#ubuntu-release 2010-03-29
 * stgraber looks at Edubuntu building and hopes that this time it'll work ;)
<stgraber> seems like it worked !
 * stgraber rsyncs
<lamont> stgraber: woot!
<lamont> Guess that means I should upload livecd-rootfs again
<lamont> will do so in the morning
<stgraber> yup, rsynced here, will start testing it but the logs were all looking good
<lamont> slangasek: you gonna hurt me if I target bug 551069 at beta2?
<ubottu> Launchpad bug 551069 in glib2.0 "FTBFS: crashes sparc" [Undecided,New] https://launchpad.net/bugs/551069
<slangasek> lamont: nope
<pitti> slangasek: I have uploaded new tzdata packages for stables (again quite urgent, meh @ governments changing them at short notice); would you mind reviewing them?
<pitti> slangasek: (dapper is still uploading, will be in the queue shortly)
<slangasek> pitti: ok, grabbing
<slangasek> ah yes, those ever-urgent Antarctic timezone changes :-)
<cjwatson> god, I hate this lvm+encryption bug, it's totally intractable
<cjwatson> I'm sure I'll figure it out at some point, but I've been prodding at it for hours and getting nowhere
<cjwatson> all I've discovered so far is that parted_server seems to be writing out the swap header but by the time any other process sees it it's all-zeroes again
<elmo> how do I (assuming I could, without my duck) tag a bug as 'not a regression, but damn, we should fix that before release'?
<slangasek> if "without my duck" ~== "without upload rights", then by talking to the release team
<slangasek> if you assume upload rights, then targeting to the release
<elmo> duck == rubber duck == root in LP
<slangasek> yeah, I know
<slangasek> the question is how un-root you want to be for this :)
<elmo> slangasek: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/546797
<ubottu> Ubuntu bug 546797 in openoffice.org "URE: Component registries might be corrupted" [Undecided,Confirmed]
<elmo> and i won't assume upload rights, I don't think I'm even an ubuntu member anymore ;-)
<slangasek> eep
<slangasek> yeah, targeting that to lucid; does that show up on upgrades from hardy, karmic, both?
<elmo> slangasek: only tried karmic
<elmo> don't tend to have OO.o on my hardy boxes
<slangasek> maintainer script sez karmic-only
<slangasek> and that this gets shown to *everyone* on karmic upgrade
<slangasek> added in OOo 1:3.2.0~rc5-1
<sbeattie> pitti: commented on bug 445852, let me know if there's more that you would like me to test.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/445852)
#ubuntu-release 2010-03-30
<slangasek> pitti: so I've done some debugging of #537262, and I'm fairly convinced that this is simply a race condition resulting from sendsigs firing before the plymouth job has *started* on shutdown; there's little enough left in /etc/rc6.d on a stock system that this is very possible
<slangasek> pitti: I think the right thing to do is, inside the 'for seq' loop, call initctl list again to check for any new jobs that have popped up; this is still not entirely race-free, but it is a fairly cheap fix (cheaper than waiting 10 seconds on shutdown for no reason) and should catch the vast majority of cases - what do you think?
<slangasek> (even though we've stopped the crash reports now, we're still hanging around ~10s longer on shutdown than we need to because of this)
<pitti> sbeattie: thanks
<pitti> slangasek: that sounds plausible, at least much more than initctl having a bug of randomly not displaying jobs
<pitti> slangasek: but what I don't understand is why plymouth would cause a 10 s hang then? doesn't it react to SIGTERM?
<pitti> slangasek: i. e. if plymouth starts slightly late, then it wouldn't be on $OMITPIDS, and the killall5 would (try to) TERM it
<pitti> which was the original effect described in the bug, I believe, that plymouth is killed prematurely
<slangasek> pitti: it /can/ cause a 10s hang because it also races the invocation of killall5 - and indeed that's the case bug #537262 would correspond to, since if it had been caught by the first killall, the apport hook wouldn't have reported it
<ubottu> Launchpad bug 537262 in plymouth "plymouth pid missing from OMITPIDS and terminated by sendsigs - Please no more confirmations/comments" [High,Confirmed] https://launchpad.net/bugs/537262
<pitti> slangasek: hm, but wouldn't at least the third or fourth one kill it?
<slangasek> pitti: the third and fourth ones use SIGCONT, which won't kill the processes :)
<pitti> oh, indeed
<pitti> right, of course; /me grabs some tea to wake up
<pitti> yes, that makes perfect sense now
<nigelb> can someone give me an ack for a UIFe for pitivi, bug 314885
<ubottu> Launchpad bug 314885 in pitivi "Don't show version number in titlebar" [Low,Triaged] https://launchpad.net/bugs/314885
<nigelb> got blessings from translations and doc
<kirkland> slangasek: is a new bash-completion file for a command line utility subject to FFe?
<slangasek> kirkland: it's a feature, not a bugfix, so yes
#ubuntu-release 2010-03-31
<nigelb> can someone give me an ack for a UIFe for pitivi before thu freeze? bug 314885
<ubottu> Launchpad bug 314885 in pitivi "Don't show version number in titlebar" [Low,Triaged] https://launchpad.net/bugs/314885
<nigelb> I'd really appreciate an ack for bug 314885 from someone from the release team
<ubottu> Launchpad bug 314885 in pitivi "Don't show version number in titlebar" [Low,Triaged] https://launchpad.net/bugs/314885
<nigelb> cjwatson, ping
<cjwatson> nigelb: hi?
<cjwatson> ... ok
<nigelb> cjwatson, got some time to ack a UIfe?
<lamont> slangasek: are we installable enough that it makes sense for me to roll new lucid tarballs?  would speed up build times to not be dist-upgrading them every build
<lamont> slangasek: and I'm not clear what sort of schedule all y'all would like around that activity, in the general sense
<slangasek> lamont: http://people.canonical.com/~ubuntu-archive/testing/lucid_probs.html
<slangasek> certainly more installable than last night
<lamont> slangasek: heh
<lamont> interesting - I just upgraded twisted on a few buildds
<cjwatson> nigelb: acked
<nigelb> cjwatson, thanks :)
<doko__> asac, slangasek: is the xulrunner-dev demotion seriously wanted? what's the replacement?
<slangasek> doko__: sorry, what's the context?
<slangasek> the upstream security policy impacts what we're going to be supporting
<slangasek> i.e., "as little as possible"
<doko__> slangasek: openjdk-6 build failure due to demotion
<doko__> didn't see any warning before ...
<slangasek> ah
<slangasek> I don't know who demoted it; it shouldn't have been done while there were reverse-deps
<slangasek> doko__: it looks like xulrunner-1.9.2 is in main now?
<doko__> slangasek: ok, will reupload.
<doko__> slangasek: I assume it is planned as well to update xulrunner to xulrunner-1.9.3 and so on for lts updates? does this mean you want to rebuild dependencies as well?
<slangasek> if it's planned, it hasn't been mentioned to me; https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model is the blueprint about this
<doko__> the only thing about demotion I can find is: decide on demotion vs. droppage of xulrunner-1.9.x from the archive
<ScottK> Personally, I think it should be removed, not demoted
<slangasek> what does openjdk need xulrunner for, btw?  It doesn't seem to have a runtime dep on it?
<doko__> slangasek: the plugin
<slangasek> it only needs headers to build that, no runtime dep?  or is it statically linking something?
<doko__> dynamically linking
<doko__>  /usr/lib/jvm/java-6-openjdk/jre/lib/*/IcedTeaPlugin.so
<slangasek> doko__: I only see a dependency on libnspr4-0d; should it be build-depending on nspr instead of xulrunner?
<slangasek> oh, hm, it links against xul but doesn't have a dep on it
<doko__> $ ldd /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so|grep 'not found'
<doko__> 	libxul.so => not found
<doko__> 	libxpcom.so => not found
<doko__> ahh
<slangasek> probably because of the "not found"
<doko__> ok, let's add this manually ...
<slangasek> dh_shlibdeps -l/path/to/libs?
<doko__> asac: ^^^ I think we did have the problem before
<doko__> will do
<doko__> the xulrunner cooperation between debian and ubuntu is just 'nice' ...
<doko__> sid: $ xulrunner-1.9.1 --gre-version
<doko__> 1.9.1.8
<doko__> but no directory with this version
<doko__> asac: is there anything simpler?
<doko__> echo /usr/lib/xulrunner-$($(basename $(pkg-config --libs-only-L libxul | sed  's/^-L//;s/-devel//;s,/lib *$,,' )) --gre-version | sed 's/^\(.....\).*/\1/')
<doko__> /usr/lib/xulrunner-1.9.2
<doko__> slangasek: doesn't help:
<doko__> dpkg-shlibdeps: warning: Can't extract name and version from library name `libxpcom.so'
<doko__> dpkg-shlibdeps: warning: Can't extract name and version from library name `libxul.so'
<slangasek> meh, figures
<doko__> slangasek: xulrunner-1.9.* doesn't have any shlibs files
<slangasek> well, and if it did they apparently wouldn't work due to the unversioned soname
<doko__> filed bug #552780, I'll hardcode the dependency for now
<ubottu> Launchpad bug 552780 in xulrunner-1.9.2 "how to properly link against libxul and libxpcom?" [Undecided,New] https://launchpad.net/bugs/552780
<Keybuk> slangasek: new mountall uploaded
<Keybuk> buildds seem very behind today
<Keybuk> so the screaming probably won't start until tomorrow
 * ajmitch hopes that stuff uploaded in the next few hours won't get us told off?
<slangasek> nope, it's my responsibility to pull the trigger on the archive freeze when it's time
#ubuntu-release 2010-04-01
<pitti> so I did some NBS and component mismatches fixes, which should clean some i386 bits on http://people.canonical.com/~ubuntu-archive/testing/lucid_probs.html
<pitti> but for this to be really useful I guess we have to wait a day or two for the buildds to catch up
<pitti> (which have been used for some 16 hours for security and openjdk builds)
<ScottK> Not to mention a huge stack of private builds overnight too.
<nigelb> ok, I got this ack on wednesday from release team, since today we're in beta freeze, do I need another ack?
<nigelb> I subscribed sponsors, no one bothered I guess
<ScottK> nigelb: No, just normal sponsorship.
<nigelb> ScottK, so that ack would also hold good for beta freeze, right?
<cjwatson> beta freeze just means that everything gets manually reviewed before it hits the archive
<cjwatson> after beta-2 release, we go back to feature freeze status for a while, so feature freeze approvals still hold good - if it's not considered suitable for beta-2 by the reviewer, we just hold it in the queue until the beta's out
<nigelb> ok, thanks :)
<ttx> cjwatson: Do you formally review all uploads during freeze, or expect to be pinged for things that need to go through ? I was wondering if we should avoid uploading what is not beta2-critical (because reviewing the queue means more work to you)
<ttx> the announcement is not clear if we should "refrain from uploading" like during the softfreezes
<cjwatson> if there's stuff that *must not* go into beta-2, please don't upload it
<cjwatson> otherwise, it's probably best to upload anyway, but if there's something you explicitly need then it's a good idea to ask
<ttx> cjwatson: ok
<Riddell> I wonder where today's kubuntu daily CDs got lost
<cjwatson> lost?
<Riddell> nothing at http://cdimage.ubuntu.com/kubuntu/daily/20100401/  build logs seem fine
<cjwatson> Missing debootstrap-required libdb4.7
<cjwatson> CD1 missing some packages needed by debootstrap
<cjwatson> make: *** [/srv/cdimage.ubuntu.com/scratch/kubuntu/daily/tmp/lucid-amd64/packages-stamp] Error 1
<cjwatson> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<cjwatson> archive error, I'll fix it
<Riddell> ah, it helps if I look at the daily build log not the daily live log
<lamont> rolling brownout of buildds for a new lp-buildd rollout, just fyi
<pitti> slangasek: oh, we haven't talked about it last Friday? will we move the release team meeting to Tuesday or somethign such? (Good Friday/Easter Monday holidays)
<pitti> or just skip it?
<slangasek> pitti: oh, I keep forgetting that Europe gets Good Friday off
<pitti> slangasek: oh, the US doesn't?
<slangasek> I don't think we should try to do one on Tuesday; we'll have our hands full with the beta itself at that point
<pitti> *nod*
<slangasek> no, we don't
<slangasek> we get Easter off ;P
<pitti> Monday?
<ScottK> pitti: Schools often get it off, but not work.
<ScottK> No, Sunday.
<slangasek> pitti: no, Easter Sunday :)
<pitti> how .. generous :)
<pitti> slangasek: anyway, is it okay if I update our release status page to the current status quo, and ask Ken or Rick to join the meeting as a desktop team delegate?
<pitti> the release status page is really what takes most of the work/conveys the most interesting information anyway
<ttx> slangasek: fwiw, the french work on Good Friday.
<slangasek> pitti: sure
<slangasek> cjwatson: I can haz queue bot?
<cjwatson> you can haz
<slangasek> kthx!
<ev> If someone could let usb-creator through, I'd appreciate it.  According to rgreening, it fixes a critical bug in the kde frontend.
<slangasek> ev: looking
<ttx> slangasek: the dhcp3 thing there is mine, would be good to have in the milestone to catch any corner case I didn't think of, but it's hardly critical or needed for beta2.
 * ttx calls it a day
<slangasek> ev: this breaks string freeze?
<ev> erm, yeah, ouch
<ev> please reject, fixing
<slangasek> ok
<slangasek> that might be alright to let in immediately post-beta, if coordinated with translators; the new string is short and easy
<slangasek> and unlikely to appear in screenshots
<ev> reuploaded
<pitti> liblauncher-0.1 kills the previous changelog, I pinged didrocks to fix and reupload
<pitti> (actual code change is obvious one-line patch)
<slangasek> ev: <cough> this upload misses the functional changes to the kde frontend
<pitti> mvo: so, I can't make too much sense of the aptdaemon upload, and there's no associated bug
<ev> arrrr
<pitti> mvo: what does that do? and how much was it tested?
<ev> this is what I get for rushing
<ev> slangasek: okay, uploaded.  Sorry for the hassle.  I've got to run to catch a train though.  If it's broken this time, it's a release note, I guess.
<slangasek> ev: ok, g'night :)
<ev> slangasek: cheers
<ScottK> slangasek: ^^^ clamav update catches (minor) security fixes from clamav 0.96 final.  I'd like those in for the beta, but am waiting on uploading 0.96 final so I can coordinate with Debian.
<mvo> pitti: sorry, its for the ubuntuone-music-store
<mvo> pitti: and it makes it use less authentication dialogs
<mvo> pitti: currently each action (add-repo, update-cache, install-pkg) is a policykit action that needs confirmation
<mvo> pitti: with the patch add-repo implicitely grants update-cache and install-pkg so that the music store needs to prompt only once
<mvo> pitti: if you need a bugreport I can ask aquarius to write one
<ScottK> queue bot gone mad.
<ScottK> Looking at the packages in Main without a package set, it seems like there's a need to adjust the promotion process to also add to a package set.
<slangasek> hmm, no doubt
<ScottK> Is UNR using chromium-browser?  It's in Universe and not part of a package set, but I thought they were.
<cjwatson> promotion process> yes, there is a problem at the moment that the two processes aren't unified
<cjwatson> this is a real pain but I haven't had time to sit down and fix it
<cjwatson> package set addition relies on me periodically processing the output of a script :-/
<doko_> please consider accepting python2.6 (only affecting the python2.6-dbg package and helping apport)
<cjwatson> grub-installer is one half of the server splash screen bug; the other half is a debian-cd change, which I can do easily but don't want to do before grub-installer's in
 * cjwatson -> bed
#ubuntu-release 2010-04-02
 * ScottK returns with more Scotch.
<ScottK> More Scotch == More NBS gets done.
<ScottK> Urgh.  Samba4 got no updates this cycle.  Do we want the 9 month old snapshot we have, the 7 month old snapshot from Unstable, or the 4 month old snapshot from December?
<ScottK> Need to rebuild due to talloc transition anyway.
<ScottK> Correction, the Experimental snapshot is two months old
<ScottK> I'll leave all three building when I go to bed and see what survives.
<ScottK> Looks like the answer may be "the one that builds".  Two of the three didn't make it through configure.
<ScottK> OK, 0 for 3 and I see it's on the supportable binaries removal list.  Will see what I can do with it tomorrow.
<asac>   ubufox_0.9~rc1-0ubuntu1_source.changes: done.
<asac> Successfully uploaded packages.
<asac> ok ...
<asac> slangasek: we wont be able to attend todays meeting ... holiday + travelling
<asac> slangasek: i will send a mail with our status replying to the meeting reminder
<asac> slangasek: also will include the stuff we wanted to discuss on omap ...
<asac> i will be back on Wed
<slangasek> asac: omap> ok, thanks - have a good holiday!
<ScottK> slangasek: I believe I have a plan: downgrade ldb to 1:0.9.6~git20090912-1, upgrade samba4 to 4.0.0~alpha8+git20090912-1 (from Unstable), then rebuild openchange and sssd.  I've tried these locally.
<ScottK> Can haz FFe?
<ScottK> (please no paperwork, I don't think I could stand making a sensible bug of it)
<ScottK> 1:0.9.10~git20091212+really0.9.6~git20090912-0ubuntu1
<slangasek> ScottK: how are you handling the downgrade?  +really.git20090912-1?
<ScottK> Except ld is getting confused now for some reason.
<slangasek> howso?
<ScottK> err dpkg-shlibdeps I mean
<ScottK> https://launchpad.net/~kitterman/+archive/ppa/+build/1623812/+files/buildlog_ubuntu-lucid-i386.ldb_1:0.9.10~git20091212+really0.9.6~git20090912-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
<ScottK> I'm trying another local build of the unmodified package to make sure it's related to the rename
<ScottK> Should know in ~5 minutes
<ScottK> Yeah, builds fine when not renamed
<ScottK> Foundi t.
<ScottK> it.
<slangasek> \o/
<slangasek> ScottK: FFe granted, yes
<ScottK> Thanks.
<ScottK> On it's way.
<doko__> hmm, who did give back schroot on armel? did give it back just 1h ago ...
<slangasek> not me
 * ScottK neither
<ScottK> Any ideas what samba4 would be in the Xubuntu package set?
<slangasek> sounds like a bug to me
 * ScottK wonders if the bug gets filed against cjwatson?
<ScottK> I was wrong about saving a binary New.  The newer samba4 snapshot has new binary packages.
 * ScottK is off for a while.
<slangasek> ScottK: the kdebase-workspace repo has an unrelated change to the default homepage; are you ok with that going in w/ the plymouth fix, or should I revert temporarily?
<slangasek> ScottK: I see samba4 in the queue, but not ldb?
<ScottK> slangasek: I went ahead and pushed ldb through since Universe isn't frozen.
<slangasek> ah, ok
<ScottK> slangasek: I'm fine with the homepage change (it's been discussed in #kubuntu-devel)
<ScottK> Pushed samba4 too.
<ScottK> I'm off (really this time).  I 'll at kdebase-workspace when I get back.
<slangasek> ok - should finally reach the queue in 10min or so
#ubuntu-release 2010-04-03
<ScottK> slangasek: Accepted (workspace).  Thank you.
<slangasek> ScottK: yay \o/
<ScottK> samba4 is working out too.  It goes on the binary New stack for Monday's archive admin ....
<slangasek> I'll hopefully get to that yet tonight
<ScottK> apt-cache unmet|grep -c Depends
<ScottK> 205
<ScottK> Some work there too for the next few weeks.
 * slangasek nods
<sistpoty> did the binary package removal thingy happen already?
<slangasek> sistpoty: I was trying to get debtags-edit sorted out first, and it's being stubborn
<ScottK> FYI, since the Launchpad rollout yesterday, packages are not automatically coming off of depwait.  They need a manual push.
<wgrant> s/yesterday/Wednesday/
<slangasek> ScottK: has that bug been reported?
<wgrant> Yes, a CP is pending.
<slangasek> oh, wgrant knows - same thing :-P
<ScottK> Yep
<slangasek> that explains the strangeness of me having to nudge packages along
<wgrant> https://bugs.edge.launchpad.net/soyuz/+bug/553068
<ubottu> Ubuntu bug 553068 in soyuz "buildd-retry-depwait.py crashing" [High,In progress]
<sistpoty> ok, thanks, I guess 230 unmet deps isn't too good then :/
<slangasek> how many go away when we remove the unbuildable binaries?
<ScottK> Not sure if that makes it more or less.  We'll see.
<slangasek> right, so lucas has reported a FTBFS bug against debtags-edit in Debian too
<ScottK> slangasek: Please try and document what you're doing so when I suggest we do this every cycle at UDS, you won't have to cringe and wish you had.
<slangasek> and the reason it build-depends on g++-4.2 is because of an Ubuntu delta; the bug was fixed differently in Debian, and now there's a fresh FTBFS
<slangasek> ScottK: the email included pointers to and/or copies of all the scripts used :)
<slangasek> I documented it so I wouldn't have to remember how to do it a week later, let alone a cycle ;)
<ScottK> ;-)
<slangasek> right, so, debtags-edit is orphaned in Debian; gonna do a QA upload and fakesync
<sistpoty> is ries already back up?
<slangasek> yes
<sistpoty> oh, nice, thanks!
<slangasek> but backlogged so badly that it's not feasible to wait until I can do a real sync
<wgrant> Yay, my inbox might stop filling up.
<ScottK> slangasek: Would you please look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566270 and give me a preference between putting the offending package back or removing the rdpends (which are currently uninstallable)?
<ubottu> Debian bug 566270 in ftp.debian.org "RM: libclass-dbi-loader-relationship-perl/unstable -- RoQA; License problems" [Normal,Open]
<ScottK> Odd it's open, since it was removed from Unstable.
<ScottK> and StevenK, of course, chopped it right out of Ubuntu.
<ScottK> Based on the comment from the original author in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563519 I'd be inclined to put it back.
<ubottu> Debian bug 563519 in libclass-dbi-loader-relationship-perl "libclass-dbi-loader-relationship-perl: missing copyright and license" [Serious,Fixed]
<slangasek> ScottK: oh, geez; yes, please put it back
<ScottK> slangasek: It's still in Testing, can you sync it from there.
<slangasek> "can't independently verify the license in debian/copyright by looking at the upstream sources" - not a bug
<slangasek> will I be able to sync it, or will I get a "version previously seen" from LP?
<ScottK> You will.
<ScottK> (get the previously seen)
<ScottK> I'll upload it.
<slangasek> ok
<ScottK> Would you remove it from the sync blacklist please.
<wgrant> I really should fix copy-package.py to let you revive binaries.
<wgrant> It's perfectly possible for other archives through the web UI. Just not through the console for the primary archive.
<slangasek> ScottK: it's not in the sync blacklist (removals generally don't end up there) - did you want it added /to/ the blacklist (to prevent it from showing up on the removal list)?
<slangasek> taking a smidge longer than expected to fix up debtags-edit, because I'm fixing up the Vcs-* settings while I'm uploading - given that the package is orphaned and I can't commit to the target repo
<ScottK> Hmmm.  Probably should be added.
<slangasek> done
<ScottK> Uploaded.
<sistpoty> ok, unless I made another silly mistake as with mclibs, libgfortran2 -> libgfortran3 should be done.
<slangasek> \o/
<ScottK> To balance the karma, I found another package that needs removing.
<ScottK> Found another premature removal, but fortunately it has a new version, so I just filed a sync bug.
<ScottK> Good night.
<slangasek> 'night!
<ScottK> slangasek: Could we perhaps have plymouth-theme-ubuntu-logo seeded somewhere that all derivatives don't end up with it seeded?
#ubuntu-release 2010-04-04
<slangasek> ScottK: yes, though I think we should make sure all the flavor theme packages depend on plymouth-label before switching
<ScottK> slangasek: How about just seeding plymouth-label then, not the entire Ubuntu theme?
<slangasek> the target is to not need to seed plymouth-label at all and only pull it in as a dep; I'd rather just get all the theme packages fixed so we don't have to change it twice
<cjwatson> slangasek: I want to move plymouth-theme-ubuntu-logo from standard to desktop-common too to avoid excessive pollution of Priority: standard; I switched the seeds over, but I think all the -metas that use desktop-common will need uploads ...
<cjwatson> I figure servers won't want it anyway
<cjwatson> oh, err, does this conflict with what ScottK said above?
<cjwatson> actually no, it supports what ScottK said :-)
<cjwatson> ok, so I won't upload *-meta until the themes have been switched
<cjwatson> I'm away Sun/Mon anyway
<ScottK> slangasek: Are you tracking which are updated and which aren't?  Kubuntu is fixed.
<slangasek> ScottK: I'll look this weekend and make sure it's sorted before Monday
<ScottK> Great.
<ScottK> I need to do a kubuntu-meta upload, but not before it's fixed so that doesn't get dragged in.
<slangasek> ScottK: the last workitem for foundations-lucid-supportable-binaries is 'update SRU policy to ensure it's clear FTBFS fixes for missing binaries are SRU candidates', but it already seems clear to me - do you think changes are still needed here?
<ScottK> slangasek: If you're happy.  I'm happy.
<ScottK> There was some discussion about it as UDS, but we didn't review it in detail.
<ScottK> I think particularly since you said they were SRU candidates in your u-d-a mail, it should be fine.
<slangasek> okie
<ScottK> It's interesting how fast the vnc FTBFS got fixed once it was removed....
<slangasek> that does tend to be the way
<ScottK> BTW, ldb -> samba4 -> openchange -> evolution-mapi is all done.
 * slangasek cheers
<doko_> slangasek: I'd like to upload a gcc-snapshot/gcc-4.5 build (supposed to build on armel). it will block the community ports for a while, but the queues are empty
<slangasek> doko_: go ahead and upload, though there may be a few more accepts in the meantime out of the stuff currently in the queue
<ScottK> Interesting.  I didn't realize Partner would build on the Ubuntu buildds.
<wgrant> ScottK: That does seem pointless.
<wgrant> But it's trivial for an admin to change.
<ScottK> For sun-java6 it makes sense to do it that way.  It just further blurs the line about is Partner part of Ubuntu.
<wgrant> I heard rumours that Partner will be replaced with PPAs soon.
<wgrant> As it should have been from the start...
<wgrant> (technically they're not 'Ubuntu' buildds; they're just non-virtual)
<ScottK> I heard that rumor too, but it may have been from you.
<wgrant> Possibly. I heard it from a reasonable source last week.
<slangasek> ^^ would be great if someone could review plymouth
<ScottK> Is queuediff expected to be able to cope with v3 format source packages?
<ScottK> BTW, a certain maintainer is unlikely to be pleased with your versioning.
<slangasek> I did several other uploads with the same versioning and there was no screaming.  I'm happy to use dch the way it's meant to work, and he's apparently happy to fix the version up by hand each time he uploads. <shrug> :)
<ScottK> OK.
<ScottK> For some reason, queuediff seems to be failing to remember to download plymouth_0.8.1-4ubuntu1.debian.tar.gz and things go downhill from there.
<slangasek> :(
<ScottK> slangasek: I'm not comfortable with accepting the plymouth upload, but I did fix queuediff to work with v3 source format.
<wgrant> ScottK: I'm guessing that it would make everyone involved rather happy if LP did the diff itself?
<ScottK> Not sure.  Queuediff seems to work pretty well.
<ScottK> Just interdiff doesn't work on v3 source.
<ScottK> So you have to skip the shortcut of not downloading the orig.tar.gz .
<ScottK> I guess it would depend on how much I trusted LP to really be diffing the correct files.
<wgrant> Interestingly, LP does actually do the diff before the upload is accepted.
<wgrant> It just doesn't display a link anywhere.
<wgrant> LP uses debdiff.
<ScottK> What gets diffed if there are two uploads of the same package in queue?
<wgrant> It will diff against the latest primary archive version.
<wgrant> Latest accepted, that is.
 * ScottK needs to get to sleep, but will think about it.
<wgrant> Night.
<ScottK> Good night.
<cjwatson> slangasek: plymouth looks good to me; accepted
<sistpoty> cjwatson, iulian, Riddell, pitti, nhandler, ScottK, slangasek: wrt. delegates, I've finally got confirmation from anyone and have drafted a mail about it: http://paste.ubuntu.com/409073/
<sistpoty> any comments, questions, objections?
<ScottK> No server delegat then?
<sistpoty> ScottK: thought you'd handle server? (no need to delegate then)
<sistpoty> should I explicitely mention that kubuntu and server has members in the release team already, so isn't delegated?
<ScottK> Sounds reasonable.
<sistpoty> revised version: http://paste.ubuntu.com/409076/
<ScottK> sistpoty: Looks good.
<sistpoty> ok, thanks
<sistpoty> (I'll wait a little bit longer yet in case someone else has objections or additions before sending)
<nhandler> sistpoty: What do you mean by "directory process"? Do you mean Ack+Upload?
<sistpoty> nhandler: grant an exception. Do you think that's unclear?
<sistpoty> (it's "directly process" btw, seems like I even spellt it correctly *g*)
<nhandler> sistpoty: Yeah, it is a bit unclear, as they should be leaving a comment on those types of bugs as well to show they granted a FFe. /me can't type right after waking up
<sistpoty> heh
<sistpoty> ok, will try to improve the wording
<sistpoty> http://paste.ubuntu.com/409086/
<sistpoty> nhandler: is that better? ^^
<nhandler> sistpoty: Is there a reason for the distinction between sync requests? Shouldn't a note saying an ack has been (not) granted be left on all bugs they process?
<sistpoty> nhandler: good point, was thinking of FFe's granted on irc when I wrote explicitely about sync requests
<sistpoty> next try: http://paste.ubuntu.com/409089/
<sistpoty> nhandler: ^^
<nhandler> Looks good
<sistpoty> and yet one small fix: http://paste.ubuntu.com/409090/ (s/nonetheless/always/)
<nhandler> :)
<sistpoty> ok, mail sent to U-D-A, pending moderation. In case there's anything that should get improved, please delete it from moderation, make the changes and resend (as I'm most likely afk for the rest of the day), thanks!
<ScottK> slangasek: ^^^
<slangasek> mail accepted
#ubuntu-release 2011-03-28
<hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
<cjwatson> ScottK: sorry, wasn't at a terminal
<pitti> cjwatson: FYI, I did some seed updates to catch transitional packages, demotion of binaries to universe, etc (just to avoid overlaps here)
<pitti> langpacks now finished building, and I newed the rest, so the noise from them should disappear in the next cycle, too
<ev> doko_: ping; I don't suppose you have time to take a quick look at https://bugs.launchpad.net/ubuntu/+source/python-mock/+bug/723219 ?
<ubot4`> Launchpad bug 723219 in python-mock (Ubuntu Natty) (and 1 other project) "[MIR] python-mock (affects: 1) (heat: 10)" [Medium,New]
<doko_> ev: doing today
<ev> awesome, thanks so much
<ScottK> cjwatson: No trouble.  It turned out not to be so bad.
<mvo> ev: python-mock \o/
<ev> mvo: yeah, it's awesome, isn't it? And Michael Foord works for Canonical now, so double win.
<mvo> ev: indeed, plus getting the MIR through is also nie
<mvo> ce
<mvo> nice
<ev> indeed :)
 * pitti accepts gcalctool, only translation updates
<pitti> nss discussed in #u-devel, accepting
<NCommander> anyone awake who can sign off on a beta freeze exception?
<cjwatson> can you upload the package in question and we'll review it from the queue?
<ogra_> NCommander, pitti should be able to
<cjwatson> that's usually better than approval-in-advance
<NCommander> cjwatson: I just did
<ogra_> yeah, trust the queuebot :)
<NCommander> mono 2.6.7-5ubuntu2
<cjwatson> queuebot will notice in a few minutes
 * NCommander got the email
<ogra_> it's watching you ;)
<NCommander> https://bugs.launchpad.net/ubuntu/+source/mono/+bug/619981
<ubot4`> Launchpad bug 619981 in mono (Ubuntu Natty) (and 2 other projects) "mono apps crash on omap4 due to no smp support for armel (affects: 1) (dups: 1) (heat: 33)" [High,Confirmed]
<cjwatson> it's an RC bug, should be acceptable, I'll review it once queuebot notices it
<pitti> NCommander: only question is: will it build on armel by tomorrow?
<NCommander> pitti: its a 3h build
<NCommander> as long as the buildds aren't clogged, it should
<pitti> mono has an arch all/any mix, thus highly prone to uninstallability due to archive desync
<pitti> NCommander: they aren't, there's a handful of free armel builders
<NCommander> Finished on 2011-03-25 (took 3 hours, 54 minutes, 12.3 seconds)
<NCommander> Er, 4 hours
<NCommander> :-P
<ogra_> pitti, its severe enough to have a delay due to the upload
<pitti> ogra_: agreed
<pitti> 4 h sounds fine
<ogra_> i.e. imho it is acceptable to lose a day
<NCommander> ogra_: will you handle the seeding change?
<ogra_> pitti, we will need a subsequent seed change and netbook.-meta upload once that has been tested
<ogra_> NCommander, sure
<cjwatson> mono accepted
<ogra_> thanks !
<NCommander> awesome
<highvoltage> skaet: good morning, in Edubuntu we have an incomplete feature that we'd like to remove, it requires an FFe UI freeze exception
<highvoltage> skaet: I filed a bug for it at https://bugs.launchpad.net/ubuntu/+source/edubuntu-live/+bug/744292 - after stgraber acks it I'll go ahead and do it, just wanted to let you know fwiw
<ubot4`> Launchpad bug 744292 in edubuntu-live (Ubuntu) "FFe: Please remove edubuntu-live-welcome from Edubuntu live system (affects: 1) (heat: 6)" [Low,New]
<skaet> highvoltage, thanks for letting me know.
<skaet> highvoltage, will it require documentation changes to release notes?
<highvoltage> skaet: nope
<skaet> okie.  just wanted to check.
<stgraber> highvoltage: +1, I'll remove it from the seed and see if we need to update -meta.
<highvoltage> stgraber: great
<stgraber> highvoltage: it doesn't seem to have any rdepends so removing from the seed should be enough
<stgraber> highvoltage: done
<ScottK> If you removed it from the seed, you'll need a meta upload too.
<stgraber> ScottK: it wasn't in edubuntu-desktop, it was just in our livecd seed. I'm rebuilding -meta anyway but AFAIK it wasn't referenced in any meta package.
<ScottK> Oh.
<ScottK> OK.
<pitti> cjwatson: quick sync-up about natty_probs: fglrx/nvidia are meant to be uninstallable (incompatible X.org ABI), and Bjoern and I are sorting out the oo.o stuff; after that it's down to armel
<cjwatson> pitti: thanks
<cjwatson> I'm doing a full CD build pass now, except for armel (since at least some of those are waiting for mono)
<cjwatson> I don't particularly expect this to be final, but it'll be good for smoke-testing
<pitti> *nod*
 * skaet *nods*
<pitti> skaet: good morning
<pitti> skaet: who is the AA in charge for beta-1?
<skaet> good afternoon pitti
<skaet> pitti,  cjwatson's on the list
<pitti> skaet: (I'll help out, of course)
<cjwatson> where is that list, incidentally?  I keep losing it
<skaet> just a sec, and I'll post the link
<skaet> https://wiki.ubuntu.com/ReleaseTaskSignup
<cjwatson> ah yes, thanks
<cjwatson> linked from ReleaseTeam in an effort to not lose it again
<pitti> ah, I didn't find it either, thanks
<pitti> well, in practice it has always been a shared effort anyway
<skaet> :)
<skaet> cjwatson, thanks for linking from ReleaseTeam page, should have done that earlier.
<stgraber> skaet: I'm going to upload a new LTSP fixing install issues on Edubuntu (typos in postinst script generating invalid ssh_known_hosts)
<ScottK> stgraber: I'll review it.
<skaet> stgraber,  ok
<stgraber> ScottK: thanks. uploaded
<ScottK> OK.  It'll be a bit before LP has a diff.
<pitti> ^ these fix uninstallability issues, accepting
<stgraber> ScottK: thanks fror the review
<stgraber> *for
<ScottK> It wasn't actually me.  I got disctracted by $WORK.
<highvoltage> I uploaded a bug fix for edubuntu-live as well (see above), would be nice if someone could let it through!
<pitti> stgraber: you're welcome :)
<pitti> highvoltage: looks fine, accepted
<highvoltage> pitti: vielen dank
<cjwatson> debian-installer is mostly a rebuild for the current kernel
<pitti> skaet: ah, I am currently figuring out why our WI charts are broken -- seems the ubuntu-11.04-beta-2 milestone disappeared from https://launchpad.net/ubuntu/natty ?
<pitti> no wonder we have so much stuff on our b1 charts
<skaet> pitti,  yeah, I was looking for it to assign bugs to this morning and not seeing it either.
<pitti> skaet: mind if I create it again?
<skaet> please
 * skaet will be very happy actually if you do.  :)
<pitti> done
<skaet> :D
<pitti> looking forward to tomorrow's WI charts then
<pitti> OO.o/LibO stuff fixed on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
<pitti> good night everyone, time for sport
<skaet> thanks pitti.
<stgraber> pitti: oh, ok :) thanks !
<cjwatson> can somebody who didn't contribute to them review debian-installer and ubiquity?
<cjwatson> and possibly also ubiquity-slideshow-ubuntu, cf. bug 744374
<ubot4`> Launchpad bug 744374 in ubiquity-slideshow-ubuntu (Ubuntu) "UI Freeze Exception: ubiquity-slideshow-ubuntu (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/744374
<ScottK> slangasek: koffice in the queue is another armel GL/GLES fix.  I did test build on armel, so I think it's safe.
<slangasek> ok, looking at d-i/ubiquity/koffice
<skaet> thanks slangasek
<ev> If someone could approve the incoming apt-clone, I'd appreciate it.  Fixes a bug in the upgrade/reinstall option in ubiquity that I was seeing in my tests.
<skaet> ev, is there a bug number?
<ev> no, I didn't file one sadly.  It was a fairly standard "install Ubuntu 10.10 with pidgin and chromium, then try the natty installer upgrade option".  It's covered in the regression tests.
<ev> err it is now :)
<cjwatson> gfxboot-theme-ubuntu 0.11.3 on its way, fixes the RC part of bug 742558
<ubot4`> Launchpad bug 742558 in ubiquity (Ubuntu Natty) (and 3 other projects) ""Keep default keyboard layout ..." dialog is confusing (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/742558
<cjwatson> https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu24/+buildjob/2349966/+files/buildlog_ubuntu-natty-i386.debian-installer_20101020ubuntu24_FAILEDTOBUILD.txt.gz urp
<jibel> skaet, buildid for ubuntu-alternate is 20110328.1 ?
<cjwatson> yes
<jibel> smotest ran fine and images are good then.
<jibel> s/smotest/smoketest
<cjwatson> good, so we have a baseline
<skaet> jibel,  :)  thanks.
<slangasek> ev: fwiw, there's a standard interface for disabling build-time test suites: DEB_BUILD_OPTIONS=nocheck
<jibel> skaet, ubuntu-server and desktop on amd64 and i386 passed smoketest.
<skaet> yay - was just wondering about server...  :)
<skaet> jibel,  thanks
<slangasek> ev: so "ifndef UBIQUITY_NO_TESTS" ought to be "ifneq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))"
<slangasek> ev: though hmm, I don't see that anything calls this 'tests' target by default?
<cjwatson> slangasek: it's a dependency of the binary target
<cjwatson> (which is a bit odd since binary is only run on the arch-indep builder, i.e. i386)
<cjwatson> in fact, may not necessarily be run at all
<slangasek> mm, yes
<ev> bum
<slangasek> ev: accepted, all the same; but I suppose you'll want to clean up the testsuite activation some
<ev> failed to build
<ev> fixing
<ev> and indeed
<ev> thanks for the pointers
<slangasek> ftbfs? poo
<slangasek> ah, in the testsuite no less - so only on i386 ;)
<ev> heh
<slangasek> there are two apt-clones in the queue; which one is the good clone and which one should I shoot?
<ev> oh, probably shoot mine
<ev> I didn't see any record of mvo's upload on launchpad
<ev> so I signed and uploaded
<slangasek> so shoot the later one, keep the earlier?
<ev> correct
<doko> the just uploaded sysvinit is multiarch fallout. please accept, if we want the fix for bug #665185 in the beta
<ubot4`> Launchpad bug 665185 in sysvinit (Ubuntu) "/etc/init.d/sendsigs fails to kill some processes (affects: 1) (heat: 10)" [Low,Fix released] https://launchpad.net/bugs/665185
 * slangasek makes a frownie-face at the upstream build system
<slangasek> doko: do you happen to know where the sysvinit upstream tarball went?  apparently 2.86.ds1 had one, and 2.87dsf is a native package
<slangasek> anyway, accepted
<slangasek> doko: is everything unblocked at this point to let you go ahead with a snapshot rebuilD?
<slangasek> tr D d
<doko> slangasek: I don't know of anything more, the remaining c-m shouldn't hurt
<doko>  o nodm: nodm
<doko>    [Reverse-Recommends: kdebase-workspace]
 * slangasek nods
<doko> Riddell: ^^^
<doko> anyway, first dinner
<slangasek> that was discussed earlier today on #u-d, it's an alternative Recommends
<ScottK> slangasek: Thanks for the koffice reivew.  Pending a resolution on avogadro we're done on gl/gles stuff.
<slangasek> yep - kunal is working through the avogadro stuff, hope to see a resolution in the next day or two
<slangasek> is that blocking rebuild of packages for beta on armel?
<ev> slangasek: so something like this? http://paste.ubuntu.com/586598/
<slangasek> ev: looks good to me
<slangasek> ev: please verify in a test build that it actually does what you expect, my mastery of make $() commands is poor :)
<ev> slangasek: exactly what I'm doing now :)
<ScottK> slangasek: Yes.  IIRC Riddell was looking into dropping the avogadro build-dep/depends on armel as a workaround.  Not sure how far he got.
<slangasek> ScottK: ok. unfortunately since avogadro is using GLEW, rather than GL, it's not as straightforward as just switching the build-dep to gles2
<slangasek> maybe GLEW ought to also build against gles2 on armel, but that's a big can of worms
<skaet> ev, slangasek, cjwatson - could one of you take a look at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/739632
<ubot4`> Launchpad bug 739632 in ubiquity (Ubuntu Natty) (and 1 other project) "ubiquity crashed during install with: plugininstall.py: DebconfError: (10, "oem-config/enable doesn't exist") (affects: 8) (dups: 5) (heat: 162)" [High,Confirmed]
<slangasek> best if cjwatson or ev can look at it, my familiarity with ubiquity isn't very deep
<skaet> slangasek, ok, thanks.
<cjwatson> looking
<cjwatson> I thought I fixed that one
<cjwatson> can't find the fix though ...
<cjwatson> oh yes, I remember going through that with ev.  it's not a ubiquity bug, it's a bug somewhere else
<cjwatson> skaet: do we have any direct contact on IRC with a tester who can reproduce this?
<skaet> jibel's reporting it
<skaet> should be able to hook up in #ubuntu-testing
<jibel> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/730209/comments/29 same issue with current iso and ubiquity 2.5.29 . I'll try to find the tester
<ubot4`> Launchpad bug 730209 in ubiquity (Ubuntu Natty) (and 1 other project) "Ubi-partman fails with exit code 141 in Desktop Natty Alpha 3 (affects: 31) (dups: 2) (heat: 166)" [Critical,Fix released]
<cjwatson> I hope we aren't encouraging testers to tack onto the end of existing bugs
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/739632/comments/9 - request for debugging information
<ubot4`> Launchpad bug 739632 in ubiquity (Ubuntu Natty) (and 1 other project) "ubiquity crashed during install with: plugininstall.py: DebconfError: (10, "oem-config/enable doesn't exist") (affects: 9) (dups: 5) (heat: 170)" [High,Incomplete]
<iulian> Please accept mahara. ^
<cjwatson> that looks like a syncpackage upload?
<iulian> Indeed.
<cjwatson> I'd process a requestsync bug if given the bug number
<cjwatson> I would rather not process a syncpackage upload
 * iulian nods.
 * iulian wonders how he can track down the uploader.
<cjwatson> that's one of the reasons I don't like to process syncpackage uploads ...
<iulian> Bleh.  I'll just do it myself.
<cjwatson> I may be able to track down the signer with some work
<cjwatson> 2011-03-28 21:30:24 DEBUG   Signed-By: Artur Rona <ari-tczew@ubuntu.com>
<cjwatson> iulian: ^-
<iulian> Uhm.
<cjwatson> and if Artur wonders why most of his sync bugs haven't been processed, it's because most of them are Debian uploads that incorporate an Ubuntu change and maybe make the odd packaging tweak - I've been processing universe syncs that actually make functional changes, but I don't want to spend buildd time on things that users won't notice
<cjwatson> and I'm entirely happy to process something like this from him (a security fix) via requestsync
<iulian> It seems that he's not online at the moment and I'm too lazy to send him an email.  He obviously didn't read your last email sent to the ubuntu-devel mailing list.
<iulian> Anyway, I will let him know about this when I see him online, if I don't forget.
<cjwatson> good luck
<iulian> Have you already talked to him about this?
<cjwatson> not about this particular thing
<cjwatson> If Artur asks, I've rejected his syncpackage upload per https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032789.html, but have done a verbatim sync of the same package version in his name
<cjwatson> (he's not on IRC at the moment)
<iulian> Ack.
<cjwatson> skaet: Evan's fixed that debconf protocol desync bug, upload should be ready soon
<skaet> cjwatson, ev - thanks!  :)
<ev> sure thing
<cjwatson> I'm going to need to upload a couple of desktop packages to fix udebs so that d-i is buildable again
<cjwatson> pango1.0 and libxcb
<cjwatson> accepting ubiquity
<slangasek> cjwatson: pango1.0/libxcb> blast; do you want me to take one of those?
<cjwatson> I'm on pango1.0, if you could take libxcb that would be good
<slangasek> ack
<cjwatson> I assume you know which problem I mean - stuff being in /usr/lib/$(multiarch) rather than /usr/lib
<slangasek> yep
<cjwatson> well, I'm on pango if the bzr checkout ever finishes
#ubuntu-release 2011-03-29
<slangasek> cjwatson: have you confirmed these are the only two udebs with the problem and things won't fail further down the line?  I guess we don't have udebs in Contents
<slangasek> libxcb fix committed, building to verify
<doko> populate-archive now running for 1h, not sure if I will wait ...
<slangasek> how long does it usually take?
<cjwatson> slangasek: Debian does, we don't, unfortunately
<cjwatson> I might be able to cruft together a brute-force scan
<cjwatson> we don't have that many udebs ...
 * slangasek nods
<slangasek> libxcb uploaded, after I stopped typoing it as 'xkcb'
<slangasek> did your bzr checkout clear?  if not, I have a local checkout
<cjwatson> it did, I'm test-building now
<slangasek> ok
<slangasek> sorry for the hassle :/
<cjwatson> -rw-r--r-- root/root     15544 2011-03-25 04:47 ./usr/lib/i386-linux-gnu/avahi/service-types.db
<cjwatson> pool/main/a/avahi/libavahi-common3-udeb_0.6.29-0ubuntu2_i386.udeb
<cjwatson> is the other one - apparently not actually a library though
<slangasek> yep
<slangasek> just arch-dep gdbm database file
<cjwatson> the library itself is in /usr/lib
<cjwatson> so that won't break mklibs
 * slangasek nods
<cjwatson> everything else on i386 is clean
<doko> I remember taking it about 1h the last time
<cjwatson> ... and amd64 armel powerpc
<cjwatson> slangasek: does http://paste.ubuntu.com/586660/ look OK?  slightly clunky ...
<slangasek> I thought about just changing the install path in the .install.in file for the library and leaving the modules in the multiarch path; mklibs doesn't need to poke at the modules, does it?
<slangasek> your way looks correct to me as well, but it is clunky as you say
<cjwatson> it seems as though it ought to consider symbols in them for reduction
<slangasek> ok
<cjwatson> if a pango module is the only thing that uses some symbol ...
<cjwatson> (I'm not certain whether it does right now, but it ought to if it doesn't :-) )
<cjwatson> ah, it does, they show up in mklibs output
<slangasek> ok
<slangasek> I'll accept this if you upload it :
<slangasek> )
<cjwatson> slangasek: done.  I used your changelog entry from libxcb though, since it was better-worded ... :-)
<slangasek> heh, ok :)
<cjwatson> slangasek: would you mind giving d-i back once those two have been published?  I'll be asleep by then, I hope
<slangasek> can do
<cjwatson> could somebody look at gfxboot-theme-ubuntu 0.11.3, please?
 * cjwatson -> bed
<hyperair> hi
<hyperair> is it too late to upload something for beta1?
<hyperair> slangasek: ping
<slangasek> hyperair: hi there
<hyperair> slangasek: hi. i'd like to upload banshee 1.9.6 for natty. is it too late for that?
<slangasek> "Too late to upload something for beta1" - technically no, but it hopefully has a good reason :)
<hyperair> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/736631
<hyperair> this bug.
<ubot4`> Launchpad bug 736631 in banshee (Ubuntu) "External devices not recognised at all (affects: 10) (dups: 2) (heat: 60)" [High,Fix committed]
<slangasek> what else is in the new upstream version?
<hyperair> i accidentally broke the build of the gio hardware backend, so nothing gets detected
<slangasek> "new upstream version" usually implies "feature freeze exception needed"
<hyperair> http://pastebin.com/9x4YUJws
<hyperair> that's the relevant changelog entry
<hyperair> in banshee's case, i'm planning to get 2.0 into natty, but that'll be after beta.
<hyperair> banshee's following the GNOME release schedule, and 1.9.6 is the current unstable version -- 2.0 is the next stable
<slangasek> 9 entries listed under "enhancements" - sorry, I'm not willing to accept a freeze exception like this the week of beta; if you think 736631 should be fixed for beta1, please backport
<hyperair> alright, thanks
<slangasek> (unless skaet has a different opinion on this)
 * skaet looking
<skaet> hyperair, I agree with slangasek,  file it in as a FFE and target it to beta-2.    Its a bit late for beta-1 now.
<hyperair> skaet: alrigt.
<hyperair> skaet: there's also the 2.0 release coming up in april
<skaet> hyperair,  do you know when?
<hyperair> tarball due on 4th
<hyperair> should have relatively minor changes, so the package should be ready for upload within the next day or so
<skaet> hyperair, that will fit into the beta-2 window nicely.
<hyperair> alright. thanks.
<hyperair> skaet: so should i file two FFEs, or will one suffice?
<skaet> hyperair, file one FFE for the 2.0 version.  Unless there's a very good reason to take the other one before.
<hyperair> alright.
<hyperair> well, i'll be going. slangasek, skaet, thanks for the help!
<skaet> hyperair, thanks for bringing it forward.  :)
 * skaet toddles back to editing release notes....
<slangasek> cjwatson: hmm, strange new failure with the new libpango, "Depends: libthai0 (>= 0.1.12) but it is not installable" - digging in
<slangasek> got it, moving the files back to /usr/lib caused binary-install/$(UDEB_PKG) to fail to remove pango-thai-lang.so
<slangasek> if anyone wants to review pango1.0 in the queue in about 5 minutes, be my guest; otherwise I'll self-accept to make sure it gets in before the no-publisher window
<kirkland> slangasek: i can, if you like
<kirkland> slangasek: elseways, go for it
<slangasek> up to you
<slangasek> kirkland: ^^ you reviewing, or shall I accept directly?
<kirkland> slangasek: i'm already on it, looks good
<kirkland> slangasek: component/section/priority?
<kirkland> slangasek: i'll leave as is
<kirkland> slangasek: OK: pango1.0
<slangasek> nothing should be changed, this isn't a NEW package...
<kirkland> slangasek: done
<slangasek> thanks
<slangasek> should build in plenty of time to get into the next publisher cycle, good
<skaet> :)
<pitti> Good morning
<mvo> the python-apt is a nice-to-have but its perfectly fine if its not on the cd
<pitti> mvo: it does cause a ton of jockey crashes, though
<pitti> mvo: thanks for fixing that (and kudos to barry for debugging)
<mvo> yeah, all credit goes to barry
 * mvo hugs barry
 * pitti accepts the slideshow as well
<pitti> as we didn't get the split cairo in, I'll chop off a small langpack from i386 to fix oversizedness
<pitti> (cairo will land after b1)
<cjwatson> slangasek: thanks for cleaning up pango1.0
<cjwatson> damn, I should have caught that in debc :-/
<cjwatson> if that bind9 upload is what I think it is, it has to be in the server images we ship, IMO (http://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record)
<cjwatson> reviewing
<cjwatson> oh, no, different bug
<cjwatson> OK, that's low-priority, I think I'll leave it
<pitti> the dnssec one is much more urgent for lucid/maverick at this point
<pitti> still figuring out the SRUs
<cjwatson> that dnssec bug is already fixed in natty, good
<pitti> cjwatson: do you think we'll need to fix bug 717404  for b1?
<ubot4`> Launchpad bug 717404 in ubiquity (Ubuntu) "ubiquity-dm crashed with IOError in command(): [Errno 32] Broken pipe (affects: 2) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/717404
<cjwatson> pitti: see my comments at the end of that bug
<cjwatson> that's Fabio Marconi being scattershot in his bug handling
<cjwatson> I suspect that the original bug is no longer relevant
<pitti> ah
<pitti> I saw them, but I didn't know yet how urgent the original one was
<pitti> cjwatson: I dropped the bn langpack from i386 live seed to work around the oversizedness, FYI
<pitti> still needs to trickle through soyuz, I guess
<pitti> slideshow and python-apt are currently being published
<cjwatson> it was processed by the cron.germinate run that just happened, and there's stuff to be published, so it'll hit the archive in <1hr
<seb128> is the current iso worth testing or are respins coming in the next hours?
<pitti> I'd say "both"
<seb128> ok
<pitti> seb128: the new iso is by and large "newer slideshow, fixed python-apt for jockey crash, not oversized any more on i386"
<Daviey> Hi, what was the reasoning for server spin 20110329 ?
<cjwatson> cron
<cjwatson> and whatever packages were accepted between the previous build and that one; at minimum it includes a refreshed installer with the current kernel
<Daviey> ah ok.. has the uninstallable packages in powerpc been noticed?  It's new in the report.html from the previous spin.
<Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/20110329/report.html
<cjwatson> nope, I'll check on that
<cjwatson> hm, ubiquity build failures on armel and powerpc
<Daviey> oh joy.
<cjwatson> Evan mentioned something which I now see was related to that
 * cjwatson has a poke
<Daviey> groovy.
<cjwatson> 01:28 <ev> *grumbles about having hardcoded an efi question despite having constructed the facilities to find the correct platform-specific ones*
<cjwatson> 01:28 <ev> tomorrow though
<Daviey> heh
<Daviey> cjwatson, At which point should we be considering a serious candidate for B1?  Are we switching to manual spins soon?
 * ev waves
<ev> yes, the build failure is due to a poorly constructed test
<Daviey> ev, do you have access to power and armel hardware to test this on?
<cjwatson> ev: testing a fix now
<cjwatson> Daviey: all platform team members do
<ev> cjwatson: brilliant
<cjwatson> Daviey: sometime today
<ev> we do? Is this on the wiki somewhere?
<Daviey> cjwatson, the porter boxes?  for installing?
<cjwatson> https://wiki.canonical.com/MachineOverview
<cjwatson> actually nowadays it's porter-$arch.canonical.com
<cjwatson> (except that $arch is ppc rather than powerpc, but ...)
<cjwatson> Daviey: sufficient to run the ubiquity test suite
<ev> oh nice
<pitti> ev: note that in the chroots you can do sudo apt-get install <package>
<ev> noted; thanks
<Daviey> cjwatson, ah.. ok..  The concern i have is that our team will not be testing the ISO's for power and arm... and i don't think the QA team are in a better situation.
<cjwatson> sure, separate problem from this.
<Daviey> ack
<cjwatson> can somebody review ubiquity?  the sooner the better so that we can get architectures back in sync
<Riddell> cjwatson: looking
<Riddell> accepting
<cjwatson> thanks
<iulian> Good morning.
<iulian> Could someone please also accept at-spi2-core?
<Riddell> iulian: accepted
<iulian> Ta.
<Riddell> iulian: I take it at-spi2 isn't going to be default in natty?
<iulian> Riddell: No, it's not, as far as I know.
<pitti> cjwatson: hm, http://cdimage.ubuntu.com/daily-live/20110329/ is still oversized, seems this was built before the -bn langpack drop was published?
<Riddell> I've dropped a language pack from the kubuntu live seed to get kubuntu undersized
<cjwatson> pitti: it would have been
<cjwatson> ought to wait for new ubiquity, though
<cjwatson> iulian: blah, sorry, I reviewed it and thought I'd accepted it along with -atk
<cjwatson> pitti: the builds were just from cron today
<pitti> ah; I got a tracker notification
<cjwatson> that wasn't me
<iulian> cjwatson: No worries. :)
<Riddell> I got a personal notification from a Jean-Baptiste asking for testing
<cjwatson> Riddell: that's jibel
<NCommander> morning all
<jibel> where are the images for u-headless, k-desktop and x-desktop on armel/imx51 ? I cant find them on cdimages
<ogra_> jibel, nobody implemented support for mx51 yet
<ogra_> (on the image builders or in livecd-rootfs)
<jibel> ogra_, oh well, skaet https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts should be updated accordingly
<bdrung> can you please reject this upload?
<cjwatson> bdrung: is it yours?
<bdrung> cjwatson: yes
<cjwatson> bdrung: done
<cjwatson> ah, ubiquity 2.5.32 has published now
<cjwatson> does anyone have anything else that needs to go into a respin?
<Daviey> bdrung, Just out of curiosity, what was wrong with it?
<cjwatson> (publisher is still running, so you have a few minutes to answer)
<bdrung> the debian changlog entry was missing
<Daviey> cjwatson, Just two moments, want to check if a package is seeded or not.
<Daviey> cjwatson, I'm happy.
<cjwatson> Daviey: which package?
<Daviey> cjwatson, keepalived .. rdepends of ipvsadm
<Daviey> Really not essential, to hold back a beta.. therefore not for a spin IMO.
<cjwatson> well, should I respin server or not?
<Daviey> cjwatson, yes please.
<cjwatson> server running now, since the Ubuntu DVDs are currently building from cron so live images have to wait for that to free up
<Daviey> super
<bdrung> ^ that's the correct one
<ScottK> jibel: I didn't get mx.51 sorted yet, but I'm hoping for permission to do it next week, so please don't delete them from the wiki page yet.
<ScottK> bdrung: Since it's on the Mythbuntu ISO, it should wait until after Beta 1 unless it's got a critical fix.
<ScottK> bdrung: If it does, please coordinate with the Mythbuntu folks and see if they want it for Beta 1.
<jibel> ScottK, deleting it was not my intention, just adding a note on the wiki to indicate the status of the image.
<cjwatson> ScottK,bdrung: it only changes versions of build-dependencies
<ScottK> jibel: OK. That's fine.
<ScottK> cjwatson: Right, I see that now.  I certainly can wait.
<cjwatson> (so doesn't seem like it can be critical)
<ScottK> Agreed.
<bdrung> ScottK, cjwatson: yes, this upload can be hold until after the beta. i wasn't aware that it's on the mythbuntu iso
<Riddell> ScottK: update for kubuntu mobile if you fancy reviewing ^^
<ScottK> Riddell: Waiting for the diff.
<Riddell> cjwatson: shall I remove desktop images from the ISO tracker?
<cjwatson> no particular need to remove them, but I'm rebuilding them
<skaet> cjwatson, ALL images being rebuilt now? (ie. should all on the iso tracker get marked as disabled for now)
<skaet> or just the desktop ones
<skaet> ?
<cjwatson> server wanted a respin anyway, so I guess the lot
<ScottK> cjwatson: Due to ^^^ if you can do Kubuntu last we might have that in by then.
<cjwatson> there weren't many tests completed on the tracker so I wasn't worrying about it
<cjwatson> ScottK: ok
<ScottK> It's only essential for Kubuntu Mobile, but if we can get it on the others, so much the better.
<cjwatson> Most images have Jockey, so that python-apt crash fix is a good thing to get in across the board, even aside from getting the installer in sync everywhere.
<skaet> cjwatson, ok,  have marked all actual images on the iso tracker as disabled for now.
<cjwatson> skaet: note that I'd already posted server
<cjwatson> (20110329.1)
<skaet> urk
<skaet> undoing.
<skaet> cjwatson, ok, server's back.   one question, would any of the changes made affect the upgrade tests?   Am wondering if the results are ok there, or if they need to be redone too.
<cjwatson> skaet: can never be certain, but I think a substantive effect on upgrade tests is unlikely
<skaet> cjwatson, thanks,  will suggest to jibel redoing them then with latest images can be deprioritized until after the rest of the testing.
 * pitti pats http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- I don't think we've ever been that good for beta-1
<cjwatson> mvo: update-manager saying beta - does that need to be in images, or is it in the server-side component?
<mvo> cjwatson: server side is good enough
<mvo> cjwatson: I do that now
<cjwatson> oh good
<cjwatson> Daviey: the server image is going to need a quick respin because I forgot to update the volume label to say Beta 1 rather than Alpha
<cjwatson> doing that right now
<skaet> Daviey, cjwatson - have marked 20110329.1 server as disabled
<ScottK> stgraber or highvoltage: Is ^^^ needed for beta 1?
<highvoltage> ScottK: ideally, yes, since it affects a UI change and should rather be done sooner than later
<highvoltage> ScottK, skaet: https://bugs.launchpad.net/ubuntu/+source/edubuntu-live/+bug/745000
<ubot4`> Launchpad bug 745000 in edubuntu-live (Ubuntu) "UIFe: Edubuntu installer Ubiquity Description (affects: 1) (heat: 6)" [Low,In progress]
<ScottK> I guess it depends a bit on where we are on respins.
<stgraber> It could be accepted and if we end up respinning, then we'll have it. I don't think it's worth a respin just for that.
<highvoltage> ScottK: ok. it's low priority so if if would cause any inconvenience, then it can certainly wait until after beta
<cjwatson> edubuntu is several hours off by way of respins
<cjwatson> accepting this won't cause an image building problem
<ScottK> I'll review it then.
<stgraber> thanks
<ScottK> Once LP makes the diff ...
<skaet> ScottK,  thanks - I thought it was just text change.
<Daviey> cjwatson / skaet, thanks
<ScottK> I'll find out once there's a diff.
<skaet> ScottK,  I put approved in there, but if its more than that and there's risk, please judge appropriately.
<ogra_> ScottK, i have some skeleton stuff for mx51 already btw, but will need more info about the HW and some testing on your side, lets sit down next week and take a look
<stgraber> it's supposed to just be a text change in debian/templates. If there's something else, feel free to reject as that'd be a mistake :)
<cjwatson> cdimage cron jobs disabled
<ScottK> ogra_: I'll be glad to.
<highvoltage> thanks ScottK
<stgraber> ScottK: http://launchpadlibrarian.net/67595025/edubuntu-live_11.03.3_11.03.4.diff.gz
<ScottK> Yep.  Got it.
<ScottK> Looks good.  Accepted.
<skaet> cool  :)
<stgraber> yeah! thanks
<slangasek> cjwatson: n/p (pango1.0)
<cjwatson> Ubuntu server, alternate, desktop posted
 * ScottK consideres that perhaps any test result that doesn't reference at least one new or existing bug should be considered invalid.  No upgrade is perfect.
<ScottK> (upgrade or install - the case I just did was an upgrade)
<doko> slangasek: that's what I'm uploading, doesn't have to be on the images. http://paste.ubuntu.com/586916/
<slangasek> doko: "$(dir $(libdir))" grabs the parent directory of $(libdir)?
<doko> yes
<slangasek> ok
<slangasek> looks like what we want, then
<doko> checked with a test build
<slangasek> module-init-tools (pre-)reviewed, looks good to me; where are we on image building?  This probably isn't critical enough to force a respin but it's definitely good to have if there's time
<cjwatson> somewhat into building
<tgardner> slangasek, huh, I was just about to drop a note to skaet about that very thing.
<cjwatson> (Ubuntu server, alternate, desktop done; Xubuntu alternate done; Xubuntu desktop building; others to come)
<slangasek> cjwatson: do you want to add m-i-t to your "if there's a chance" queue?
<slangasek> tgardner: we have a bot that notifies us of pending packages :-)
<cjwatson> sure
<ogra_> cjwatson, headless too please, once you get to armel
<cjwatson> everything is on the list
<ogra_> great, thanks
 * pitti wonders what the "free software only" option means these days -- is it just about adding restricted/multiverse apt sources? I don't think we actually install any non-free stuff by default any more, not drivers, not linux-firmware-nonfree
<pitti> (unless you tick the checkbox in the installer)
<doko> skaet, slangasek: rebuild tests started for armel, i386, amd64
<cjwatson> it controls the apt sources, yes
<cjwatson> it also suppresses the appearance of that installer checkbox
<cjwatson> so it's easy to build an installer image that doesn't offer non-free software
<slangasek> doko: great :)
<pitti> cjwatson: ah, thanks; but unless you tick anything in particular, a default install only has free stuff now, right?
<slangasek> doko: what's the link for the amd64/i386 archive rebuild?
<doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20110329
<doko> https://launchpad.net/ubuntu/+archive/test-rebuild-20110329-arm
<doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-arm-natty.html
<doko> the other overview page isn't there yet until wgrant wakes up, or we wake him up =)
<slangasek> no problem :)
<slangasek> doko: and lp:svammel should be ready now-ish, so we'll be able to use that for autofiling bug reports about build failures
<doko> does it catch duplicates?
<slangasek> doko: https://wiki.linaro.org/MattiasBackman/Sandbox/SvammelUsage,
<slangasek> , https://wiki.linaro.org/Platform/Infrastructure/Specs/BuildFailureBugFiling
<slangasek> the infrastructure team has said "yes" - I haven't tested it in a live fire situation yet :)
<cjwatson> pitti: I believe so
<jibel> cjwatson, can we reopen ubuntu dvds for testing ?
<cjwatson> no, but I can build them asap
<lamont> skaet: (et al): new launchpad-buildd that has natty-toolchain compatible detection of 64-bit pointers converted to ints rolling out sometime todayish
 * lamont tosses louvi back where it belongs
<skaet> lamont, can we wait until after this set of images for the release finishes building?
<skaet> cjwatson, ^^?
 * skaet feeling a bit worried about possible variable changes at this stage.
<lamont> skaet: the total change is to the regex where we look at the log and say "no, you didn't actually succeed like you think you did, you really failed"  I can certainly wait until beta is out before I push it out if you want
<lamont> the exposure is that things think they fail, and then die on users' machines with SIGSEGV/SIGBUS due to bad compiles that the compiler decides should be warnings, when they really are failures
<lamont> to make matters more amusing, they only sometimes fail on amd64, since the upper 32 bits of pointers are most frequently all zeros.  just not always
 * skaet feels a bit better after that explanation.
<cjwatson> I don't have a problem with that rollout - it won't affect CD image builds, anyway
<cjwatson> although I'd like any current builds not to be restarted in the process :-)
<skaet> cjwaton,  cool.   lamont can you wait until the current set is finished, and then we'll let you know when the coast is clear?
<lamont>   [ various ]
<lamont>   * ProjectGroup.products sort order and remove Author: comments.
<lamont>   * Fix some tests to not print stuff
<lamont>   * Make buildd pointer check regexes work on natty
<lamont>   * merge before rollout + text conflict patch by wgrant
<lamont> https://bugs.launchpad.net/launchpad-buildd/+bug/719162
<ubot4`> Launchpad bug 719162 in launchpad-buildd "[Natty] check-implicit-pointer-functions fails on natty, resulting possibly broken packages (affects: 1) (heat: 6)" [Critical,Fix committed]
<lamont> cjwatson: yeah - I'll wait for your all-clear, or beta
<lamont> because yeah, totally gonna just romp it all over the build farm when it rolls.
<skaet> ScottK, pitti, cjwatson, (and all interested) - have updated https://wiki.ubuntu.com/NattyReleaseSchedule  will broadcast out to u-d later today so would appreciate a quick review.
<slangasek> doko: I remembered that bug #741949 should also be fixed in eglibc; I'll cook a patch and send another upload to the queue and reject yours
<ubot4`> Launchpad bug 741949 in eglibc (Ubuntu Natty) (and 1 other project) "libc6-i386 co-installed with libc6:i386 breaks ia32-libs (affects: 1) (heat: 6)" [Low,Triaged] https://launchpad.net/bugs/741949
<doko> slangasek: ok, thanks
<cjwatson> I've queued up everything else for build apart from Kubuntu/armel (which is waiting for kdebase-workspace/armel to build)
<cjwatson> dinner
<ogra_> skaet, beta freeze on 11th now ?
<ScottK> skaet: I think it's fine.
<skaet> ogra_, yes that was the best compromise point
<ogra_> skaet, heh, k, i'm sure the unity-2d guys wont like that, they just confirmed the 13th with me today as final upload date for bugfixes
<ogra_> i'll forward the 11th
<skaet> thanks ogra_
<smoser> cjwatson, or slangasek or skaet could someone load the iso tracker with http://uec-images.ubuntu.com/server/natty/20110329/published-ec2-daily.txt
<skaet> smoser, to confirm - you're not expecting the links to work from the iso tracker, just using it to record the results?
<smoser> we need the amis populated into the table. (post-amis-to-iso-tracker)
<smoser> lp:~ubuntu-archive/ubuntu-archive-tools/trunk/
<slangasek> ScottK: ^^ should fix the armel problem
<skaet> smoser, ack.
 * skaet sees if she can get that script working again
<ScottK> slangasek: Cool.  At this point we should probably wait until after Beta 1 don't you think?
<ScottK> Riddell: ^^^
<slangasek> ScottK, Riddell: your call entirely
<ScottK> I guess it depends on how much we care about having some out of date packages on the images.
<ScottK> Riddell: ^^^?
<zul> is the nertboot images still being respun?
<cjwatson> netboot?  no
<cjwatson> that shouldn't have been marked as rebuilding
 * cjwatson goes to fix
<doko> doesn't start too good ... https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+builds?build_text=&build_state=failed
<slangasek> eh, binutils?
<slangasek> is that the same transient build failure as before?
<slangasek> bind9 is a multiarch failure, sigh
<slangasek> stupid manual build-time probing
<doko> we either need to link it statically, or change the soname
<doko> for every upload
<slangasek> so this is a general binutils problem?
<slangasek> apturl is weird; I swear I didn't break /usr/share/omf ;P
<doko> heh ...
<skaet> smoser, jibel,  there are some images in http://uec-images.ubuntu.com/server/natty/20110329/published-ec2-daily.txt that are not registered in the iso tracker.   Specifically looks like ap has split to northeast and southeast.
<skaet> jibel, can you make the changes to the isotracker to add the new ones ( northeast ) and clarify the others (add southeast)
<skaet> jibel_, ^^
<smoser> skaet, 'southeast' is "Asia Pacific"
<skaet> slangsek, cjwatson, smoser - am going to need to wait on jibel to get some numbers to use in the iso tracker (tablenumbers) before I can get the script working to pick up the new northeast images.
<skaet> smoser,  yup,  that's what's there now, so appears to be what isotracker is mapping to now.
<skaet> smoser, do you want me to edit out the northeast and publish the rest right now?
<skaet> then come back to them later when we hear from jibel?
<smoser> sure.
<ScottK> slangasek: Any thoughts on what we can do about Bug #744944?
<ubot4`> Launchpad bug 744944 in kdebase-workspace (Ubuntu Natty) (and 1 other project) "kdm is restarted during the upgrade to Natty . The user is disconnected from the session (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/744944
<ScottK> It's the PAM service restart that's doing it.
<slangasek> hum. has kdm regressed?
<ScottK> Something has regressed.
<slangasek> or maybe it doesn't play nicely after the switch to upstart
<ScottK> There's no debconf prompt for the restart.  Just happens.
<ScottK> I'm guessing if I'd done a command line upgrade I'd have been asked like I was for my server upgrade I did earlier today.
<slangasek> yes, that's per previous feedback that when doing upgrades with the default GUI upgrader, and the default set of services are running, there should be no prompting... but that was predicated on the assumption that the restart wouldn't break the GUI itself
<slangasek> so there are two possible solutions here
<slangasek> one is that kdm may have evolved to the point where a pam upgrade doesn't break it because the authentication is done by a helper process that's launched at authentication time; if someone can confirm that this is the case, we can drop kdm from the list of services to restart
<cjwatson> Kubuntu alternate, Kubuntu desktop, and Kubuntu mobile i386 posted
<slangasek> another is that we find a different "restart" option for kdm that's graceful and lets kdm reload libpam from disk, without restarting the current session
<slangasek> (the third option is to have to prompt on upgrade, but that's unsatisfactory; "is it ok to kill your session now?" is not a very elegant question)
<skaet> smoser,  can you check all except the northeast are accessible now?
<ScottK> slangasek: Is there some "It's an upgrade, don't restart KDM because they have to reboot at the end anyway" option?
 * skaet --> grab some lunch,  biab
<slangasek> ScottK: unless kdm implements 1), that carries the risk that if anything goes wrong during the upgrade and they're logged out, they won't be able to log back in to finish the upgrade and the system may not be in a bootable state at that point (because who knows what state the packages are in)
<slangasek> so I'd really prefer not to do that, from a robustness standpoint
<ScottK> Could that get us through beta 1?
<ScottK> Because currently getting logged out is a sure thing.
<ScottK> Riddell: ^^^?
<slangasek> yes, though at least you're guaranteed to be able to log back in to cleanly shut the system down
<slangasek> we can do that as a stopgap
<ScottK> Worst case you can switch to a VT and login that way.
<ScottK> Obviously not suitable for final, but for beta should be ~OK.
<slangasek> if someone who has kubuntu running could tell me if the main/parent kdm process has libpam loaded into memory, maybe we can short-circuit and just go with fix #1
<ScottK> I have it running.  How do I find that out?
<slangasek> lsof -p $pid | grep pam
<ScottK> Where $pid is kdm's pid?
<slangasek> yes
<ScottK> Returns nothing.
<slangasek> ok, then we should be able to drop it from the service restart list altogether
<slangasek> (not just as a temporary fix for beta)
<slangasek> are you looking to get this on images, or just in the archive for upgrades?
<slangasek> (if I have a little time, I have another multiarch-related upgrade fix I'd like to include)
<ScottK> I'd say just in the archive fo upgrades.
<ScottK> fo/for
<slangasek> ok; will get that together later today
<slangasek> ok for me to reassign the bug to libpam, or do you need a task open on kdebase-workspace to collect dupes?
<ScottK> slangasek: I think it's fine to reassing.
<ScottK> gn/ng
<ScottK> stgraber or highvoltage: I'd really like to get ia32-libs updated before beta, but it's in the Edubuntu package set ...
<stgraber> hmm, what ? :)
<stgraber> ia32-libs in the edubuntu package set ? fun
<highvoltage> ScottK: what's the update, btw?
<ScottK> http://launchpadlibrarian.net/67613251/ia32-libs_20090808ubuntu10_source.changes
<ScottK> Getting the newer drm in will allegedly help a lot with crashes from using an old drm in ia32-libs with flash.
<ScottK> Plus the more multiarch the better.
<ScottK> stgraber: I've assumed it's on your amd64 dvd.  Is that not the case?
<stgraber> ScottK: I just checked and we don't ship it :)
<ScottK> OK.
<stgraber> it's not in any of our .manifest or .list, so I'm not really sure how it ended up being in our package set
<ScottK> Then I'll treat it like unseeded Universe then.
<stgraber> ScottK: sure, go ahead !
<stgraber> cjwatson: ^ any idea ?
<ScottK> Done.
<cjwatson> desktop-gnome.build-depends_edubuntu_natty_amd64:ia32-libs                                 | ia32-libs                         | wine1.2 (Build-Depend)                     | Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>      |        33345206 |          143224
<cjwatson> looks like it's only there for build-depends
<stgraber> ok, I think I got it
<stgraber> we ship ttf-symbol-replacement which is a binary package of wine1.2 which itself build-dep on ia32-libs :)
<stgraber> so even if ScottK breaks ia32-libs it'd only be an issue if we rebuild wine1.2 and that'd only affect Edubuntu if ttf-symbol-replacement actually uses ia32-libs (which is very very unlikely for a font package)
<ScottK> Which is good since I already accepted it.
<slangasek> :D
<highvoltage> ScottK: in other words, please go ahead :)
<ScottK> slangasek: ^^^ Riddell and I decided to go ahead on avogadro.  Thanks again.
<slangasek> no prob
<cjwatson> does avogadro require a rebuild of anything?
<ScottK> If there's time re armel we'll want to get kdeedu and kdeplasm-addons in, but if we don't do them, we're no worse off.
<ScottK> It's more than a rebuild though.  Riddell has a kdeedu on the way.
<cjwatson> I haven't started any Kubuntu armel builds yet, since when I started this build sequence we were still waiting for stuff
<cjwatson> left to do: ubuntu-netbook (in progress), ubuntu-headless, mythbuntu, ubuntustudio, kubuntu dvd, edubuntu dvd
<cjwatson> that's at least three or four hours' worth
<Riddell> slangasek: do I need to check that pam issue with kdm upstream or are we happy that it's fine not to restart?
<slangasek> Riddell: if the kdm process doesn't have libpam loaded except when it's doing an authentication, then there's no risk unless we've missed that it's loaded persistently in some other process
<Riddell> groovy
<ScottK> lamont: Any chance of getting one or more of the dead armel builders brought back to life?
<slangasek> bamf uploaded, fixing multiarch-induced FTBFS; I expect this is fine to keep until after beta1
<kirkland> howdy release team ... I'm uploading cdebconf_0.154ubuntu2 to natty now;  this can be held until beta2, but I wanted to make sure it was in the queue asap
<kirkland> note that this change won't take affect until cjwatson rebuilds debian-installer after beta1 releases
<cjwatson> yep
<cjwatson> dear ubuntu-netbook, why are you taking >2h to build
<cjwatson> lamont: are acorn and sycamore actually doing anything useful?
<cjwatson> they aren't answering HTTP from chinstrap
<stgraber> cjwatson: I removed the release note item about LTSP not working. That's been fixed and tested on both alternate and Edubuntu by highvoltage.
<skaet> stgraber,  cool.  thanks
<ScottK> slangasek: No such luck on avogadro: https://launchpadlibrarian.net/67618143/buildlog_ubuntu-natty-armel.avogadro_1.0.1-3.2ubuntu1_FAILEDTOBUILD.txt.gz
<slangasek> yeah, just saw the mail
<slangasek> hrm, how did that happen
<slangasek> I'll see if adding libqt4-opengl-dev back is enough to fix this
<slangasek> (sorry, up to now it has only been build-tested on i386.. I figured I'd get a chance to do an armel build test before queue accept, but the panda is taking its sweet time)
<slangasek> maybe I have one of these by-faster-we-mean-slower SD cards of GrueMaster's
<ScottK> We're no worse of than we were before.
<highvoltage> I'm in the wiki page making some changes to the edubuntu parts... I'll be out again in a minute or so
<slangasek> if I get through two consecutive eglibc builds on amd64 in the time it takes me to get the avogadro *build deps* installed on my panda, I'm going to be sad
<slangasek> GrueMaster: what do you use for profiling SD card performance?
<slangasek> ScottK, Riddell: ^^ there's the pam fix for kdm; just the one change after all, apparently the other one I thought I needed was one I already included
<Riddell> slangasek: looking
<slangasek> kdm is still listed in the libc6.preinst for restarting - that's harder to confirm that we don't need to restart for
<ScottK> What's going to happen if it doesn't get restarted that's worse than it getting restarted in the middle of the upgrade?
<slangasek> hmm, this code seems to have bit rotted; only kdm, postgresql, and xdm listed for restart, and a bunch of code to handle other services not listed at all
<slangasek> ScottK: as long as the user knows how to get to a VT, nothing - I'm musing out loud about how to fix this overall, we can certainly apply a stopgap for beta
<ScottK> OK.
<skaet> smoser,  jibel's added the test cases.   please join us in #ubuntu-testing if there are still issues.
<smoser> ok. i'll be filling the results out tomorrow when jamespage is around.
<Riddell> slangasek: accepted
<slangasek> cheers
<GrueMaster> slangasek: Mainly time.  I see how long it takes to flash an image to my SD from my desktop, and also how long it takes to boot or other tasks.
<slangasek> ok
<GrueMaster> Not a very efficient method, but definitely visible between different SD cards.
<GrueMaster> For builds, you should at a minimum use a USB based chroot.
<GrueMaster> I haven't timed an NFS root yet.  Maybe next week.
<slangasek> I don't have a USB disk hooked up, this was intended to be a quick one-off :)
<GrueMaster> What is the timeframe for new armel images?
<cjwatson> netbook just finished
<cjwatson> headless is running
<cjwatson> netbook took two hours or so ...
<cjwatson> I've posted netbook (omap3/omap4)
<cjwatson> away for an hour or two
<skaet> slangasek, cjwatson,  new version of post-amis-to-iso-tracker.py uploaded (rev 235) has northeast images in testcases now.
<slangasek> great :)
<stgraber> /w/win 33
<stgraber> oops :)
<pitti> good night
 * slangasek waves to pitti
<cjwatson> ubuntu-headless posted
<cjwatson> (omap3/omap4)
<lamont> cjwatson: sycamore/acorn both answer to ssh - seeing what they're up to
<lamont> ScottK: yeah, it's been 8 hours since I did it last, it may well be time to smack them agvain
<lamont> cjwatson: both are happily idle
<lamont> ScottK: in theory, the 4 are back.  (being quick on the recovery is not rewarded, since then I have to actually kill the build that is STILL RUNNING)
<doko> lamont definitely needs a smack bitch
<lamont> doko: if only there were some way that we could encapsulate the process in a programming language.
<lamont> ...
<GrueMaster> cjwatson: Can you (or someone) make some adjustments ot the iso tracker for the headless and netbook armel images?
<GrueMaster> The Netbook images really should be Ubuntu Arm Preinstalled [omap3|omap4]
<skaet> GrueMaster, is it just the labeling?  or something with the mapping?
<GrueMaster> Both.
<skaet> GrueMaster, jibel is the one who can help here, and if he's offline bdmurray
<GrueMaster> I think the Netbook images are from Lucid and earlier, so they don't map correctly.
<skaet> start the discussion off in #ubuntu-testing
<GrueMaster> Ok.  Moving on.
<skaet> joining you....
<hggdh> slangasek: I just ran a server-amd64 minimal install, and got a d-i loop. Right now this is just a heads-up, I am re-running it t confirm
<hggdh> (the loop is due to a segfault in a d-i lib)
<slangasek> hggdh: are you meaning to flag skaet rather than me, or is there specific action you think I should take here?
<slangasek> hopefully it's not a multiarch-induced segfault, though I guess that's not impossible :)
<hggdh> slangasek: I did flag skaet, and she asked me to flag you :-)
<slangasek> ok :)
<hggdh> slangasek: all other server installs seem to be kosher
 * skaet just wanted it on slangasek's radar in case it was a multiarch-induced segfault... ;)
<slangasek> man, I hope not :)
<skaet> me too
<hggdh> slangasek: skaet: I think I know what caused it -- installing a minimum system (real) on a VM, instead of installing a minimum VIRTUAL system on a VM
<hggdh> I will repeat it later, but this will be a normal bug, not an ISO test one
 * skaet feels better...    
<skaet> thanks hggdh
 * hggdh is starting to redeem self with skaet ;-)
<skaet> lol
<doko> it's good to be able to blame anything on multiarch ;-P
<slangasek> :-)
<cjwatson> lamont: thanks, see #is though, it sorted itself out not that long after I asked
<cjwatson> GrueMaster: yeah, I don't have that level of iso tracker access, sorry
<GrueMaster> Neither do I.
<cjwatson> GrueMaster: please can you specifically *not* make them "Ubuntu Arm Preinstalled [omap3|omap4]", though
<GrueMaster> Ughh.
<cjwatson> GrueMaster: that naming is a horrendous pain in publish-image-set.py
<cjwatson> the closer it corresponds to how cdimage names things, the smoother the release publication process can be
<GrueMaster> Then someone needs to delete them from the testcases and fix the netbook ones to map properly.
<lamont> cjwatson: figures
<cjwatson> publish-image-set.py scrapes iso.qa with a big pile of regexes and uses that to output publish-release commands that we use when we're ready to release
<GrueMaster> We run into this every release since early maverick.
<cjwatson> the "Ubuntu Arm" stuff was completely out of sync with everything else there, and a massive headache
<GrueMaster> That's what we do best.  :P
<cjwatson> fixing up the testcase mappings seems to make more sense than changing the names
<GrueMaster> Agreed.  Just no one seems to care about the tracker except during release week.
<cjwatson> hggdh: having trouble seeing how that could make a difference ...
<cjwatson> hggdh: there are differences in how those two preseed files set up the target system, but no segfault in d-i can be explained away by that
<cjwatson> hggdh: do you have more details on the segfault?
<hggdh> cjwatson: I do not understand either, but now it is working; I will get back to it when I end the ISO tests
<cjwatson> what I mean is that installing a minimum system (real) on a VM is a valid test
<hggdh> cjwatson: not right now, no details, except it looped
<cjwatson> I guess that's a better way to put it
<hggdh> hum
<cjwatson> the virtual option is optimised for VMs, rather than being the only valid thing to choose on VM
<hggdh> then this would be a failure
<cjwatson> s
 * lamont EOD afk
<hggdh> OK, I will repeat it nwo
<hggdh> now
<cjwatson> mythbuntu and ubuntustudio posted
<jibel> GrueMaster, I cant do this instantly because the name/path resolution is hardcoded in the tracker.  please file a bug against ubuntu-qa-website and I'll see what can be done for next milestone.
<cjwatson> skaet: do you know why Edubuntu upgrade tests are disabled?
<cjwatson> looks like just those plus Kubuntu DVD, Edubuntu DVD, and a bunch of Kubuntu armel builds to go
<cjwatson> Kubuntu DVD is in progress, will take a while though
#ubuntu-release 2011-03-30
<skaet> cjwatson, had them disabled while waiting for the images to build, since no one had started them.   Have gone in and re-enabled.
<skaet> I have to go out for a couple of hours, but will be back on line later tonight.
<cjwatson> ok, though upgrade tests are basically unrelated to image builds :)
<cjwatson> I'm off for a while too.
<skaet> I'll check and see if the images have emerged when I get back.
 * skaet figures cjwatson is overdue to sleep, actually.   ;)
<skaet> biab.
<cjwatson> kubuntu dvd posted
<GrueMaster> cjwatson: Have the kubuntu arm desktop & mobile images been spun up?  I've been asked to test the omap4 images after I finish our normal images.
<cjwatson> no, about to do that after the current build finishes (which shouldn't be long)
<GrueMaster> Current build?
<cjwatson> cdimage has been building stuff solid for a good seven hours.
<cjwatson> and Kubuntu armel wasn't ready when I kicked all that off
<cjwatson> Edubuntu DVD posted
<GrueMaster> I thought they all ran in parallel.
<cjwatson> nope.
<cjwatson> kubuntu armel building now, followed by kubuntu-mobile armel
<GrueMaster> ok
<cjwatson> there are some potential parallelisation improvements, and I do occasionally do stuff in parallel deliberately, but running *everything* in parallel isn't likely to be one of them
<cjwatson> that'd be a good way to kill the livefs buildds
<cjwatson> Kubuntu desktop armel failed
<GrueMaster> figures
<cjwatson> Kubuntu mobile armel not looking happy eitherbso far
<cjwatson> *so far either
<GrueMaster> Ok.
<GrueMaster> What's the issue?  Package missing?
<cjwatson> oh, it's because kdebase-workspace/armel STILL hasn't built
<cjwatson> ... yes it has, must just not quite have published
<GrueMaster> sheesh.
<cjwatson> ok, that suggests I can retry shortly
<cjwatson> just over a 10-hour build, that ...
<cjwatson> I didn't even think to check
<GrueMaster> Where are the build logs?  I am not seeng anything for kubuntu armel on http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/
<GrueMaster> Not even logs for last week's images that I have.
<cjwatson> there seems to be something wrong with the mirror job
<GrueMaster> ah
<cjwatson> I'm having some trouble seeing what; maybe now isn't the time to investigate
<GrueMaster> Not critical to me.  I was just curious.
<cjwatson> 'w3m http://acorn.buildd/~buildd/LiveCD/' and 'w3m http://sycamore.buildd/~buildd/LiveCD/' from a login on people.c.c will get you them, though
<cjwatson> (which is not ideal because it's internal-only)
<cjwatson> kubuntu-mobile-omap4 seems to be getting somewhere
<cjwatson> so you may at least get that in the not horribly distant future
<GrueMaster> Only so long as it completely interrupts my evening.  :P
<cjwatson> dude, it's 2:50am here, don't talk to me about evenings.
<GrueMaster> heh.
<GrueMaster> I've been there.  More often than I care to remember.
<ScottK> ^^^ was another syncpackage upload.  I mailed the uploader asking them to file a sync request.
<ScottK> (and rejected that one)
<cjwatson> GrueMaster: Kubuntu mobile armel+omap4 posted
<cjwatson> I'm having another go at building Kubuntu desktop armel+{omap,omap4} and Kubuntu mobile armel+omap.  Please can somebody else check in a while whether they've built and post them if so; I need some sleep.
<skaet_> cjwatson, am back on now.   if you're still up,  go sleep.    I'll stay up until pitti gets on.
<skaet_> kubuntu mobile armel+omap is available - 20110330 image
<ScottK> GrueMaster: ^^^
<GrueMaster> ScottK: Yep, got them pulling now.
<ScottK> Cool.
<skaet_>  GrueMaster,  ScottK,  kubuntu desktop armel + {omap, omap4} has come off the builds.
<ScottK> OK.
<GrueMaster> Thanks.  Pulling now.
<skaet_> jibel, Gruemaster,   we're missing an ISO tracker entry for Kubuntu Desktop armel omap4 - but the image is there.
<skaet_> 20110330
<skaet_> GrueMaster, ^^
<GrueMaster> Yep.
<GrueMaster> I'm going to pull them now and just do a spot test.  I'll do more tomorrow if they boot.  If not, I'll let everyone know immediately.
 * GrueMaster hates getting old.  Can no longer do 20 hour work days.
 * skaet_ understands exactly what GrueMaster means... :P 
<skaet_> Thanks GrueMaster.   I'll stay on until I hear the results of the spot tests.
<GrueMaster> skaet_: I am looking at an ugly screen that may have appeared in the ubuntu-netbook omap4 images over the weekend (no daily images for most of last week).
<GrueMaster> Doesn't look like a critical respin issue, but is an ugly mark.
<GrueMaster> It can be worked around with a manual reboot in the preimage config process, easily documentable.
<GrueMaster> Not sure how it will affect the kubuntu images.
<skaet_> thanks Gruemaster..
<GrueMaster> .http://members.dsl-only.net/~tdavis/panda-20110328.jpg is what it looks like.  Reset will come up clean and launch oem-config properly.  Doesn't reappear after that.
 * GrueMaster hates these types of issues.
<GrueMaster> Doesn't affect omap images nor headless.  Very odd that it only is hit once during first boot.
<skaet_> yeah, that definitely will need its workaround documented.
<GrueMaster> I'm more worried about finding the cause and filing a bug.
<skaet_> hopefully ogra_ may have some insight, and see if they can figure it out.
<skaet_> post the bug number here when you've got it filed please.   suspect that when pitti comes on line, he will be interested as well.
<GrueMaster> Thankfully I keep a running history of daily images between releases so I can backtrack.
<skaet_> :)
<pitti> Good morning
<skaet_> heya pitti,  good morning.
<GrueMaster> Hey.
<skaet_> All images that were kicked off by cjwatson have been put in the tester.
<GrueMaster> So far, I am seeing bad screen corruption on the Ubuntu-netbook and Kubuntu-desktop images on omap4.  It appears to be resolution related.
<pitti> skaet_: any catastrophes so far?
<skaet_> pitti,  arm and/or kubuntu is problematic based on the rebuilds. and what Gruemaster is finding out on the arm side.
<pitti> skaet_: the bits on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html, or more recent regressions?
<GrueMaster> I'm leaning heavily towards a kernel issue.  This is a new kernel since Saturday (i.e. no real testing) and is the first .38 kernel for omap4 that reenables HDMI.
<GrueMaster> At least with the omap4 images.
<pitti> argh, fglrx is on the DVDs; I'd love to accept it now, so that people actually can get a working driver right after an upgrade, does that sound ok?
<pitti> skaet_: ^
<skaet_> pitti,  I'm sympathetic.  /me thinking about implications
<pitti> skaet_: it's just in ship, not in the live session
<rsalveti> GrueMaster: did you remove the old dvi arguments?
<pitti> but it's rather useless on the DVD right now, as it's uninstallable (i386) and breaking your system (amd64)
<rsalveti> don't know if ogra_ already removed it
<pitti> so I'd rather have a working versino in the archive, in case people try it
<skaet_> pitti,  if the dvds haven't started testing yet, mark them for rebuild and go ahead.
<pitti> it's disabled in jockey, but still, people could install it manually
<GrueMaster> rsalveti: I'll check, but they don't work with the dvi port anymore.
<rsalveti> GrueMaster: I tested this kernel and it worked fine with my monitor, but not during installer
<pitti> skaet_: I don't want to rebuild DVDs actually
<skaet_> ??
<rsalveti> GrueMaster: hm, it should work
<rsalveti> GrueMaster: can you check the package version?
<GrueMaster> rsalveti: Same here with a 20110321 upgraded image.
<rsalveti> could happen that the meta package is not updated
<GrueMaster> rsalveti: linux-image-2.6.38-1206-omap4 2.6.38-1206.9
<rsalveti> not the latest
<GrueMaster> From the manifest.
<GrueMaster> There is a new one in the pool since 3 hours ago?
<pitti> skaet_: DVDs were fully tested already, I don't think this is important enough to drop that; people can install fglrx from the archive instead of from the DVD
<rsalveti> GrueMaster: 2.6.38-1207.10 was published at 26
<GrueMaster> Grrrrrr.
<skaet_> pitti,  yup,  go ahead and accept.
<pitti> skaet_: ack
<rsalveti> GrueMaster: could be lack of meta update
<GrueMaster> typical.
 * skaet_ read the backscroll, and put 2+2 together as you explained.   
<rsalveti> yup
<pitti> skaet_: FYI, need to disappear for ~ 30 min for a vaccination, bbl
<GrueMaster> Ok, get it updated so we can reroll armel images and start over in the morning.
<rsalveti> beagle one seems fine here, at least I could install and open the unity-2d interface
<GrueMaster> omap images are running fine.
<GrueMaster> Only omap4 images have issues (headless works fine also).
<slangasek> ^^ wanted for kubuntu upgrades to beta; without it, users get a nasty shock when kdm restarts and destroys their running session
<slangasek> (eglibc)
<slangasek> nothing in there that needs to be on the ISOs though
<rsalveti> GrueMaster: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty-meta.git;a=commit;h=55b7429412381840311673838dedf7b6f8afc104
<rsalveti> GrueMaster: yup, meta needs update
 * GrueMaster is getting really tired of these last minute rerolls for armel during release week.
<skaet_> pitti, ^^ can you help with the rerolling the armel images when bits are ready.
 * skaet_ needs to go zzz now
<GrueMaster> I need to call it a night.  I can only go 16 hours between beauty sleep.  Night skaet_.
<skaet_> Thanks GrueMaster,  night
<rsalveti> yeah, also going afk, asked at #ubuntu-kernel for meta update
<rsalveti> hopefully someone can update it soon
<GrueMaster> I'll look for new images in the morning.
<GrueMaster> again.
<pitti> skaet_afk: sure
<pitti> hm, which bits are needed for the armel images?
<pitti> ah, omap meta package, sure, will look
<pitti> there's no upload, though
<ogra_> hmm, the kernel team seems dead today
<ogra_> pitti, i just uploaded a fix for flash-kernel, since we will have to re-roll for linux-meta anyway, that can as well go in
<ogra_> (fixes bug 744862)
<ubot4`> Launchpad bug 744862 in libdebian-installer (Ubuntu Natty) (and 3 other projects) "/proc/cpuinfo strings for OMAP4 devices changed with 2.6.38 kernels (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/744862
<pitti> ogra_: do you know if someone is on linux-meta?
<pitti> omap-meta, I think?
<ogra_> cooloney is
<ogra_> but he cant upload and seems to wait for tim
<pitti> you or I cannot sponsor this?
<pitti> ogra_: flash-kernel accepted
<ogra_> thanks
<ogra_> i'm not sure how the pocesses in the kernel team are, probably he waits for a review of a team mate or something
<ogra_> he went for dinner now, so i cant ask him
<cjwatson> ogra_: which rerolls are we talking about heree?
<cjwatson> *here
<cjwatson> I missed some scrollback due to going over my ISP's usage cap this month
<ogra_> cjwatson, armel omap4 at least
<ogra_> cjwatson, new linux paxkage was uploaded but no new meta, so the display is broken
<ogra_> (the new kernel fixes it)
<cjwatson> which armel omap4?  there are >1
<ogra_> all that use graphics (but for consistencys i would also re-roll headless)
<cjwatson> ok, please let me know when rerolls should start
<ogra_> will do, still waiting for the kernel team
<doko> cjwatson: please could you accept one more g*-4.4 package? the buildds are free
<cjwatson> which one?
<doko> say, gcj-4.4, shortest build time
<doko> then gnat-4.4, then gcc-4.4
<cjwatson> are the dependencies such that this will not cause any uninstallability if architectures are out of sync?
<cjwatson> we still have at least a couple of respins to come
<doko> no
<doko> gdc-4.4 was a ftbfs, gcj-4.4 needs the update for multiarch
<mvo> is there going to be a respin of ubuntu desktop ? I have a software-center upload that switches from reviews.taging.ubuntu.com to production (the production instance is there now finally!)
<mvo> not critical as we can just redirect from staging -> production for a while but would be nice to have (if we respin anyway)
<cjwatson> not planned at the moment
<mvo> ok, thanks
<cjwatson> software-center is arch: all, though, so it's safe to accept in case we do respin - done
<mvo> thanks!
<ogra_> pitti, omap4 meta should hit the archive in a minute, please approve
<pitti> yippie
<ogra_> :)
<pitti> ogra_: done; let's hope it builds before the publisher run
<ogra_> yeah
<ogra_> shouldnt take long though
<ogra_> \o/
 * tgardner wishes all his packages went that fast.
<ScottK> Any objections of I go ahead and accept ia32-libs?
<pitti> ScottK: oh, I just did so, as it isn't on any image
<ScottK> pitti: OK.  That would be a good reason for me not to do it.
<ScottK> Thanks.
<pitti> ScottK: hoping it'll unbreak flash :) (yesterday's update broke it)
<ScottK> Yep.
<ScottK> My view has been if you care about flash working you ought to be on i386 (until multiarch gets done).
<pitti> ScottK: right, but when looking at how much discussion bug 723831 caused, I'd rather see that working :)
<ubot4`> Launchpad bug 723831 in ubiquity (Ubuntu) (and 2 other projects) "Installer â The option to 'install third-party software' when installing Ubuntu should be selected by default (aka "make Youtube work") (affects: 6) (heat: 54)" [Wishlist,Won't fix] https://launchpad.net/bugs/723831
<ScottK> Definitely.
<pitti> ogra_: in accepted, good
<ogra_> pitti, awesome, so we can re-roll ?
<pitti> ogra_: no, needs publishding first
<ogra_> ah, right
<pitti> ^ don't worry, this was a reject (I reuploaded because there was another patch to sponsor)
<ogra_> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-ti-omap4/ doesnt look like we made the last publisher run :(
<ogra_> cjwatson, omap4 rebuilds can be started, linux-image-omap4 2.6.38.1207.6 just hit the archive
<cjwatson> ogra_: right
<NCommander> cjwatson: please build headless first
<ogra_> NCommander, ?
<NCommander> It takes a lot less time, and if it fails to build, we know the other ones will
<NCommander> ^- ogra_
<ogra_> that can go last
<cjwatson> too late.
<NCommander> ogra_: it can go first
<cjwatson> lamont: can you kill whatever's running on acorn+sycamore, please?
<cjwatson> livefs jobs
<ogra_> NCommander, we try to fix a graphics bug
<ogra_> how will headless help here ?
<cjwatson> I c&ped too much by accident
<NCommander> ogra_: I just talked to GrueMaster about it, he can test headless while the others are building. Headless takes ~30m, desktop takes at least 2h lsat time I built them by hand
<ogra_> NCommander, nothing will fail to build, we replaced two packages
<ogra_> desktop takes pretty exactly 90min on antimony
<ogra_> +/- 2-3min
<GrueMaster> ogra_: Headless can be testing while the others are downloading.
<GrueMaster> It is small and fast.
 * ogra_ sighs and goes afk
<cjwatson> this is all moot unless lamont comes back
<GrueMaster> thank you.
<ogra_> feel free to take over from Â´me now
<NCommander> ogra_: it takes longer than that cause we also have to do compression step which takes a good 30 minutes
<cjwatson> since I accidentally started a netbook build
<cjwatson> (and ctrl-c'ed it again accidentally, so it's running unsupervised)
<NCommander> cjwatson: ugh :-(. We really need a kill image script on antimony
<ogra_> GrueMaster, did you notice that the package removal bits in oem-config change teh debconf ui color to unreadable in headless ?
<ogra_> do we have a bug for that ?
<slangasek> pitti, ScottK: you mean you aren't all using my ppa and *have* flash working with multiarch?! ;)
<GrueMaster> I did not notice.  I was too consumed with trying to figure out the graphics issues.
<pitti> slangasek: I of course have run your PPA for the last five years! I'm exclusively worried about our users here, of course :)
<ScottK> slangasek: No.  I use i386 on desktops.
<pitti> slangasek: jokes aside, it actually works for you now? awesome
<slangasek> ScottK: ah, heh
<slangasek> pitti: yes, http://pastebin.ubuntu.com/586924/
<slangasek> but you can't upgrade libglx-mesa-dri from that ppa or it wants to remove your x server ;)
<pitti> slangasek: you mean you aren't already running wayland? :-)
<slangasek> hah
<Riddell> cjwatson: the kubuntu mobile images from yesterday still have kdm and plasma-desktop on them, but kubuntu-mobile is no longer a Task of those packages, maybe they were rebuilt too soon, could we get new images if you agree?
<cjwatson> Riddell: is that arm?
<doko> cjwatson: I think gcc-4.4 can be approved (arm is still busy, but ...)
<slangasek> doko: hi, so what happened that required a gcc-4.4 reupload?
<slangasek> or do you mean gdc-4.4 here?
<doko> slangasek: merging of hrw's cross changes, and serving as a basis for the gdc-4.4 (FTBFS), gcj-4.4 (wasn't multiarch ready) and gnat-4.4
<slangasek> ok
<Riddell> cjwatson: i386 in my case
<GrueMaster> Riddell: we are respinning the omap4 images anyways (kernel issue).
<cjwatson> Riddell: do you think it's beta-critical?
<Riddell> cjwatson: for kubuntu mobile it is, it's not our most important flavour but I don't think we lose anything by rebuilding now
<cjwatson> ok
<cjwatson> building
<skaet_> GrueMaster, Ubuntu ARM Preinstalled (omap3+omap4) are the 20110329 images - are they the ones being rebuilt right now?
<skaet_> cjwatson, ^^ ?
<GrueMaster> I hope so.  The kernel meta landed only a few hours ago.
<cjwatson> skaet_: I'm in the middle of posting
<cjwatson> ubuntu arm preinstalled omap4 posted
<GrueMaster> Thanks.  Pulling.
<skaet_> cjwatson,  awesome.  :)
<cjwatson> I accidentally rebuilt omap3 as well, but you can ignore that
<cjwatson> we can just publish the old one if it's already been tested?
<cjwatson> the request was just to respin omap4
<skaet_> cjwatson,  it doesn't have any test results beside it, so may as well put both up.
<GrueMaster> As long as there are no other package changes, I'm good.
<cjwatson> I have no idea whether there are other package changes :-)
<GrueMaster> skaet_: I hadn't posted results yet (waiting for tracker issues to get resolved).
<GrueMaster> cjwatson: I can check.
<skaet_> ahh,  ok GrueMaster
<GrueMaster> The only package changes I can see that may be relevant are pam and software-center.  Need to find out why they were updated post-freeze.
<cjwatson> I approved software-center
<cjwatson> it switches to using a production server rather than staging
<GrueMaster> Ah.  Not a big deal for armel I would think.
<GrueMaster> (not sure how it works).
<cjwatson> anyway, if you've already tested omap3, there's no point in revving for the sake of it, I think
<GrueMaster> But for the limited user base, I'm not sure it is a major concern for beta.
<cjwatson> you have enough to do
<GrueMaster> Heh.  Yes I do.  :P
<skaet_> cjwatson, Gruemaster - agreed.  If testing already done, its lower priority to retest with new image.
<GrueMaster> cjwatson: While I pull the netbook image down, can you start respin of headless, kubuntu, and kubuntu-mobile for omap4?
<cjwatson> already did
<GrueMaster> Thanks.
<cjwatson> headless is building right now
<cjwatson> and the others are queued in that order after iti
<GrueMaster> Excellent.
<cjwatson> in parallel, kubuntu-mobile/i386 is building as Riddell requested
<cjwatson> I'm going out for a while and would appreciate it if people would post those as they complete
<cjwatson> again, no need to post omap3
<skaet_> cjwatson,  will keep an eye on it.
 * skaet_ and won't post omap3 ;)
<doko> slangasek: hmm, did you run your script on the old test rebuild?
<slangasek> doko: no, I ran it against test-rebuild-20110329-arm + test-rebuild-20110329 + the main archive; so anything that's ftbfs in natty also got a bug filed
<doko> ok
<lamont> cjwatson: are acorn/sycamore still an issue? (covered tab, sorry)
<cjwatson> lamont: nope, thanks
<cjwatson> don't kill what's there now :)
<lamont> hence the question
<doko> *cough* perl ftbfs with multiarch
 * slangasek mumbles
<slangasek> assign me a bug? :)
<highvoltage> oh crap I didn't quite finish all the Edubuntu ubiquity slideshow slide pictures (not that it's particularly noticable)
<highvoltage> (I guess I'll just try to get an exception for them after beta release)
<doko> slangasek: done. still fighting with nfs-utils ...
<skaet_> kubuntu mobile i386 20110330 posted
<skaet_> Riddell, ^^
<skaet_> Gruemaster, cjwatson,   headless armel omap4 posted.
<GrueMaster> ok.  Sorry, had a phone call.
<GrueMaster> I'll pull it now.
<skaet_> :)
<skaet_> GrueMaster, Riddell, ScottK,  kubuntu desktop omap4 20110330.1 posted
<GrueMaster> ok
<skaet_otp> cjwatson, slangasek,  I think that the only one left to emerge now is kubuntu mobile armel omap4.   Anything else that may have been overlooked?
<doko> slangasek: please accept python*-stdlib-extensions, afaics, not on any CD's
<slangasek> looking
<cjwatson> kubuntu-mobile armel+omap4 posted
<highvoltage> there. edubuntu is all tested (shew).
<highvoltage> (with very few and small bugs this time, at least)
<skaet> highvoltage.  :)
<skaet> highvoltage,  thank you - that sort of nice news is always most welcome.  :)
<highvoltage> skaet: only a pleasure!
<highvoltage> skaet: there's 3 low-risk fixes that, if we apply them when the archive opens again, we'll have 0 edubuntu-specific bugs for the 2nd beta if nothing changes (that would be kind of nice)
<matttbe> Hello,
<matttbe> I'm part of the Cairo-Dock team and I want to update Cairo-Dock packages on Ubuntu. I've opened two bug reports (cairo-dock and its plug-ins) one month ago (before the FF) with two linked branches: https://code.launchpad.net/bugs/723994 & https://code.launchpad.net/bugs/723995
<ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu Natty) (and 1 other project) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 16)" [Wishlist,New]
<matttbe> I've contacted a few people on IRC but now I really don't know what can I do...
<skaet> matttbe, this is a good place to bring it up,  however right now we're in last stages of getting beta images ready.
<matttbe> skaet: yes I know but what do I have to do?
<skaet> matttbe, if you could bring it up again on Friday or next monday,  if it hasn't been taken care of before then,  that would be much appreciated.
<skaet> has the ubuntu-release team been subscribed to the bugs?
<matttbe> skaet: ok thank you!
<matttbe> yes
<skaet> cool,  it should be in the queue then, and as soon as the load lightens it should get assessed.
<matttbe> skaet: and it seems that my sponsor has subscribed you :)
<skaet> matttbe,  thanks for flagging it.   I had noticed cairo dock has been on the bug list, but hadn't had the bandwidth to dig in yet.
<matttbe> skaet: no problem but I hope that these packages will be updated before the beta2 :)
<cjwatson> reposting a few desktop images to relabel them and avoid a Wubi bug
<slangasek> testing a fix for the perl multiarch ftbfs now; have the package building, want to see if it also fixes the ftbfs of perl revdeps
<doko> \o/
<slangasek> cool, libuuid-perl fixed with a fixed perl
<slangasek> uploading perl
<doko> can't approve
<slangasek> that's ok, someone will get it eventually :)
<slangasek> doko: have the buildds finished the rebuild for main on x86, or is there still more coming?
<doko> slangasek: same answer as to robbiew (which he didn't like =) https://launchpad.net/builders/  i386 at s, amd64 at p for main, universe not yet started
<robbiew> heh
<robbiew> slangasek: that means "no"
<slangasek> :D
<doko> sorry, couldn't resist ;)
<slangasek> doesn't bother me any :)
<slangasek> thbbt, why does reportbug not let me set usertags for multiple users
<doko> had to convince soyuz to get populate-archive from 10h+ to 2h
<slangasek> heh
<slangasek> doko: aside from perl ftbfs being scary (but now fixed), are there any other multiarch pain points that you're aware of currently?
<slangasek> the desktop stuff seems to be getting sorted (or already is)
<slangasek> bind9 is multiarch, I bet postfix is also
<cjwatson> python-apt breakage makes it painful to use on the desktop, so I turned it off
<cjwatson> (bug 740072)
<ubot4`> Launchpad bug 740072 in python-apt (Ubuntu Oneiric) (and 1 other project) "apt.Cache.__iter__ breaks when multiarch is enabled (affects: 2) (dups: 1) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/740072
<slangasek> yep
<cjwatson> (ah, you knew about that)
<slangasek> sadly I don't foresee us getting that fixed in time for natty
<slangasek> and I have 10 libs in ppa that are needed before you can actually install any useful packages with it on the desktop (flashplugin)
<doko> slangasek: fixed the python stuff
<doko> now seeing seabios
<slangasek> and I don't think you guys want me to transition mesa post-beta ;)
<doko> slangasek: I don't care if you provide .so links in the expected location
<doko> s
<slangasek> sure; that's better for backwards-compatibility, but it also makes the packaging more complex and error-prone
<slangasek> so I'd rather not, as much as I would've liked to have it in
<doko> I know, but it might be worth having such a thing for debian multiarch
<slangasek> anyway, flashplugin without nspluginwrapper is also not the most useful thing - so I'm planning to draw the line here and close out the FFe bug
<slangasek> doko: I think debian multiarch is going to go even further in the first iteration, and have multiarch -dev packages early - and those definitely can't have compat symlinks in /usr/lib
<slangasek> (this, after all, is what addresses the cross-compiling use case, which is what Linaro and Emdebian folks are both primarily after)
 * doko is happy to blame debian for multiarch
<slangasek> heh
<slangasek> s/blame/credit/ ;)
<doko> uploaded fixed gcc-4.4
<slangasek> thanks, will review
<doko> I'm still bad with politics, sorry
#ubuntu-release 2011-03-31
<skaet> slangasek around?
<GrueMaster> Ugh, these SD cards are freaking slowww.  oem-config has been running for 30 minutes on my beagleXM.  Also need to restart the kubuntu-moble omap4 image testing (SD corruption).
<GrueMaster> Almost done booting into kubuntu desktop on my beagleXM.  Past the login screen, just waiting for something to happen.
<skaet> GrueMaster, thanks
<GrueMaster> I am almost finished with armel testing.  The biggest time consumer is filing bugs and adding to the tracker.
<GrueMaster> I need to take a break (dinner and minor down time).  Will be back in an hour to finish kubuntu-mobile on omap4.
<GrueMaster> I want to fail kubuntu-mobile on armel, but iso tracker requires a bug number.  Problem is there is no display manager in the image.
<ScottK> GrueMaster: nodm is by design.
<GrueMaster> Well, I don't think console only is by design.  Otherwise you might rather run headless.
<ScottK> True.
<GrueMaster> Am I miising a trick to running this?
<GrueMaster> (bad typing excluded)
<ScottK> Dunno.  I'd ask rbelem or apachelogger on #kubuntu-mobile.
<ScottK> I do know it's supposed to have nodm instead of kdm so you don't have to login.
 * ScottK needs to sleep.  Good luck.
<GrueMaster> I'll give it one more go, then I'm out.
 * skaet nods
<GrueMaster> skaet: I'm out.  Get some sleep.  :)
<skaet> Thanks for your efforts!  soon for me too...
<pitti> Good morning
<skaet> pitti, jibel,  good morning.  :)   Interesting discussions with cjwatson on nasty wubi/grub bug in #ubuntu-testing backscroll - FYI.
<pitti> skaet: hey, good morning
<pitti> skaet: FYI, I just gave https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview some polishing
<pitti> skaet: oh, wubi still broken? I noticed that cjwatson did a CD respin last night for wubi
<skaet> yeah,  memory corruption issue in grub exposed it looks like.
<jibel> Hi skaet good night! I've read it.
<skaet> In the introduction on the https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<skaet> is the probably response to it.   ie. we don't recommend using wubi.
<skaet> with beta 1.
<pitti> *nod*
<jibel> pitti, the respin was to fix the label of the iso that wubi was not recognizing as a valid Ubuntu ISO.
<skaet> pitti, feel free to go into the TechOverview and do more polishing.   I still haven't finished translating/reviewing as worthy of mention, all those lovely new bugs.    Big gap for me is the desktop/unity side.  :)
<pitti> skaet: ah, I was about to ask whether I should go through the known issues
<skaet> yes please.
<pitti> sure
<skaet> also,  feel free to start in on as much of the release checklist as possible.   cjwatson only went to bed about 4 hours ago, so not sure when he'll be rolling on.
<pitti> skaet: I can start the image publishing and all that, so that the mirrors can start pulling from the firehose
<skaet> pitti, that would be good.   The images that are there are the one's we'll be going with now.
<pitti> skaet: ok, so aside from wubi no other catastrophes?
<skaet> I do think there are some of the arm/kubuntu varients we may need to selectively review whether worth shipping or not,  but you'll need ogra's input I think.
<pitti> well, I'll run through the iso tracker again anyway, to pick up new fatal bugs
<skaet> #u-testing, and look at GrueMaster's comments.
<skaet> thanks.
 * skaet feels that now that pitti is awake, its in good hands, and she can go to sleep.  :)
<pitti> skaet: heh, sleep well!
<skaet> thanks.
<mvo> good night !
<jibel> skaet, sleep well!
<cjwatson> pitti,skaet: I'm here at the moment, though I normally start late on Thu
<pitti> hey cjwatson
<cjwatson> publish-image-set.py --prepublish should be fine to do
<pitti> cjwatson: I'm currently updating the known issues on tech overview, and can then start the image publishing, if you want me to
<cjwatson> sure, that'd be great
<cjwatson> how about I fix publish-image-set?
<cjwatson> should work now (r236)
<pitti> hm, publish-image-set doesnt seem happy (only has very few images), investigating
<cjwatson> --prepublish doesn't have many because only a few need prepublication
<cjwatson> (that got me too)
<pitti> ah, of course
<pitti> cjwatson: we don't have source isos on releases.u.c.?
<pitti> (good from a mirror POV, just not sure about the legalese)
<cjwatson> that reminds me, I need to run cron.source (running)
<cjwatson> we don't
<pitti> good
<cjwatson> ideally we'd link to the source images
<cjwatson> (directly rather than generally to cdimage)
<cjwatson> <p>This directory contains the most frequently downloaded $CAPPROJECT
<cjwatson> images. Other images, including DVDs and source CDs, may be available on the
<cjwatson> <a href="http://cdimage.ubuntu.com/">cdimage server</a>.
<pitti> before publishing I'll do some cleanup first; at a3 we ran into -ENOSPC issues which caused a lot of confusion
<cjwatson> I did some cleanup yesterday / the day before which may have helped
<cjwatson> check with IS how much space is free, I guess
<pitti> ah, good
<pitti> ok, removed quite some old images (including two old edubuntu DVDs, etc.)
<pitti> cjwatson: mirrors are busy now
<pitti> cjwatson: can I also already publish the source isos? (as they take aaages to sync, even just to cdimage mirrors), or does your cron.source thing still need to run?
<pitti> cjwaston: ah, I see the cronjob, nevermind
<pitti> I'll wait for that
 * pitti goes back to banging on techoverview
<pitti> skaet_zzz: FYI, I'm summarizing related bugs in the tech overview, and also remove unimportant ones (such as deprecation warnings), to make the page a little easier to understand and read
<pitti> ogra_: would you like to review the "Ubuntu Netbook on ARM" and "Ubuntu Headless" sections on https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview ?
<pitti> cjwatson: publishing beta-1 source isos to cdimage now (as this takes ages)
<pitti> cjwatson: I also moved the alpha-3 images to ../old-images, but did _not_ sync that yet
<pitti> cjwatson: so the remaining thing to do now is the publish-image-set.py minus src
<pitti> I need to disappear for a couple of hours for doctor appointment, some errands and lunch, sorry; should be back when the action resumes, though
<cjwatson> source> ta
<cjwatson> I get upset mails and bug reports from John Gilmore if we don't get the source images done properly
<ogra_> pitti, added and reviewed
<cjwatson> out for a while (taking the car for its yearly test, so of course I'll have to walk back)
<pitti> re
<pitti> ogra_: thanks
<ogra_> pitti, about the kubuntu arm images, i have no idea which ones should get published, you will need to ask the owner
<pitti> Riddell, ScottK: who owns/decides about the maturity of kubuntu arm images?
<ogra_> there was a wikipage with a list of owners
 * ogra_ digs 
<ogra_> https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts
<pitti> ah, thanks
<pitti> bug 712061 sounds like it would affect omap3 and omap4
<ubot4`> Launchpad bug 712061 in kubuntu-mobile-default-settings (Ubuntu Natty) (and 1 other project) "kubuntu mobile images fail to load (affects: 1) (heat: 70)" [Medium,In progress] https://launchpad.net/bugs/712061
<pitti> pinged rbelem in devel
<ogra_> pitti, we dont have live images on armel
<ogra_> so loop device or squashfs issues are not for us
<ogra_> hmm, that bug turns into something completely different at the end
<ogra_> pitti, the nodm stuff might or might not affect armel, the initial bug description surely *isnt* an armel issue
<pitti> since this is "it", I wonder whether we could just thaw uploads again
<cjwatson> has skaet said she's OK to go with what we have?
<pitti> that's what she said this morning, /me checks logs
<pitti> 2011-03-31 09:43:30     skaet   pitti, that would be good.   The images that are there are the one's we'll be g
<pitti> oing with now.
<pitti> (argh, c&p from less sucks
<pitti> so, wubi is officially declared broken, and the kubuntu mobile images as well
<pitti> the rest looks okay
<ScottK> pitti: I think powerpc is broken too.
<pitti> right
<cjwatson> the wubi bug looks like it may be due to an incorrect limit in GRUB's NTFS implementation
<cjwatson> the error isn't actually printed, but gdb seems to be revealing a "read out of range" error, which is only generated in a single place in ntfs.c
<ScottK> If we're ~sure this is it, perhaps I could go ahead and accept gcc-4.4?  It will take a long time to build and isn't the default gcc, so even if we are wrong and respin something it's unlikely to have any effect?
<cjwatson> I'd be happy with that
<ScottK> OK.
<ScottK> Done.
<pitti> cjwatson: hm, I can't find a bug report about the wubi failure (i. e. the grub2 memory corruption), is there one? (I checked wubi and grub2, and the ISO tracker)
<pitti> hey skaet, good morning
<skaet> morning all
<skaet> any new breakages overnight from the remaining tests?
<jibel> pitti, I filed bug 746257 but the title is not really clear since I didn't know what's the problem was.
<ubot4`> Launchpad bug 746257 in wubi "Wubi fails to boot. User dropped to a grub shell (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/746257
<pitti> skaet: nothing new; so wubi, powerpc, and kubuntu mobile are officially declared broken, the rest ought to work
<pitti> jibel: ah, thanks; I'll add that as a reference to the tech note
<skaet> thanks pitti.
<pitti> skaet: ok, that just fixed the remaining "TODO" item in https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview, should be fairly complete now (also see my mumblings in backscroll)
 * skaet looking
<pitti> skaet: images are pre-published and should be mirrored, old images cleaned up
<pitti> skaet: so I'm by and large now waiting for "the word" to publish the images, and have natty unfreeze (stuff is queueing up and we really don't want to land that on a Friday)
<ScottK> pitti: Once we start unfreezing, I'd suggest we let loose things like the pkg-binarymangler that might affect other builds first so we don't end up with another late Friday post-milestone breakage problem when no one is around.
<pitti> skaet: note that publishing the images will still take a bit
<pitti> ScottK: both pkgbinarymangler and pkg-create-dbgsym are rather harmless really, but can do
<ScottK> That was just an example.
<ScottK> Thanks.
<pitti> right
 * skaet went through backscroll and all looks reasonable. :).   
<skaet> pitti,   thank you for the editing of the bugs!
<pitti> yw
 * skaet *hugs* pitti
 * pitti hugs back Kate
<pitti> skaet: so, please let me know when I should push the publish and thaw buttons
<skaet> pitti,  will do.  negotiating with web publishing now (rhlee is doing it this time)
<pitti> skaet: as I said, we'll need at least one or two hours time in advance to the web publishing
<pitti> well, let's say one
<skaet> heh.
<GrueMaster> Morning.  I'm looking over the TechOverview and see one thing that can be removed.  Under Ubuntu Netbook on Arm, No visual feedback on the splashscreen during jasper run. (728335) is now working.
<skaet> GrueMaster,  cool.   just go delete
<pitti> hm, sorry, I thought I already removed all the fix released bugs
<skaet> pitti,  they are a shifting target right up to the last minute.
<GrueMaster> Apparently the bug wasn't properly updated.
<pitti> ah, phew
<skaet> pitti,   where are the headless, arm, kubuntu mobile images going to be coming down from.    We're also not shipping the uce-images,  so we probably need to make some mention of that.
 * skaet goes and deletes the uec-images ref from the download beta 1 list 
<pitti> skaet: everythign but ubuntu/kubuntu desktop/alternates/server will be on cdimage, as usual
<pitti> skaet: i. e. arm, xubuntu, ubuntu DVD, source, tec.
<pitti> "etc"
<ScottK> I think we won't ship any kubuntu-mobile this milestone.
<ScottK> Riddell: ^^^ ?
<pitti> that, too (see above)
<Riddell> right, don't
<skaet> pitti,  where are the ec2 images?
<pitti> skaet: that's a mystery I still haven't learned about -- smoser usually does the right thing to them to publish them
<smoser> :)
<smoser> are we ready to push go ?
<pitti> smoser: when skaet says the world, we can both push our buttons and see who publishes faster :)
<smoser> http://uec-images.ubuntu.com/server/natty/20110329/ will be promoted, it has been pre-published.
<pitti> "the race of the rsyncs"
<skaet> smoser,  what path should I reference in the release notes for folks to pull those images from for beta?
 * skaet just reads
<pitti> smoser: would that be http://uec-images.ubuntu.com/releases/natty/beta-1/ eventually?
<skaet> http://uec-images.ubuntu.com/releases/natty/beta-1/ (Ubuntu Server for  EC2)  ?  ok?
<smoser> right.
<pitti> smoser: btw, you might want to remove http://uec-images.ubuntu.com/releases/natty/alpha-3.tmp/ ?
<smoser> oh. yeah, sorry.
<smoser> http://uec-images.ubuntu.com/releases/natty/beta-1/
<smoser> i'll ditch that tmp file.
<smoser> gone
<skaet> hmm,  ubuntu-headless looks like it needs to be added to the list.
<skaet> pitti, http://cdimage.ubuntu.com/ubuntu-headless/releases/natty/beta-1/
<skaet> seem about right?
<pitti> skaet: yes, looks fine to me
<ogra_> yup, thats the right path
<skaet> cool.  adding it.
<pitti> publish-release.py doesn't know about the headless images yet; I'll try to crowbar that in in the meantime
<pitti> cd
<pitti> erk, focus
<skaet> thanks.
<ogra_> oops, sorry, i should have added it ...
<pitti> I mean, publish-image-set
<skaet> I thought that some of the images would also go on /testing/ as well, but waiting feedback from web team
<pitti> ogra_: headless is armel+omap and armel+omap4 as well?
<doko> pitti: please could you accept perl before the general unfreeze?
<pitti> doko: noted
<pitti> doko: and let that publish, or you just want it to start building first?
<doko> pitti: start building, so that I don't see that many build failures in the rebuild test
<doko> same for doxygen
<pitti> ack
<pitti> no problem
<doko> the latter maybe now, it's not on any image
<pitti> doko: done
<pitti> in general I'll walk through and accept the lower-level stuff first
<skaet> pitti,  hmm,  what about the netboot images?
<cjwatson> I'll take care of the HTML pages for netboot
<cjwatson> where's the manifest page?
<skaet> cjwatson,  manifest page is a bit stale (on the todo), but indicates cdimage for netboot.   https://wiki.ubuntu.com/NattyNarwhal/ReleaseManifest
<doko> pitti: please accept gdc-4.4 too (packages b-d on gdc currently ftbfs)
<cjwatson> is that architecture list still what you want published?
<pitti> doko: done
<doko> pitti: same for gnat-4.4 (which will fail to build immediately, needing manual lamont love (or hate))
<pitti> doko: done
<cjwatson> http://cdimage.ubuntu.com/netboot/11.04/beta-1/ (not synced out yet, but that's where it'll be)
<skaet> cjwatson,  I'll be updating manifest to reflect what we've gotten testing agreement to on https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts
<skaet> will add that netboot path in the release notes - thanks!
<pitti> cjwatson: FYI, r237 now handles ubuntu-headless (erk ugly code)
<cjwatson> yeah, that stuff isn't fun.  thanks
<doko> pitti: and finally gcj-4.4
<pitti> skaet: hm, https://wiki.ubuntu.com/NattyNarwhal/ReleaseManifest doesn't have the headless armel images?
<pitti> done
<pitti> I guess that's now "bye-bye buildds" until today :)
<pitti> "tomorrow" I mean
<skaet> pitti,  thanks.   yeah,  manifest needs a good scrub.
<pitti> skaet: do you think it's ok to thaw now? (sorry for nagging, but it's getting late, I need IS for that, and we _really_ don't want to defer that until tomorrow)
<skaet> pitti,  yeah,  I just checked with jibel, and it doesn't look like anything that's left could become a show stopper (beyone what we know)
<skaet> pitti,  go ahead with the unthaw and turning on the auto jobes.
<skaet> jobs even
<pitti> skaet: ok, cool; I'll accept the low-level stuff then, and ask for thawing
<pitti> skaet: CD cronjobs can certainly wait until tomorrow, no rush with them
<cjwatson> pitti: thanks for dealing with the publishing; I know I was on the hook for the last stages
<pitti> cjwatson: no worries; you barely slept for 4 hours, happy to help you a bit
<Daviey> Hi, Has the archive thawed now?
<Riddell> Daviey: it would explain why all those packages got removed
<pitti> thawed, uploads work again
<pitti> queues cleared
<smoser> pitti, so i should have pushed 'go'?
<pitti> smoser: I didn't publish CD images yet, still waiting for skaet's go
<smoser> ah. ok.
<pitti> smoser: that's just the natty uploads, so that we stop blocking development
<skaet> pitti,  smoser,   go ahead now.   I don't see any blockers at this point.
<pitti> skaet: ack
<Daviey> dandy
<tgardner> now that the archive is thawed, could someone NEW linux-backports-modules-2.6.38 ?
 * skaet -> food,  biab
<pitti> cjwatson: I now published all images and updated HEADER.html, but I didn't mangle manifest yet
<cjwatson> want me to?
<pitti> is that www/./simple/.manifest ?
<cjwatson> yes
<pitti> cjwatson: what needs changing there?
<cjwatson> I'll do it and you can look at the diff
<pitti> thanks
<pitti> cjwatson: and where is the counterpart for kubuntu?
<cjwatson> diff -u .manifest.full .manifest
<cjwatson> it's all in that file
<pitti> cjwatson: ah, I see; so that's only temoprary for faster mirror sync?
<cjwatson> yes
<cjwatson> faster mirror probing actually
<pitti> ok, www diff looks good
<pitti> anything else? if not, I'll press the sync-mirrors button
<pitti> there, syncing
<pitti> skaet: I'll supervise the syncing and tell you when it's done
<pitti> skaet: oops, TechOverview has "cdimage" for u/kubuntu, fixing
<pitti> skaet: it's releases.u.c.
<tgardner> pitti, cjwatson: can I get linux-backports-modules-2.6.38 NEWed? I hate to nag, but we're about to have a meta package upload for the kernel that also references LBM binaries. not the end of the world for sure, but annoying nonetheless.
<pitti> skaet: release.u.c. links added to https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview, and updated descriptions
<pitti> tgardner: done
<tgardner> pitti, thanks
<smoser> http://uec-images.ubuntu.com/releases/natty/beta-1/ is live now.
<pitti> edu and kubuntu DVDs finally rsynced, whew
<skaet> pitti,  thanks.    Remind me to corner you at UDS for a description of why the links change from cdimages to releases for beta and the background as to the which images are selected.
<skaet> pitti, smoser - just heard back from web team,  and http://www.ubuntu.com/testing/download (Ubuntu and Ubuntu Server)  will be able to be working after all for this release.
<pitti> skaet: that's easy: cdimage.u.c. only has a handful of mirrors and only is the DC
<skaet> DC?
<pitti> skaet: i. e. we use it for alphas, ports, DVDs, and anything else which won't get millions of download (which our DC alone couldn't sustain)
<pitti> skaet: data center
<skaet> ahh,  ok.
<skaet> cool
<pitti> skaet: releases.u.c. gets mirrored around the world, and has the most popular images
<pitti> skaet: but DVDs, ports, etc. are simply too big to get mirrored so widely
<pitti> (and at the same time are much less popular)
<skaet> :)
<skaet> Am interested in the criteria used for deciding "popular images",  I imagine its based on some download statistics from James   :)
<pitti> skaet: right now that's ubuntu/kubuntu desktop+alternate, and server
<pitti> skaet: the DVDs are too big, and e. g. xubuntu doesn't have so many downloads that it would need a worldwide mirror network, i. e. we can sustain that
<skaet> pitti,  thanks!
<pitti> ah, http://cdimage.ubuntu.com/releases/natty/beta-1/ doesn't have arm, sorry; fixed TechOver
<pitti> last Ubuntun DVD rsyncing, the rest should be fairly quick
<skaet> thanks pitti
<pitti> skaet, cjwatson: I suppose http://releases.ubuntu.com/ html should also have "Ubuntu Natty Narwhal Beta-1" in the release list? want me to fudge the html?
 * skaet looking
<cjwatson> yeah, that needs to be fudged by hand - I'll do it
<cjwatson> (.htaccess too)
<skaet> pitti, cjwatson  yes,  thanks - "Ubuntu 11.04 (Natty Narwhal)"
<pitti> ah, thanks
<cjwatson> done.  sync at your leisure
<cjwatson> (I haven't synced it out, didn't know what state you were in)
<GrueMaster> pitti: http://cdimage.ubuntu.com/kubuntu/releases/natty/beta-1/kubuntu-11.04-beta1-preinstalled-desktop-armel+omap4.img.gz appears to be from http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110330/ not http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110330.1/
<pitti> ARCHES='armel+omap armel+omap4' for-project kubuntu publish-release daily-preinstalled 20110330 preinstalled-desktop named beta-1
<pitti> GrueMaster: right; I'm afraid our script only builds them together
<pitti> GrueMaster: hang on, I'll update it
<cjwatson> s/builds/publishes/?
<pitti> ^ yes
<cjwatson> odd though, I thought I made it notice that
<GrueMaster> ls
<cjwatson> maybe I missed something
<GrueMaster> oops
<GrueMaster> I don't think the link was updated on iso.qa when the omap4 images were respun.
<GrueMaster> The kubuntu images were done last.
<GrueMaster> Not a major deal.
<pitti> GrueMaster: publishhing the 30.1 image now
<cjwatson> GrueMaster: I'm pretty sure skaet and I updated the links between us
<GrueMaster> Thanks.  I pull a separate copy of released images and compare them to the daily images I tested with.  That's how I noticed.
<GrueMaster> cjwatson: Not trying to point blame.  Just making sure the tested images are the same as in the release.
<cjwatson> sure, just a point of information
<pitti> GrueMaster: published, syncing out now; the date looks better now, from 15:41
<pitti> instead of 05:something
<pitti> GrueMaster: thanks for noticing!
<GrueMaster> Also, we may want to rename the ubuntu netbook armel images before final.  ubuntu-netbook-11.04-beta1-preinstalled-netbook* is redundantly redundant.  :P
<ogra_> how did the last netbook get into that ?
<ogra_> i thnk thats coming from the way publish-release was called
<GrueMaster> ogra_: Our image names are natty-preinstalled-netbook-armel*.  The release names are s/natty/ubuntu-netbook-11.04-beta1.  Just need to remove the first netbook.
<pitti> http://releases.ubuntu.com/ has a shiny natty link now, thanks cjwatson
<skaet> :)
<pitti> ok, CD syncing will still take a bit; I'll grab some dinner in the meantime
<GrueMaster> ubuntu-headless is the same namewise.
<ogra_> GrueMaster, well, ubuntu-netbook is the flavour name, the imagetype shouldnt get a piece from the flavour added
<ogra_> imho it should be <flavour>-<release>-<type>-arch+subarch.img.gz
<ogra_> i.e. ubuntu-netbook-11.04-preinstalled-armel+omap4.img.gz
<GrueMaster> ok, so the script needs to be fixed to strip out the second redundant name.
<ogra_> see pittis call of the script above
<ogra_> for-project kubuntu publish-release daily-preinstalled 20110330 preinstalled-desktop named beta-1
<ogra_> it just needs the -desktop dropped on the third last arg
<GrueMaster> ogra_: Why are you telling me how the process works?  I'm only pointing out a minor naming issue.  I don't care how to fix it or if it gets fixed.  I'm just pointing it out.
<GrueMaster> Do you want me to fix it?
<ogra_> ??
<pitti> GrueMaster: http://cdimage.ubuntu.com/kubuntu/releases/natty/beta-1/ has the current image now
<GrueMaster> Ok, thanks.
<pitti> hm, all other images are synced now, but http://cdimage.ubuntu.com/mythbuntu/releases/natty/beta-1/ is blatantly missing
 * pitti fiddles
<pitti> oh
<pitti> Daily for natty amd64 on 20110329.1 is oversized! Continue?
<pitti> well, I suppose "yet"
<pitti> "yes"
<pitti> skaet: rsync complete; all links on https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview "in addition, they can be found" work now
<pitti> skaet: the http://www.ubuntu.com/testing/download meta-link is still outdated at least for me (it redirects to a nearby German mirror)
<pitti> skaet: can you try whether it works for you?
<skaet> thanks pitti.   :)  All the direct links are working
<pitti> (different mirrors take a different time to catch up)
<skaet> checkting testing now.
<pitti> hm, another German mirror is behind as well
<pitti> seems these still need a bit
<pitti> skaet: bug on http://www.ubuntu.com/testing -- it says "Beta", should be "Beta 1"
<pitti> (and the link is still broken)
<skaet> pitti,  can you fix?
<pitti> skaet: no, that needs a webmaster
<skaet> or do I need to get webteam on it.
<skaet> heh
<skaet> that answers that
<skaet> - ok,  on it.
<pitti> skaet: (sorry, was at dinner; back for real now)
<pitti> cjwatson: do you happen to know whether there's somethign we can do about taking outdated mirrors out of the http://www.ubuntu.com/testing/download redirector?
<slangasek> pitti: ask LOSAs for a cdmirror probe?
<pitti> doing that
<slangasek> make sure you have a reduced .manifest on releases
<slangasek> otherwise the probe takes too long to be useful
<pitti> slangasek: we do
<slangasek> ok
<skaet> pitti,slangasek.   mirrors starting to kick in now.  http://ubuntu-releases.eecs.wsu.edu/natty/
<pitti> yeah, I've seen a few German mirrors updating as well
<pitti> skaet: I pinged in #is
<skaet> pitti, newz2000 will fix the typos.
<pitti> great
<skaet> anyone else spot any?
<skaet> hmm,  just spotted we didn't have an NattyUpgrades page on the community documentation side:  went and created one.   https://help.ubuntu.com/community/NattyUpgrades
<skaet> it still needs some editing though.
<pitti> mirror prober seems to have helped, looking good now
<jibel> skaet, on http://www.ubuntu.com/testing/natty/beta the 1rst link at the top of the page (Download Beta) is broken
<jibel> it should probably be "http://www.ubuntu.com/testing/natty/beta#Download%20Beta%201" <- with a 1 at the end
<jibel> who is able to edit this page ?
<skaet> jibel,  newz2000 is helping get it working.   thanks for catching.
<Riddell> evening.  are we nearly there yet?
<highvoltage> Riddell: according to omg!ubuntu! beta1 has been released for several hours now :)
<Riddell> wow, they scoop us every time, how do they do it
<highvoltage> they're the fox news of ubuntuland :)
<skaet> Riddell,  highvoltage - they see when we're testing the web sites.
<skaet> announce will be going out shortly after a last set of edits.
<pitti> good night everyone
<highvoltage> good night pitti
<skaet> good night pitti
<skaet> slangasek, cjwatson,  ubuntu-announce has gone out,  can you approve.
<cjwatson> I don't have privileges on -announce
<cjwatson> only -devel-announce
<cjwatson> bah, we should've removed the chroot-aware bit from the upstart section, since it doesn't work yet
<cjwatson> ah well
<cjwatson> approved the -devel-announce copy
<skaet> thanks cjwatson
<slangasek> skaet: I'm failing to remember how to get in to approve it; the passwords I have cached don't seem to be doing the job
<slangasek> or I'm on the wrong page, which is possible
<skaet> slangasek,  I'll go ping in #is
<skaet> can you go change the #ubuntu-devel topic?
<slangasek> done
<skaet> thanks
<skaet> :)
<skaet> slangasek,  can you point me to the runes to let me do the posting on ubuntu release blog?
 * skaet finishing off the to do list
<slangasek> skaet: log in at https://release-blog.ubuntu.com/wp-login.php; I think you have a login/password, let me know if I need to reset it
<slangasek> confirmed, your login is there
<skaet> ok,  sent off the request for it to be reset
<skaet> slangasek,  thanks.
<slangasek> "sent off a request" - I don't know where that request goes, probably nowhere useful :)  I'll reset it.
<slangasek> hmmm but I don't have a button to generate a new password
<skaet> slangasek, got one via email, and I'm in now.
<slangasek> ok
<skaet> thanks for your help  :)
<slangasek> then maybe I've changed the password on you and locked you out again, heh
<slangasek> we'll find out next milestone!
<skaet> hmmph
<skaet> not working now. I'll try the one you just sent
<skaet> yup,  that did it.   Am In now.  :)
<highvoltage> yay beta 1 \o/
#ubuntu-release 2011-04-01
<skaet> highvoltage,  :)
<skaet> slangasek,  blog entry done.  Seems I don't have permissions for that final step though.
<slangasek> what's the final step/
<slangasek> ?
<skaet> Post announcement to Launchpad (ubuntu-drivers members have posting rights)
<skaet> https://launchpad.net/ubuntu/+announce
<slangasek> seems I don't have access anymore either
<slangasek> I think you need someone on the TB then
 * skaet nods
<skaet> yeah, we need to change that comment as well then.
<skaet> cjwatson, pitti ^^
<skaet> slangasek, cjwatson, pitti - kees helped out,  step 5 done.
<skaet> And with that - I call it a day.
<slangasek> ok, great :)
<slangasek> congrats on the beta!
<skaet> thank you all,  for getting the beta out!   awesome teamwork.  :)
<slangasek> oh geez
<slangasek> Build status
<slangasek> [NEEDSBUILD] Needs building
<slangasek>     Start 2011-04-03
<slangasek> wtf, ppc
<kirkland> could I get permission to upload this to natty?  http://paste.ubuntu.com/588060/
<kirkland> i have a couple of other fixes coming for cobbler, but this one in particular is making iterative development difficult
 * kirkland uploads, as I know you'll reject if there's a problem
<kirkland> Okay, just uploaded cobbler part 2 of obvious fixes
 * micahg thought the archive was open again
<kirkland> i have some more functional ones coming tomorrow
<kirkland> for now, I'm worn out
<pitti> skaet: congratulations!
<cjwatson> skaet: do we have to have the release meeting today?  dunno about you but I'm knackered. :-)
<cjwatson> (I notice you haven't sent out the agenda yet, so was wondering if you were contemplating cancelling)
<Daviey> fwiw, our team has nothing new/scary to report.
<pitti> cjwatson, skaet: FYI, cd image cronjobs turned back on
<pitti> nothing major from desktop either
<pitti> except that the latest unity fixed a gazillion crashes, it's actually stable again :)
<Daviey> pitti, seems 2d unity was fixed aswell!
 * cjwatson is still deep inside a horrifically complex gdb/qemu session for wubi
<cjwatson> 18 breakpoints with a bunch of custom commands ...
 * ogra_ wouldnt have much to report for armel either ... and wouldnt mind skipping this week
<ScottK> cjwatson or pitti (or any other release team member): Please look at the utouch-grail upload that just went up and the commentary in Bug 742582.  I think it's completely out of line.
<ubot4`> Launchpad bug 742582 in utouch-grail (Ubuntu) (and 1 other project) "Add touch gesture events (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/742582
<ScottK> "if anyone has any problems with this change, they need to take it up with Mark Shuttleworth" and then uploads.
<cjwatson> ScottK: I'm not hugely fond of that comment, but pitti had already approved the FFE (comment #8)
<ScottK> OK.
<ScottK> I'd missed that.
<pitti> not that I'd massively like it either, but there wasn't a lot to decide about this :/
<ScottK> Agreed.
<ScottK> I think it had to be approved, but the take it up with ... comment is really out of line.
<ScottK> It was also, as cjwatson thankfully pointed out to  me, completely unneeded since you'd already approved it.
<ScottK> Given that the function was specified and Unity depended on it, they could have even reasonably argued it was a bug fix.
<skaet> cjwatson, pitti, Daviey - yeah, ran out of energy to get the agenda updated with the latest bugs after finishing the release.   I figured a quick round table might be prudent though to make sure we're all set on plans for the next couple of weeks.   I want to make sure everyone is aware of the freeze dates we talked about on u-release maillist,  for instance.
<skaet> don't bother preparing reports, just interested if there are any critical issues.
<skaet> would also like to see what the results are like from the testing and hardware cert teams.
<skaet> ScottK,  Riddell,  ^^
<ScottK> OK.
<matttbe> Hello
<matttbe>  I'm part of the Cairo-Dock team and I want to update Cairo-Dock packages on Ubuntu. I've opened two bug reports (cairo-dock and its plug-ins) one month ago (before the FF) with two linked branches: https://code.launchpad.net/bugs/723994 & https://code.launchpad.net/bugs/723995.
<ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu Natty) (and 1 other project) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 16)" [Wishlist,New]
<matttbe> I've contacted a few people on IRC and we said to me last time that I'd to do this request today (due to the beta freeze).
<matttbe> So... is it possible to help me?
<matttbe> Ok I'll be back later but I hope somebody may help me!
<skaet> matttbe,  sorry  we were in release meeting
<skaet> pitti,  around?
<pitti> skaet: yes
<skaet> pitti,  any reservations on accepting the new cairo-dock in?
 * pitti looks
<pitti> skaet: if you looked at it, fine for me; it's an universe leaf package
<skaet> pitti,   haven't gone through the code yet,  but will do the check then if it has a chance.   it seems to have been overlooked, and a probable good thing to have.
<skaet> micahg,  you had some issues on the cairo-dock plug-ins   did they get resolved?
<micahg> skaet: I wanted to look into the option of merging from Debian, but at this point, I would just take what he has if it's upload worthy and merge next cycle
<skaet> micahg,  ok.
<skaet> thanks
<Laney> he disagrees with how Debian has done the packaging
<ScottK> skaet and micahg: We need to be careful not to fork the package from Debian.
<Laney> why do we have cairo-dock-plugins and cairo-dock-plug-ins?
<micahg> right, he says it's not in the spirit of upstream, I was going to review that, but he said that we never merged from Debian before
<Laney> looks like the former has never even built
<ScottK> One is a transitional package.
<micahg> Laney: that's another problem
<ScottK> Or our package naming is different.
<Laney> we should probably remove & blacklist it until this is sorted out
<Laney> and encourage him to speak to Debian
<micahg> yep, we've never merged with Debian before for cairo-dock, so I'd say we can worry about that next cycle, the -plug-ins -plugins issue is another story, we should probably just drop the Debian one for this cycle and get it sorted out early in oneiric
<micahg> IMHO
<micahg> Laney: he already has, but maybe we can help facilitate better communication
<Laney> yeah
<Laney> do we have a clear description of what the problems are?
<micahg> skaet: ping
<skaet> micahg:  yup?
<micahg> skaet: hi, there's a thunderbird update planned for during final freeze (april 19), but that might slip a couple days, wondering if we should try to get it in or stage it in the security PPA
 * skaet checking some dates ... sec
<skaet> micahg, april 19 is way too late for Natty,  so it will have to go in after.
<skaet> is it a security fix?   if not,  should probably go through the SRU side.
<cjwatson> -security rather than SRU
<cjwatson> (SRU => -proposed/-updates)
<micahg> skaet: ok, we can probably upload it once it hits the beta channel upstream (apr 4), I'm just wondering about any potential respins
<skaet> :)
<micahg> probably has security fixes
<skaet> fair enough then.
<skaet> 4/11 is when we freeze for beta 2 - so best if its in before then.
<micahg> skaet: well, I or chrisccoulson can get whatever the current build candidate is by then, I'm wondering what to do though if there's a respin after that point
<skaet> After that,  -security option,  if there are true security bug fixes that still need to be applied.    -proposed for other bug fixes.   ok?
<skaet> micahg,  don't wait until 4/11 please - earlier is better.
<micahg> skaet: well, here's the real question, do we risk having a non-final build at release if there's a respin
<micahg> or do we release the security update potentially 9 days late
<skaet> bug fixes will be reviewed and accepted for beta 2, and up 4/21.
<skaet> so,  4/19 could conceivably squeak in if the bug fixes are reasonable.   But would want it as diffs, rather than full image, so we know what's there.
<micahg> skaet: ok, anything for the respins would be bug fix
<skaet> If there wasn't security fixes involved,  I'd be tempted to just wait until oneiric.
<skaet> thanks micahg
<micahg> skaet: ok, so to summarize so I'm clear, we should get in the candidate build as soon as possible and bug fixes to the candidate build would most likely be ok up until 4/21
<skaet> micahg, since we'll be doing the release images build on 4/21,  best plan on fixes up to 4/20.
 * micahg hopes they release on time then
 * skaet agrees.
<micahg> skaet: I'll actually be off 4/19 and 4/20, but hopefully we'll know the week before
<cjwatson> I think that may be bug 742967 dead at last
<ubot4`> Launchpad bug 742967 in grub2 (Ubuntu Natty) (and 2 other projects) "Natty Wubi grub prompt on install (affects: 2) (dups: 1) (heat: 18)" [High,Fix released] https://launchpad.net/bugs/742967
<cjwatson> ev will need to build a new Wubi binary though
<cjwatson> (after it's built)
<skaet> otherwise,  its probably going to be get it into the -security queue,  and have it ready as a 0-day fix.
<ev> will do
<skaet> cjwatson,  that's great to hear.  :)
<micahg> skaet: BTW, it's on xubuntu that would be impacted by this if an ISO respin was needed
<micahg> *only
<ScottK> skaet: I suspect getting it in between Beta 2 and when we spin the final candidate images would be OK.
<cjwatson> ev: upgrading to grub-pc 1.99~rc1-8ubuntu1 should be sufficient
<ScottK> It = Thunderbird.
<ev> cjwatson: congratulations on hopefully getting to the bottom of it
<skaet> micahg,  Thunderbird does tend to get used by alot of Ubuntu users as well, so not sure its just Xubuntu impact.
<ev> and noted
<cjwatson> ev: I did eventually manage to distil a non-Wubi test environment out of it
<micahg> skaet: right, but I think that's the only ISO impacted
<skaet> micahg - fair 'nuf.  :)
<ev> cjwatson: in that you were able to reproduce the bug outside of a wubi install, or you crafted something reusable for further testing of grub?
<cjwatson> if you have a config file on a loopback device that re-loopbacks itself and then calls loadfont on unicode.pf2 (to allocate lots of memory and force the freed memory out), and then a big pile of comments to ensure that you go onto another disk block, then some random echo comments, the echo commands will fail to run correctly
<micahg> skaet: I'm wrong, the DVD is as well...
<cjwatson> it's not a reliable test, but it was good enough to check that I'd got it right
<ev> nice
<cjwatson> in the Wubi environment, I just forced it to skip over the re-loopback, and confirmed that I got to a GRUB menu that way
<cjwatson> (forced> using a very carefully-selected breakpoint and 'jump' in gdb)
<skaet> micahg,  ack.   4/20 for fixes in, else plan on zero day updates.
<dobey> hi all
 * skaet --> lunch and some errands,  back on later. 
<dobey> i was wondering about the progress on the exception request for bug #733327
<ubot4`> Launchpad bug 733327 in libubuntuone (Ubuntu) (and 1 other project) "[UI FFE] Notify user of missing MP3 support (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/733327
#ubuntu-release 2011-04-02
<matttbe> Hi,
<matttbe>  I'm part of the Cairo-Dock team and I want to update Cairo-Dock packages on Ubuntu. I've opened two bug reports (cairo-dock and its plug-ins) one month ago (before the FF) with two linked branches: https://code.launchpad.net/bugs/723994 & https://code.launchpad.net/bugs/723995.
<ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu Natty) (and 1 other project) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 16)" [Wishlist,New]
<matttbe> Is it possible to help me now or should I have to be back later?
<PinkUnicorns> .75
<ScottK> matttbe: We discussed it a bit after your last visit.  I think micahg is going to look into it.
<matttbe> ScottK: ok thank you! So... do I have to wait and see? nothing more?
<matttbe> because we don't have any ack and I think that micahg can't give this ACK
<ScottK> I think one of the issues he was looking into was the differences between packaging in Ubuntu and Debian.  As a rule, we prefer to align to Debian.
<ScottK> I'll probably ack whatever recommendation he makes.
<matttbe> yes I know but the Debian maintainer doesn't want to apply some patch given by the upstream...
<matttbe> it's a bit ridiculous but... I'm not a Debian maintainer :)
<ScottK> So I would seek him out on #ubuntu-devel when you seem him and ask how you can help out.
<matttbe> ok but I've already given to him all reasons of this problem with Debian
<matttbe> https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564
<ubot4`> Launchpad bug 657564 in cairo-dock-plugins (Debian) (and 4 other projects) "Duplicated package with cairo-dock-plugins (coming from Debian) (affects: 1) (heat: 27)" [Undecided,In progress]
<ScottK> Yes and that may be enough.   I didn't hear from him yet, so it wouldn't hurt to ask.
<matttbe> Ok so I'll try to be back later to ask some news about this problem!
<matttbe> Thank you
<slangasek> cjwatson: the current python implementation of checkrdepends reports on revdeps from the same source, which ISTR fixing the previous incarnation not to do; is this a deliberate behavior change, or can I re-fix this for the sourceful case?
<slangasek> hmm, bug #747988 is troubling; the package was removed from Debian in August but was still in natty today
<ubot4`> Launchpad bug 747988 in agsync (Debian) (and 1 other project) "Please remove agsync from natty (affects: 1) (heat: 8)" [Unknown,Unknown] https://launchpad.net/bugs/747988
<slangasek> I guess no one has been running process-removals?
<cjwatson> slangasek: sounds reasonable to fix iff you asked it about a source package rather than a binary package
<slangasek> ok, will poke at it later, thanks
#ubuntu-release 2012-03-26
<jdstrand> cjwatson: I don't have the context of the conversation, but if you need my team to flag certain packages for some reason and coordinate that with you, let me know and we'll make that happen
<jdstrand> cjwatson: (referring to the libssl conversation in backscroll)
<slangasek> jdstrand: this is specifically to do with ABI changes and d-i not respecting versioned dependencies
<slangasek> shouldn't be a problem for security updates
<jdstrand> ok, thanks
<jdstrand> we're here if you need us :)
<Daviey> d-i is good now.. thanks :)
<pitti> Good morning
<pitti> cjwatson: FYI, cd image cronjobs on manual now
<pitti> cjwatson: I set OFFICIAL="Beta" in cdimage now; that's a reason to rebuild everything, marking in the tracker
<pitti> err, pad
<slangasek> pitti: I think that needs to be set to 'Beta 2' to avoid confusion
<slangasek> (it was set to 'Beta' last time rather than 'Beta 1', but at least 'Beta 2' will still be unique)
<pitti> slangasek: oh, ok; I wasn't sure whether that gets parsed and compared anywhere
<slangasek> I believe it winds up in the iso diskinfo
<slangasek> I don't think it's *parsed* anywhere, but it's confusing to have two images called 'Beta'
<pitti> hm, beta-2 to be safe, or do you know that a space works?
<pitti> tools like usb-creator parse the version (but that comes much ealier in the string)
 * pitti digs history for lucid
<slangasek> I'm reasonably certain that 'Beta 1'/'Beta 2' was what we used last cycle
<pitti> ahh, there's precedent for "beta 2", nevermind
<pitti> done
<slangasek> cheers
 * slangasek wanders off to bed now
<jibel> pitti, IIRC wubi uses this info to identify the image and the regex fails if there is a version in the sub-version e.g Beta 2
<pitti> jibel: bonjour
<jibel> pitti, morgen :)
<pitti> jibel: oh, so did that break in hardy/lucid/oneiric as well?
<jibel> pitti, In natty I think
<jibel> unless that was fixed in wubi, let me check
<jibel> pitti, it is the regex used by wubi to parse disk/info
<jibel> disk_info_re = '''(?P<name>[\w\s-]+) (?P<version>[\d.]+)(?: LTS)? \"(?P<codename>[\D]+)\" - (?P<subversion>[\D]+) (?P<arch>i386|amd64) \((?P<build>[\d.]+)\)'''
<jibel> so it still fail with "Beta 2"
<pitti> jibel: ok, thanks; so I better change that to Beta-2
<pitti> jibel: done
<pitti> https://launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=44328
<pitti> hmm, 43 bugs
 * pitti gardens them a bit
<pitti> ^ csync is unseeded, and a no-change rebuild to fix uninstallability, accepting
<micahg> pitti: I still want to kill sqlite2, but I guess the rebuild's ok (will send e-mail to -release when I'm ready to work on it)
<pitti> micahg: thanks
<pitti> micahg: yeah, at least it's installable now
<micahg> pitti: being that no one's complained yet, I'm guessing it's not very used
<pitti> micahg: it was an easy thing to get off the beta-2 bug list; sorry if I got in your way
<micahg> pitti: not at all, only reason why I added to beta 2, was I was hoping to have sqlite done by now
<micahg> pitti: actually, was tempted to ask you to remove
<micahg> csync, not sqlite
<pitti> can do that as well, if there's a good reason for it
<pitti> if it's the only package that still uses sqlite2, that would be a good reason :0
<micahg> pitti: sqlite2 deprecated :), I guess at this point, it might as well wait until the rest of the sqlite cleanup
<pitti> https://launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=44328 is a bit shorter now
 * cjwatson has a look through archive admin bugs
 * Laney arghs at still not having filed the other haskell removal one
<cjwatson> newlib should be safe despite being in main; it's only there for newlib-spu which is a build-time-only thing only on powerpc
<cjwatson> Laney: https://bugs.launchpad.net/ubuntu/+source/haskell-attoparsec-text/+bug/955521/comments/3
<ubot2> Launchpad bug 955521 in haskell-xml-enumerator "Various discontinued Haskell packages to remove from precise" [Undecided,Confirmed]
<cjwatson> and comment 4
<Laney> yeah there's some yesod syncage to do
<cjwatson> and hledger-web
<Laney> yeah
<Laney> brb
<Laney> i'm syncing some more stuff which should make the rdeps go away
 * Laney pulls at threads
<pitti> cjwatson: thanks for the newlib fix, accepted
<pitti> cjwatson: FYI, I'm accepting the GNOME 3.4.0 bits; they go into -proposed, and only update translations
<cjwatson> OK; do you want to get them onto beta-2 images?
<pitti> so that we can stash up 3.4 in -proposed, and move it to precise after the freeze
<cjwatson> ah right
<pitti> cjwatson: I see no need for this
<pitti> translations are stripped anyway, and we dont' get new b2 langpacks
<pitti> cjwatson: it's mostly for seb128 to get them out of the way, and in -proposed they avoid arch skew
<pitti> I mean uninstallability due to arch skew
<cjwatson> certainly
<seb128> hum
<seb128> https://launchpadlibrarian.net/98386576/buildlog_ubuntu-precise-armel.gnome-panel_1%3A3.4.0-0ubuntu1_CHROOTWAIT.txt.gz
<seb128> "bzip2: Data integrity error when decompressing."
<pitti> erk
<seb128> does it mean the builder is buggy?
<cjwatson> I think I'd be inclined to just mash retry
<cjwatson> that sounds like a network transmission error on the chroot
<cjwatson> and bzip2 has done part of its job and spotted it
<seb128> thanks
<cjwatson> if it happens multiple times we can be more worried
<ogra_> hmm, seems nusakan didnt do the DST switch ... i just got the daily health checks mail 1h late
<ogra_> (or didnt the uk switch ?)
<seb128> cjwatson, https://launchpadlibrarian.net/98386775/buildlog_ubuntu-precise-armel.gnome-panel_1%3A3.4.0-0ubuntu1_CHROOTWAIT.txt.gz
<cjwatson> it's intentionally on UTC
<seb128> cjwatson, same issue on second try
<seb128> (same build, caph)
<ogra_> oh ... silly me, indeed
<cjwatson> seb128: hmm - ask #launchpad-ops (internal)
<seb128> builder
<seb128> cjwatson, ok
<Daviey> all servers should stick to UTC :)
<ogra_> Daviey, all the world should :)
<ogra_> would aviod me getting confused
<Daviey> ogra_: I'm happy to stick my working day to UTC :)
<pitti> cjwatson: I found a fix for bug 963069, the breaker du jour for the lucid->precise universe auto-dist-upgrade test
<ubot2> Launchpad bug 963069 in gtk+2.0 "Lucid -> Precise universe: pkgProblemResolver::Resolve generated breaks - does not replace gir1.0-gtk-2.0 with gir1.2-gtk-2.0" [High,New] https://launchpad.net/bugs/963069
<pitti> cjwatson: would you consider accepting this for beta-2 at this point? it's just adding a new Conflicts:
<pitti> err, breaks
<pitti> I'm test-building locally now to ensure it still builds
<pitti> cjwatson: I can also use -proposed if you want
<cjwatson> what's the state of image testing?
<cjwatson> a few tests registered, not lots
<cjwatson> so yeah, I'd consider it
<pitti> cjwatson: we need to rebuild everything anyway still, for the OFFICIAL change
<cjwatson> oh, you didn't do that already?  OK
<pitti> cjwatson: I did it this morning
<pitti> but images haven't rebuit since then
<pitti> cjwatson: and I updated it to say "Beta-2" instead of "Beta 2" to avoid breaking wubi (cf. jibel's ping around 0700 UTC here)
<cjwatson> sure; for lucid we just said Beta in both cases
<cjwatson> I'm actually fairly sure that "Beta 2" would have worked in the specific case of wubi; jibel misread the regex
<cjwatson> ... actually, both of them break equivalently, thinking about it
<cjwatson> \D matches anything that's not a digit
<pitti> hm, so just "Beta" after all?
<cjwatson> I understand slangasek's point about confusion, but I think avoiding triggering bugs ought to take precedence
<pitti> +1
<pitti> and that's only for the .disk/info stamp, right?
<pitti> or does it go anywhere on the .html pages?
<pitti> (these are edited manually anyway)
<cjwatson> html is done separatey
<cjwatson> +l
<pitti> and the .iso file names are a publish-release argument
 * pitti adds ^ to the etherpad
<cjwatson> accepted
<pitti> thanks
<pitti> cjwatson: I'll move it to precise once it's built everywhere
<pitti> erk, powerpc build ETA in 15 h
<pitti> seems the wesnoth backports own the ppc builders for a while
<Daviey> wesnoth  is release critical
<cjwatson> oh, blast, I was just clearing them while I remembered.  surely you can just score things up though?
<cjwatson> otherwise feel free to ask #launchpad-ops for build cancellations
<pitti> cjwatson: scoring doesn't help, already tried
<pitti> cjwatson: yeah, will do that
 * pitti questions the utility of maverick backports at this point..
<seb128> cjwatson, pitti: #launchpad-ops sorted the armel builder issue btw
<pitti> seb128: cool, thanks
<pitti> gtk+2.0 ppc building now
<scott-work> just subscribed release-team for bug #963498
<ubot2> Launchpad bug 963498 in ubuntustudio-default-settings "[FFe] menu is not ubuntu studio version" [Undecided,New] https://launchpad.net/bugs/963498
<pitti> cjwatson: FYI, out for doctor appointment for ~ 1 hour; gtk 2.0 still building :/
<cjwatson> pitti: ok
<cjwatson> scott-work: I'm not sure I see why this is an FFe; isn't it just a bug?
<scott-work> cjwatson:  i would think this is just a bug and could be addressed without the release-team's approval, but i was just being cautious
<cjwatson> confirmed anyway
<scott-work> cjwatson: thank you
<scott-work> i think there is a bit of a culture in some quarters to be cautious about bugs after freezes...perhaps, overly cautious, i will try to be more judicious in the future however
<cjwatson> it's fine to be cautious, but don't hamstring yourself :)
<jdstrand> fyi, I just sponsored a freetype upload to precise for security updates. it is not required for beta-2, but is fine if it is pulled in
<pgraner> cjwatson, the unity guys might have a fix for https://bugs.launchpad.net/ubuntu/+source/unity/+bug/963633  (or a best a partial fix)
<ubot2> Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress]
<pgraner> cjwatson, dbarth has more info
<cjwatson> OK, they can ask somebody from desktop to apply it to the package as a patch, and then we (release team) can review it once it's in the queue
<dbarth> cjwatson: hi
<cjwatson> or one of their own people with upload privileges if possible
<cjwatson> until then it doesn't need to go through me :)
<dbarth> we're testing a small fix in the gconf backend from which we suspect the hangs and corruptions come from
<pgraner> cjwatson, more of a heads up that a respin will be needed
<cjwatson> pgraner: we haven't spun yet
<dbarth> it's 4-5 lines of changes, but means a respin would be needed to integrate the change
<cjwatson> the existing images still say alpha, we were waiting for gtk+2.0 to land
<pgraner> cjwatson, ah ok, I thought we had spun then nevermind....
<cjwatson> but certainly if you could get something uploaded ASAP rather than later that would help
 * dbarth hopes we'll beat gtk+2
<cjwatson> I doubt it, it was well on its way building
<dbarth> ugh, well
<ralsina> question! We found  a security issue on ubuntuone-client on friday. We have  fix today, is there ay chance of uploading a fixed package?
<ogra_> you can in any case upload to the queue, letting the package in is a manual process during beta freeze
<ralsina> ogra_: thanks!
<ogra_> (assuming you talk about precise indeed :) )
<nessita> ogra_: yes, this is for precise. So, just dputting to ubuntu will leave the package in the proper queue?
<nessita> (hi there!)
<cjwatson> nessita: yes
<ogra_> nessita, right, you should see it being announced here by the queuebot
<nessita> ogra_, cjwatson: thanks!
<jdstrand> ralsina: is this only in the precise version?
<ralsina> jdstrand: yes
<jdstrand> ok
<cjwatson> pitti: FWIW most of my sponsored uploads from today can happily wait for post-beta2; in particular I'd prefer if busybox weren't accepted
<pitti> cjwatson: ack
<cjwatson> it's not a disaster if it is but I'd have to respin d-i
<cjwatson> pitti: pgraner/dbarth asked for us to wait until they've got a fix for bug 963633 uploaded before we start rolling images
<ubot2> Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] https://launchpad.net/bugs/963633
<cjwatson> (scrollback ~ 1 hour ago)
<pitti> cjwatson: I was told this only affects upgrades
<pitti> but ok
<pgraner> pitti, no true I got it on a freshly installed system as well
<pgraner> s/no/not/
<pitti> pgraner: ah, thanks for the update
<skaet> Daviey,  today's CD report still has server amd64 oversize.  Will we get one today that fits?
<Daviey> skaet: Today's was built before i made nay changes. :)
<Daviey> hold out.. still on track.
<skaet> :) ok
<Daviey> skaet: sorry for being brief, otp
<skaet> Daviey, np
<rickspencer3> hi skaet and dbarth
<dbarth> cjwatson, pitti, pgraner: sorry to report that the fix we were on is not working so far
<dbarth> so, it will take us still a couple of hours to confirm a fix
<cjwatson> perhaps we should go ahead and spin images anyway?
<skaet> hiya rickspencer3, about ^ ?
<pgraner> skaet, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/963633
<ubot2> Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress]
<pitti> gtk+2.0 armhf/armel are in pkgbinarymangler stage
<dbarth> i don't think we can give you a fixed package within the next 2-3h
<dbarth> :/
<pitti> but I guess if we'll respin anyway, or don't care about gtk 2 being out of date on the images, that's not a blocker
<rickspencer3> skaet, my gut tells me that unity is not going to be shippable before tomorrow
<pgraner> rickspencer3, +1
<rickspencer3> I'm watching didrocks et al debug it ... they are working hard, but there are no easy answers
<skaet> pitti,   can we revert the pocket copies, and go with the original one?
<skaet> (ie. one at freeze)
<pitti> skaet: for unity? no, we can't
<pitti> we could upload the whole stack as 5.8+really5.6 again
<pitti> in -proposed
<pitti> and then move over everything in a couple of hours when everything is built
<rickspencer3> pitti, skaet I would propose that we set a deadline for such a reversion
<skaet> pitti,  might be prudent to do that then,  and if no resolution by the time it builds.
<skaet> we switch over
<pitti> yes, sounds good to me; not sure if we also need to revert the compiz bits, or just unity
<cjwatson> skaet: reverting as +really5.6 is a giant mouthful
<pitti> didrocks: ^ ?
<cjwatson> do we REALLY want that?
<cjwatson> I don't mind setting a deadline for it, but I don't like the idea of doing it up-frfont
<rickspencer3> I would propose that we prepare to do that tomorrow
<cjwatson> *up-front
<didrocks> well, it doesn't impact beta2 as per see, the issue are only on upgrade
<rickspencer3> give the unity team 1 day to sort it out
<pitti> didrocks: pgraner says otherwise
<didrocks> hum, for the interface not showing?
<skaet> didrocks, ^ comments from pgraner...
<pgraner> cjwatson, I hit the blank desktop on a fresh install about an hour ago
<cjwatson> -> didrocks
<didrocks> pgraner: ah, can you please talk about it to duflu? he's on something else then
<didrocks> there are 3 bugs in fact
<skaet> dbarth,  didrocks,  how tightly is compiz tied in with unity fixes?
<pgraner> cjwatson, a netboot install then a apt-get install ubuntu-desktop and a reboot
<didrocks> and everyone is puzzled in it
<didrocks> skaet: we can revert compiz only, we didn't try it
<didrocks> skaet: because new compiz + old unity showed the hang that we workarounded
<skaet> didrocks,  so, best advice is to revert the entire stack and have it ready in proposed to switch to?
<skaet> if we don't get this sorted by end of day?
<didrocks> skaet: well, reverting the stack will take some hours still, so I continue to work like hard and try to get dx people on boardâ¦
<cjwatson> also reverting the stack will make it harder for people to reproduce and help ...
<didrocks> skaet: the revert will take approx 5 hours to proceed with the dep chain
<rickspencer3> cjwatson, pitti, skaet, didrocks thoughts about letting the unity team work for the next 24 hours to fix the bugs, and then work on reverting if it's not substantially closer to be being solved tomorrow?
<cjwatson> we could do with a bit under 24 hours really
<pitti> that gets really tight then
<skaet> rickspencer3, not sure we have 24 hours,   need to get the testing happening, and there could be follow on problems
<gema> agree with cjwatson , if we want to test it properly
<pitti> that means we'd be looking at candidate images Wednesday morning
<cjwatson> yes, particularly if we revert the whole stack that means it will take another 5 hours for the fix to build as we have to unrevert everything
<cjwatson> and adds that much more source of human error
<skaet> suggest we have until 1900 UTC and then decide,  revert or not.   And then have the images built.
<pitti> perhaps something like "give them 24 hours, and stage a reversion in -proposed in parallel when there is no solution in sight in 16 hours"?
<rickspencer3> pitti, that works for me
<didrocks> pgraner: so, when you upgrade
<skaet> didrocks,   uploading reverted stack - when?
<cjwatson> do we have any idea what percentage of users this affects?
<didrocks> skaet: well, if I upload the reverted stack now
<didrocks> that would mean nobody more will work on the fix
<didrocks> seeing as I'm the only one active on itâ¦
<pitti> didrocks: no need for "now"; we need it (fix deadline minux 5 hours)
<seb128> are we sure it affects lot of "new install"?
<skaet> what!
<seb128> everybody who did a unity --reset got it fixed so far
<gema> didrocks: why not, don't they want to fix it asap?
<pitti> err, shoudln't the whole DX team be all over this?
<seb128> it seems out pgraner most issues are upgraded profiles
<didrocks> seb128: seems not, with his new install + ubuntu-desktop metapackage
<didrocks> pitti: â¦
 * cjwatson wonders if pgraner has a separate bug; after all the symptom is quite generic-sounding
<pgraner> seb128, I don't know, I hit it like I said with a net install with the alternate installer then did a apt-get install ubuntu-desktop, rebooted and got the blank screen issue
<rickspencer3> hmmm
<seb128> that's quite a special install
<rickspencer3> that seems rather round-a-bout
<seb128> not a standard desktop install
<seb128> do we have any proof it happens with desktop images?
<cjwatson> perhaps worth a file-by-file comparison of that with a standard install
<rickspencer3> can someone who has the bug from upgrade do a fresh install and see it happens?
<seb128> also reverting would make us loose 1 week or trying to get that issue fixed for final
<didrocks> rickspencer3: until now, I didn't see any of this
<seb128> we can't stay on 5.6 for the lts
<pgraner> cjwatson, let me burn a usb stick and install on the same box
<rickspencer3> can someone take the responsibility of determining the scope of the problem? who is impacted (only upgraders?) and how many upgraders are impacted?
<rickspencer3> pgraner, someone from QA?
<pgraner> rickspencer3, sure jibel and I will work this
<pitti> bug 957805 is the oldest dupe, and reported against oneiric already
<ubot2> Launchpad bug 957805 in unity "Black screen after update on unity (with solution) (dup-of: 963633)" [Undecided,Confirmed] https://launchpad.net/bugs/957805
<ubot2> Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] https://launchpad.net/bugs/963633
<pitti> aside from that, it piled up some 25 dupes over the past two days
<rickspencer3> pitti, so it seems very widespread to you?
<pitti> so I think the first dupe was something diffent, or 5.8 just greatly aggravated the conditions under which this occurs
<skaet> pitti,  indeed,  which indicates its going to be fairly common, and critical is not unwarrented.
<pitti> yes, I think critical is appropriate
<rickspencer3> pitti, can we tell why some people get affected and some don't?
<seb128> one issue to consider is that going through with that will increase the chances to get it fixed by hard freeze, rolling back will put us behind on the goal
<pitti> just to have all options on the table, we could also release on Friday, couldn't we?
<pitti> rickspencer3: I can't
<rickspencer3> pitti, yes, we could release on Friday
<rickspencer3> but, let's not :)
<pitti> it's not my favourite either, as it extends the freeze quite a bit
<pitti> but we have -proposed for staging uploads, if people really want to
<rickspencer3> let's stick with Plan A (fix Unity) if at all possible
<pitti> I'm fairly sure that's everyone's favourite :)
<didrocks> so, unity --reset works for most of cases
 * skaet nods
<pitti> but can we ask for some more DXers to help out with this, instead of just didrocks?
<didrocks> we can even envision doing the settings revert ourselves
<didrocks> pitti: well, that's why I'm trying since this morning
<didrocks> duflu was on it, but it's late for him now
<skaet> pitti,  dbarth said duflu is working on it as well.
<didrocks> and he's not around anymore
<seb128> it's like 2am for him yeah...
 * skaet thought that was sam?
<cjwatson> there's bug 965390 as well; we could debate critical or high for that, but at any rate it looks like an easy fix
<ubot2> Launchpad bug 965390 in ubiquity "prompt to remove cryptsetup on an encrypted LVM install during end user setup" [Critical,Triaged] https://launchpad.net/bugs/965390
<cjwatson> (the alternate-ness there is not intrinsic; if we supported that partitioning mode on the desktop CD, as we'd like to do for Q, it would have the same problem there)
<seb128> skaet, sam and duflu both live in australia and both work on compiz
<skaet> thanks seb128
<cjwatson> damn that round planet anyway
<pitti> cjwatson: sounds like we'd have plenty of time to accomodate that fix..
 * skaet nods
<skaet> cjwatson,  you going to be working on that fix?
<cjwatson> yes
 * skaet can take over kicking images out later today
<cjwatson> just need half an hour or so for a test install to make sure I know the right fix
 * skaet nods
<pitti> skaet: we could then at least start building the non-ubuntu images and the ubuntu arm preinstalled
 * pitti wonders what's up with that gtk-2.0 build -- it's been sitting at pkgbinarymangler for an hour
<skaet> pitti,  yes,  that seems appropriate.
<pitti> skaet: oh, edubuntu has compiz, too
<cjwatson> get a webops to attach strace or get a ps dump or something?
 * pitti asks in the channel
 * didrocks can at worst try to do a http://launchpadlibrarian.net/60658417/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu3.diff.gz
<pitti> ^ accepting gtk+3.0, it's for -proposed
<pitti> everything else in unapproved is seeded somewhere
<stgraber> ^ is used by Edubuntu (AFAIK we're the only one shipping it), this upload contains a fix to a bug preventing arkose from working at all
<pitti> skaet, cjwatson: I wonder if I can go to Taekwondo now, or rather stay online for the evening?
<cjwatson> pitti: go on, I'll be around off and on for a bit
<pitti> ack; good night then!
<skaet> pitti, go to Taekwondo.  we're in wait mode now.   If you could check in when you get back
<skaet> would be appreciated
<pitti> skaet: yep, can do
<skaet> thanks pitti
<cjwatson> ^- that's for -proposed since ubiquity wants to be in sync across all architectures; please review/accept
<cjwatson> stgraber: accepted
<stgraber> cjwatson: thanks
<skaet> cjwatson,  looks like straightforward extra checking.  accepted.
<cjwatson> thanks
<dbarth> cjwatson, skaet, pitti: just an update about the bug; we're going with another workaround for now, since none of our fixes has proved to be 100% reliable so far
<dbarth> cjwatson, skaet, pitti: didrocks is building a package with a patch he used some time ago, to force a --reset on the plugin list
<didrocks> the difference is that I'll only do it on the plugin list
<didrocks> on the whole configuration
<didrocks> (and only once)
<dbarth> ie, the list of plugins is fixed-set, but the settings are preserved
<didrocks> but still, the real issue has to be worked on
<dbarth> eta? (sil2100 volunteered to do a sanity check on the packages)
<didrocks> he has a broken setting?
<dbarth> didrocks: no, just verify that there is no obvious regression, for whatever reason (since this patch is known to have worked before)
<cjwatson> so I guess you want to punt this into -proposed first?
<didrocks> cjwatson: yeah, seems better
<didrocks> cjwatson: I'm buiding it, it's a silly patch, but at least, it should unblock the situation for now
<didrocks> cjwatson: while we are at it, there is an unity patch which can make beta2 (bad interaction with software-center which can cause in a crash)
<cjwatson> didrocks: will need to see the patch, but ok ...
<slangasek> jibel: the latest upgrade failures of lucid-main are a strange regression that I can't reproduce locally by installing the lucid version of puppetmaster and then upgrading to the precise version.  Do you have any more info about what's happening here?
<slangasek> are we expecting the fix for bug #916291 in before beta-2?
<ubot2> Launchpad bug 916291 in libreoffice "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,In progress] https://launchpad.net/bugs/916291
<slangasek> well, in progress as of 4h ago; but not sure if that will land on CDs
<cjwatson> the build is 31 hours on armhf
<cjwatson> and pretty long even on x86
 * slangasek nods
<cjwatson> (12-13 hours)
 * skaet *blinks* at 31 hours on harmmhf...
<cjwatson> welcome to libreoffice :-/
 * cjwatson -> dinner
<slangasek> jibel: btw, I can't quite figure out why /etc/init/console-setup.conf is being shown as an obsolete conffile of console-setup in the lucid->precise upgrade, given that keyboard-configuration replaces this conffile and is shown as being unpacked... could we perhaps get a copy of /var/lib/dpkg/status from one of these systems post-upgrade?
<slangasek> wow, what is wrong with the javascript in jenkins?  It pegs my CPU
<didrocks> cjwatson: sorry for the time taken for the workaround, but compiz is making bad implication about what it should copy/erase under your feet
<didrocks> making a final build to ensure everything is fine
<skaet> Riddell,  pad doesn't seem to have kubuntu active on it for rebuilds,  can you add?
<infinity> doko: You were discussing a rebuild test last week, did you still plan to do that?
<skaet> Daviey,  when the fix lands from didrocks,  will the changes be there for server images to fit,  or will we still need to wait on that?
<skaet> s/fix/workaround/
<didrocks> skaet: thanks for hilighting it's a workaround, because it really is :)
<didrocks> (uploaded to -proposed, tested with a lot of reboot here)
<didrocks> but as I never got a hangâ¦ at least, for everyone it fixed with a --reset, it should work the same
<skaet> pgraner, jibel ^ who will be around to test the image once its built later today?
<Daviey> skaet: no, not yet. Unity isn't on the server cd btw :)
<pgraner> skaet, myself & hggdh
<skaet> Daviey,  it was more,  want to kick them all off at the same time.   Assumed you want to pick up the ubiquity bug
<skaet> or rather bug fix.  :)
<skaet> pgraner,  thanks.
<pgraner> skaet, I'm here as long as it takes and I'm making hggdh stay too cuz he loves this stuff :)
<hggdh> skaet: I am a mere paw in this game, I do what my manager volunteers me to
<skaet> pgraner,  glad of the company.  ;)
<skaet> hggdh,  glad of your company too.  :)
<hggdh> :-)
<didrocks> cjwatson: ^
<skaet> didrocks, cjwatson's at dinner,  looking
<didrocks> skaet: I targeted -proposed
<infinity> I'll look too.
<skaet> thanks infinity, didrocks
<infinity> didrocks: ...
<infinity> didrocks: You weren't kidding about this being a workaround. :P
<nessita> hello! the new ubuntuone-control-panel 2.99.91-0ubuntu2 has a minor fix where I added a missing dependency for a binary package
<didrocks> infinity: I'm always serious on my speech :)
 * infinity giggles at current_profile_gconfvalue.set_string('fooo')
<didrocks> infinity: yeah, compiz is aweful with the gconf backend
<didrocks> infinity: basically, copying you 2 trees
<didrocks> so if you reset some keys
<didrocks> you need to force again to copy the keys
<didrocks> this is triggered by the "profile" change
<infinity> Brilliant.
<infinity> Well, it appears to do what it's meant to do, +1 from me.
<infinity> Were "+1" is "+0.5" with an added "ew". :P
<skaet> infinity,  accepted then.
<skaet> infinity,  could you take a look at software-center as well?
<infinity> skaet: Already was. ;)
 * skaet thinking we might want to pick it up as well, based on the bug fixes mentioned in it.
<didrocks> infinity: yeah, I can only say "sorry for the kittensâ¦"
<skaet> nessita,  its been accepted now.
<nessita> skaet: thanks!
<infinity> skaet: Yeah, givne the obvious bugs I see fixed just in a cursory scan, there's no way s-c can be more broken than it was previously.
<infinity> (There's a ringing endorsement, right?)
<skaet> indeed
<infinity> But yeah, the theme oopses and the fixing of incorrect returns already looks worth it, and nothing else looks obviously wrong.
<infinity> (Accepted)
<skaet> infinity,  thanks!
<infinity> And picking up vorlon's bash-completion upload too.
<slangasek> that one's ultra-low priority for beta-2
<slangasek> but ok :)
<infinity> slangasek: Yeah, but if other things with longer build times are building anyway.
<infinity> slangasek: And if we're respinning anyay.
<didrocks> infinity: slangasek cjwatson pitti: I just hope we won't have any bad surprise with looking at the schema thing if nothing is setup (before even compiz is run for the first time). At worse, the smaller wrapper crashes the first time, but compiz will then still load (as it ignores the subprocess report)
<didrocks> I'll try with a new account to ensure
<infinity> didrocks: What's important is that you thought of that AFTER you uploaded. ;)
<infinity> didrocks: But yeah, the fact that compiz blindly ignores the return of the fork should be enough.
<infinity> Maybe.
<didrocks> infinity: yeah, just looked more at the compiz codeâ¦ and it's settings a *schema* for the current profile
<didrocks> not  using any normal "key"
 * Daviey wonders why keystone is in the desktop set.
<slangasek> looks like fatfingering to me
 * skaet curious about that as well,  dependency pulling it in?
<Daviey> nah, but NFI what is causing it.
<slangasek> no, I'm pretty sure that's just a bug in the packageset metadata
<infinity> Task: openstack
<slangasek> which someone will want to fix
<rickspencer3> if we can put Ubiquity on the server, we can put keystone on the desktop
<infinity> Oh, I guess that Task info is right.
<infinity> No idea why it's in the above sets, however.
<Daviey> infinity: i created an openstack Task.
<Daviey> I've seen similar skew before.. not too worried at this stage TBH
<infinity> Is it intentional that all this openstack stuff in universe gets the "Supported: 5y" tag, or is that an accidental side-effect of it being in the -server packageset?
<zul> infinity: the intention is to get it promoted to main
 * Daviey will take keystone
 * skaet sees some enlighted self interest on that last bit of volunteering :)
<Daviey> it's a universe package, so why would there be self interest :P
<skaet> infinity,  compiz on armhf seems to be triggering some unmet dependencies.  libgtk-3-0,  which has a package building,  just wait and retry or something more serious?
<skaet> https://launchpadlibrarian.net/98429219/buildlog_ubuntu-precise-armhf.compiz_1%3A0.9.7.2-0ubuntu2_FAILEDTOBUILD.txt.gz
<infinity> skaet: Just wait and retry, nothing to see here.
<infinity> (Well, nothing except a missing feature I meant to add to lp-buildd 5 years ago and didn't)
<didrocks> infinity: I tried in a blank new session and indeed there is a harmless stack, let me test a fix though
<didrocks> just try: except: pass (as if there is no schema, we don't want to enforce one)
<infinity> didrocks: Just test for the key existing first?
<infinity> Or that.
<infinity> Same net result.
<didrocks> infinity: it's not a key, it's a schema, gconf is not that nice :)
<didrocks> but yeah
<didrocks> the idea is that ;)
<didrocks> (it should be a key, but compiz makes it a schemaâ¦)
<infinity> Sadly, thanks to apport, there's no such thing as a harmless stack trace. :P
<infinity> Not in a development release anyway.
<didrocks> infinity: indeed, that's why I want to prevent that :)
<didrocks> the unity package here fix an interesting issue for beta2 IMHO ^
<didrocks> (do not freak out on the "inline patch", it's because I bzr merge using bzr merge-upstream workflow from upstream)
<nessita> hello again! the new ubuntuone-client 2.99.91-0ubuntu2 has a security fix where we removed some code that was logging the user's proxy credentials
<infinity> didrocks: Inline patches don't bug me.  I'm old enough to remember when diff.gz was nothing but. :P
<infinity> didrocks: Looks sane enough.
<didrocks> infinity: thanks!
<infinity> nessita: Eek.
<infinity> nessita: I'm not going to ask at what point someone thought it was a good idea to log that. ;)
<nessita> infinity: I can give some details... this is the first release we're doing with proxy support for UBuntu One, and thus the developers have been doing lots of work and lots of debugging was needed. Of course, we should have checked this before releasing to Ubuntu.
<infinity> nessita: Heh.  It happens.  Just a bit of an unfortunate oops.
<Laney> wow, caph is still busted?
<nessita> infinity: yeah :-)
<Laney> armel is not happy today
<nessita> thanks!
<infinity> Laney: Grr, I thought from backscroll in another channel that had been fixed.
<Laney> it had been
<infinity> Laney: I'm just going to set caph to broken and retry all those.
<Laney> on https://launchpad.net/builders/caph/+history you can see it worked for a small while
<infinity> On the other hand, the opportunity to mark a machine as a "sad panda" never gets old.
<Laney> didrocks: you might want to retry https://launchpad.net/~unity-team/+archive/staging/+build/3319350
<Laney> (chort was also affected, but seems to be building gtk+3.0 alright now)
<didrocks> Laney: it's fine, there will be a new commit soon and it will trigger another build :)
<Laney> righto
<infinity> The fact that this is hitting multiple machines doesn't make me feel good at all...
<Laney> yeah, and that it came back on one of them ...
<infinity> No recent updates to tar or bzip2, though.
<infinity> That would be too easy. :/
<Laney> 26/03 13:41:14 <wgrant> Laney: Yeah, the chroot file in caph's cache seemed to be randomly corrupted (correct length, incorrect content). We  forced it to refetch and it's happy now.
<skaet> infinity,  didrocks,  could you please look at https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.2-0ubuntu2 - attempted rebuild in armhf failed.
<infinity> skaet: Transitive, just needs gtk+3.0 to finish.
<Laney> btw, haskell-yesod-default could do with a nudge through NEW if anyone likes pressing buttons
<didrocks> infinity: speaking of which, here is the fix tested in a blank new session (and tested as well on existing ones, with different cases) ^
<didrocks> infinity: do not hesitate if you spot anything bad, should be straightfoward
<skaet> infinity was looking at the gtk-2.0,   now looking at the right place, and yup, seeing it is still finishing...  https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1
<infinity> Laney: Ugh.  Why does everything in the world end up build-depending on ghci? :P
<Laney> people keep on using Template Haskell
<infinity> Laney: (Actually, that's a half serious question, I don't know ghc very well, but why would one need an interactive interpreter at build time?)
<Laney> it's a compile-time metaprogramming extension
<Laney> I guess it shares code with the interpreter
<infinity> Fun.
<infinity> Well, here's hoping someone feels that should work on more than just x86 some day.
<Laney> Someone does, but not the same someone that gets paid for GHC sadly
<didrocks> infinity: does the change in compiz looks sane to you?
<infinity> didrocks: If AttributeError is the only thing it's going to throw, yep.
<didrocks> infinity: seems so from my tests at least
<didrocks> no GError or whatever
<infinity> Also, that diff touches on my one biggest annoyance with indenting-as-flow-control.  That diff is completely unreadable, where it could have been a 3-line diff in C. :P
<infinity> (Not that you'd want it as a 3-line diff if you were keeping it, but for a hack on a hack?)
<didrocks> infinity: yeah, and it makes you reading it 3 times to ensure you are not missing something obvious
<infinity> Yeahp.
<infinity> Anyhow.  I've read it 3 times, and accepted it. :P
<didrocks> accepted 3 times as well? :p
<infinity> Just the once.
<didrocks> I like diff -b, a pity there is not that option on the generated ones :)
<skaet> infinity, didrocks - reset the rebuild trigger to wait on that latest compiz drop?
<infinity> skaet: Aye.
<seb128> just for info, the GNOME 3.4 uploads I'm (and others are) doing to proposed are staging for post beta
<infinity> skaet: It'll be the same time anyway, given that arm* can't build it until GTK is done. :P
<seb128> it's to avoid cahos on friday after unfreeze and work duplication
<infinity> seb128: Check.
<skaet> thanks seb128
 * Laney likes this staging in -proposed business
<infinity> Yeah, we really should do it more.
<skaet> just means a bit more tracking when some are loading to -release, and some are loading to -proposed with the intent of it being copied over for -release.
<stgraber> ^ might fix an ubiquity bug (saying might as it's a race condition and it's not clear that it's indeed messing with debconf)
<stgraber> if it doesn't fix the bug, it'll at least do some useful logging
<GrueMaster> skaet: Could you add bug 963512 to the rebuild triggers list?  Everthing in arm+omap4 will need respin if/when this gets fixed.
<ubot2> GrueMaster: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/963512)
<skaet> GrueMaster, done.  added it to under investigation.
<GrueMaster> Thanks.
<slangasek> stgraber: which ubiquity bug might it fix?
<stgraber> slangasek: bug 964857 at least (I seem to hit it every 5 installs or so here)
<ubot2> Launchpad bug 964857 in ubiquity "12.04 Beta 2 candidate install stuck at "Configuring target system..."" [Undecided,New] https://launchpad.net/bugs/964857
<cjwatson> I've accepted it, it's definitely correct
<cjwatson> though I'd have used echo >&2 rather than logger, but meh
<stgraber> slangasek: the only way you can track it down is if running with debconf debug turned on, otherwise it just hangs
 * slangasek nods
<slangasek> huh, wasn't there another instance of that bug reported previously?
<slangasek> ISTR seeing it on one of the bug lists
<cjwatson> staging in -proposed> it'll be great once we have any tools at all for managing it
<cjwatson> slangasek: target-config scripts get it wrong from time to time, but I don't remember noticing it in g-k before
<stgraber> yeah, I think we had it reported already or something very similar anyway. I just looked at the "recently changed" list on LP and picked the first one matching what I had in my VM :)
<slangasek> I don't know if anyone fingered g-k for it, but I do think I saw another bug with that description
<slangasek> checking
<cjwatson> there was an ubuntustudio one you may be remembering
<cjwatson> I fixed it in casper recently-ish
<slangasek> oh, I was thinking of bug #946663, which is a different hang
<ubot2> Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663
<infinity> didrocks: Oh, pretty please tell me there'll be a less insane fix for that bug in the next week or so?
<cjwatson> I'm going to add logging to ubiquity to make it vaguely feasible to debug this
<didrocks> infinity: I totally hope so. I told dx that no more code will enter precise before there is a sane fix for it
<didrocks> infinity: do not forget that I uploaded to -proposed, so a copy will be needed before triggering the iso rebuild
<infinity> didrocks: Well, even if a sane fix can't be found, a less insane workaround in C/C++ that doesn't have compiz forking python? :P
<didrocks> infinity: oh, that's for sure at least :)
<didrocks> infinity: I just went to the quickest
<didrocks> infinity: I try to sneaked another workaround better in libcompizconfig before
<didrocks> but the code path is insane
<didrocks> and even sam was giving bad directions, with functions not called at boot
<didrocks> (before == earlier today)
<didrocks> just went to the urgency nowâ¦
<cjwatson> slangasek: ah, and when jodh was trying to debug that, it looks as though he ran into the bug stgraber just fixed
<cjwatson> (comment 30)
<cjwatson> tools> hey, I guess we have suite-diff.py at least, crude though it is
<cjwatson> for x in main restricted universe multiverse; do suite-diff.py ubuntu/dists/precise{,-proposed}/$x/source/Sources.gz lt; done
<cjwatson> anyone mind if I copy the ones that are done
<cjwatson> ?
<cjwatson> they'll probably go into the queue actually, I'll give it a try
<skaet> cjwatson,  yes please copy over the ones that are done.
<cjwatson> ok, those look like the two that require copying right now
<cjwatson> compiz seems to have failed to build on ARM?
<skaet> cjwatson,  watch out for the gnome ones though - they're just hanging around there until after beta 2
<didrocks> cjwatson: was gtk mismatch, isn't it?
<cjwatson> oh, right
<skaet> cjwatson,  was waiting on gtk-3.0 building
<cjwatson> skaet: yeah, I skipped gtk+3.0 and gnome-panel
<cjwatson> does it matter if we copy compiz built against new gtk+3.0, but not gtk+3.0?
<seb128> cjwatson, skaet: there is not issue accepting any of the GNOME updates (i.e if you do that by error don't worry), they are mostly translation updates
 * cjwatson checks shlibdeps
 * skaet was worrying about that...
<seb128> cjwatson, gtk didn't bump shlibs
<didrocks> so should be fine
<seb128> none of the GNOME update would bump anything, they were code frozen since .92
<cjwatson> confirmed, it just has compiz-dev Depends: libgtk-3-dev
<cjwatson> (unversioned)
<infinity> Surely, it's the non-dev deps that are interesting...
<cjwatson> there weren't any
<infinity> Oh.
<cjwatson> given back compiz/armhf; armel will need to wait a bit more
<infinity> Quite a bit more.  The build had to start over, thanks to whatever's plaguing chort and caph.
<infinity> Looking into that.
<cjwatson> $ grep-aptavail -nsPackage -XS compiz -a -FDepends libgtk-3 | sort -u
<cjwatson> compiz-dev
<didrocks> infinity: cjwatson: yeah, the build-dep was optional at some point, but you can still used compiz-dev that exposed some gtk API for a conditional build
<cjwatson> I suppose technically there's libgail-3-* too but blah
<didrocks> seems the dep changed and we should maybe build-dep on it
<didrocks> (with all the unity-window-decorator apart from gtk-window-decorator and now back inâ¦)
<skaet> cjwatson, infinity:  http://pad.ubuntu.com/ubuntu-release is up to date now I think.   [5] and [9] are pretty much waiting on armhf build,  then [5] needs to be copied over,  then can trigger the rebuilds.   See anything missing?
<cjwatson> infinity: https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1/+build/3319831 is pretty wacky
<cjwatson> Currently building on nasl (arm panda) on chort (arm panda)
<cjwatson> panda-on-panda action, apparenty.
<cjwatson> +l
<infinity> cjwatson: Yeah, that's just a display bug.
<infinity> cjwatson: It'll self-sort once the build on nasl is done.
<cjwatson> Daviey: server size> dropping mailman looks like it'd come out fairly close?
<cjwatson> skaet: we shouldn't copy over compiz until builds on all architectures are done, even if they aren't release architectures.  I'm fairly sure LP won't be happy otherwise, and if we do that it may not be possible to copy compiz/armel at all until there's a new version.
<skaet> cjwatson,  including waiting for armel?
<cjwatson> This is a particularly hairy part of LP and it's best treated with kid gloves.
<cjwatson> Yes.
<skaet> Noted, and thanks for the warning.
<cjwatson> (LP may not even let you, but I don't want to try.)
<slangasek> based on past experience, I expect LP will let you copy and then you'll be screwed wrt getting the binaries over
<skaet> lovely... :P
<cjwatson>             # Conflicting candidates pending build or building in a different
<cjwatson>             # series are a blocker for the copy. The copied source will
<cjwatson>             # certainly produce conflicting binaries.
<cjwatson>             build_summary = candidate.getStatusSummaryForBuilds()
<cjwatson>             building_states = (
<cjwatson>                 BuildSetStatus.NEEDSBUILD,
<cjwatson>                 BuildSetStatus.BUILDING,
<cjwatson>                 )
<cjwatson>             if build_summary['status'] in building_states:
<cjwatson>                 raise CannotCopy(
<cjwatson>                     "same version already building in the destination "
<cjwatson>                     "archive for %s" % candidate.distroseries.displayname)
<cjwatson> But you probably won't see that error anywhere terribly useful and you'll be left trying to divine it from chicken guts.
<cjwatson> So, yeah, you gotta wait.
<skaet> cjwatson, urk.  indeed.
<slangasek> (that's why I have my checkout of lp:haruspex)
<cjwatson> (Similarly it checks for unpublished binaries.)
<skaet> cjwatson,  has debian-cd/CONF.sh been set to OFFICIAL?
 * skaet doing a pass for the release-3 day checklist
<cjwatson> OFFICIAL has been set to Beta there, yes
<infinity> cjwatson: Oh, for the record, if you copy/move something from pocket A to pocket B (and then remove it from A), you can still repair the issue for unbuilt arches by just copying the source back to pocket A, building, and copying to B again. :P
<cjwatson> erk
<infinity> cjwatson: (I've done this a few times)
<cjwatson> Beta-2 still
<cjwatson> that really needs to go to Beta as I explained this morning
<cjwatson> otherwise it busts wubi
 * cjwatson cowboys that for now
<infinity> cjwatson: Not that I recommend relying on this fallback, but it works if someone messes up and does a partial copy.
<cjwatson> ew
<cjwatson> creative but foul
<cjwatson> and you end up with a spaghetti publishinghistory
<infinity> The history is arguably less important than the result.
<infinity> But yes, it's not ideal.
<skaet> proposed gtk+3.0 has built armhf, but not armel yet...  which is still in the chain for compiz...
 * pitti waves
<pitti> so, I see we have a workaround for unity after all, nice
<pitti> gtk+2.0 finally built at last, I'll move to precise
<skaet> hiya pitti,   board is up to date.   we probably need to talk about conventions a bit for what goes in proposed, and when,   some extra tracking has been needed.
<cjwatson> I already did
<cjwatson> pitti:
<pitti> cjwatson: ah, thanks
<pitti> skaet: well, when in doubt, use -proposed
<cjwatson> skaet: we're trying to do all this in advance of the plan of record for adding tools ;-)
<pitti> skaet: in particular, anything with nontrivial build times, anything which, when it fails on only some arches woudl have a devastating effect, and anything which involves library transitions
<skaet> pitti,  not so sure about that,  since extra tracking and interactions with other stuff in propsed...
<cjwatson> not that it's a *detailed* plan of record, but
<pitti> like, LibO is a definitive example for -proposed
<skaet> pitti,  latest compiz should have been in -releases..
<pitti> as it makes armhf uninstallable for two days otherwise
<pitti> compiz/unity are as well, due to a build dep chain of at least 3
<skaet> pitti,  yup +1 on that example.
<skaet> pitti,  problem is when other parts of that chain are preseeding into -proposed  gtk+3.0 for instance.
<cjwatson> there is a well-established tool for all this in Debian
<infinity> britney? :P
<cjwatson> we need to figure out how to integrate it without going insane in other ways
<cjwatson> yes
<infinity> I wonder how well it would perform if you just ran it without the aging period.
<infinity> So, jam stuff in ASAP when it can.
<cjwatson> something like that; needs experimentation
<Daviey> cjwatson: Yep, i have that in my local branch.. trying to find a few other things.
<cjwatson> does it need more?  that looked like about 9mb iirc
<Daviey> cjwatson: Is it really that big?
<Daviey> wow
<cjwatson> I assumed you'd started your investigations with a sorted-by-size list of packages.
<Daviey> cjwatson: I was trying to make space for keystone aswell, but that can(will) slip b2.
<cjwatson> ah
<Daviey> cjwatson: No, i was using a poke-it-and-see approach
<cjwatson> mailman is Size: 9648660
<cjwatson> on i386
<cjwatson> um, I strongly recommend sorting by size :)
<pitti> Daviey: btw, do you know about ~/iso-deb-size-compare on nusakan?
<cjwatson> otherwise you waste a lot of time on things that look complex but are small
<Daviey> pitti: i do not..
<pitti> Daviey: you give it two (alternate-style) isos, and it gives you an overview of added, removed, and significantly grown packages
<Daviey> that looks handy
<pitti> i. e. you can compare it against the beta-1 image etc. and see what grew fat
<Daviey> cjwatson: I was trying to work out why the heck we have, computer-janitor
<pitti> Daviey: c-j has a CLI backend
<Daviey> i thought it was dropped..
<Daviey> isn't that barry's project?
<pitti> and given that we never worked out how to get rid of the plethora of kernels that pile up, it's the next best thing..
<Daviey> pitti: we do have a kirk-o-matic this cycle, no?
<slangasek> a what now?
<pitti> Daviey: ?
<Daviey> I thought kirkland produced a script to scrub old kernels?
<pitti> do they get beamed away?
<pitti> ah, I'm sure there's a bunch of those around
<cjwatson> Daviey: Size: 34648 => not worth thinking about
<Daviey> cjwatson: Well there are a few crap things we can drop, including fortunes-ubuntu-server :)
<cjwatson> Size: 32298
<Daviey> the small things do add up, right?
<cjwatson> it's a lot quicker to go for the big things first
<Daviey> ok
 * Daviey bzr reverts
<cjwatson> you'll be arguing forever if you try to chip away at small things
<cjwatson> not that it isn't worth removing them if they're pointless, but they aren't really useful low-hanging fruit ...
<slangasek> Daviey: Dustin may have written a script, but I don't believe such a one has been integrated anywhere
<Daviey> cjwatson: puppet would remove ruby?
<pitti> Daviey: http://paste.ubuntu.com/901079/
<pitti> Daviey: diff between beta-1 and current daily i386, FYI
<slangasek> puppet+facter are the only reason for ruby in main at all, IIRC
<Daviey> pitti: right, those are by design.
<Daviey> but very useful if an iso balloons by suprise!
<pitti> rabbitmq-server (Î 1.6 MB - 2.6.1-1ubuntu4: 1.2 MB   2.7.1-0ubuntu2: 2.7 MB)
<slangasek> it's by design that rabbitmq-server doubled in size? :/
<pitti> that looks worth a second look
<Daviey> slangasek: I'd like puppet still seeded, but don't care for it on the iso.
<cjwatson> rabbitmq-server borged several smaller packages
<slangasek> mmk
 * skaet notes unity is done.... still waiting on the gtk+3.0 build for armel, so that compiz armle can build, and then get copied over...  grr.
<cjwatson> bug 948993
<ubot2> Launchpad bug 948993 in rabbitmq-stomp "[FFe] [MIR] rabbitmq-stomp, rabbitmq-erlang-client" [Undecided,Fix released] https://launchpad.net/bugs/948993
<slangasek> bwuh?  libgconf-2-4?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/libgconf2-4 -> checkbox-cli
<pitti> docutils-doc (1.3 MB)
<Daviey> slangasek: it increaed because 2 seperate source packages beacme part of it upstream.
<slangasek> cjwatson: ah, doh
<Daviey> slangasek: as in, they were seperate sources upstream, now part of core
<slangasek> Daviey: right
<cjwatson> well, checkbox-cli Depends: checkbox Recommends: gstreamer0.10-gconf Depends: libgconf2-4
<cjwatson> most of the increase was MaaS, realistically, wasn't it?
<cjwatson> so I think you have to look for pre-existing stuff
<cjwatson> Daviey: you could move puppet to platform.precise/supported-misc-servers, then, I guess
 * pitti is slightly confused about the "Finished ..." line on https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1/+build/3319831
<pitti> was gtk+3.0 build aborted and restarted, in a weird way?
<cjwatson> 20:42 <infinity> cjwatson: Yeah, that's just a display bug.
<cjwatson> 20:42 <infinity> cjwatson: It'll self-sort once the build on nasl is done.
<cjwatson> pitti: ^-
<cjwatson> and yes, it was
<pitti> ah, thanks
<cjwatson> 20:34 <infinity> Quite a bit more.  The build had to start over, thanks to whatever's plaguing chort and caph.
<Daviey> http://pb.daviey.com/0L3V/
<pitti> so, at this point I have the feeling that I can be more useful tomorrow early morning
<Daviey> cjwatson: yep, same with bacula and tomcat
<Daviey> and awstats
<cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/ruby1.8 says puppet and facter, yes
<skaet> pitti, thanks for checking in.   see you on the flip side.
<cjwatson> and puppetmaster
<pitti> ack, good night!
<Daviey> most of the python-* things i've listed were added to flag them for MIR, really they are already there through depends
<skaet> pitti,  sleep well.
<Daviey> i'm waiting for elmo to kick me for dropping zsh from the cd pool.
<cjwatson> so are you going to move those to supported-misc-servers or some other supported-*?  I don't think this should be intrinsically linked to dropping stuff out of main
<infinity> Daviey: I doubt elmo cares deeply what's on the ISO.
<cjwatson> it can't be in the one commit unfortunately due to the seed structure, but it would be nice for future archaeologists if the commits were at least close together in time
<infinity> Though, to be fair, I doubt that 99% of cloud users care either.
<infinity> Which makes a lot of this shuffling feel odd to me.
<infinity> I'd rather have stuff to make a "small business server" on the ISO than stuff that most users will do via pre-seeding and local mirrors.
<Daviey> cjwatson: I will added them elsewhere to make sure they stay in main.
 * skaet going to get some food while waiting for those builders to finish off..  biab
<Daviey> cjwatson: I'm going to wait to see what changes on c-m, candiates for demotion, before re-adding them elsehwre.. It might be duplicated content.
<kirkland> slangasek: Daviey: I have one, I was just putting it in bikeshed, until such time as you folks agreed on where it should/would live
<slangasek> kirkland: ah, alrighty.  Yeah, cf. ubuntu-devel discussion from last month :)
<kirkland> slangasek: yup
<cjwatson> Daviey: OK - you could run germinate locally though
<kirkland> slangasek: I didn't see that discussion come to a consensus that this was something that ubuntu-devel@ wanted to solve in general for users, in a seeded, supported manner
<Daviey> cjwatson: I could.. but is there any benefit from having it done for me?
<slangasek> kirkland: er, I would have assumed that was the consensus from the outset
<kirkland> slangasek: so we, as users of ubuntu-server in production, have our own scripts (that are now rebased on what kees sent to the list)
<cjwatson> Daviey: anyone else who looks at c-m asynchronously from this may get confused and process some of the output? :-)
<slangasek> no one likes /boot filling up, it's just been awkward to integrate without the risk of regression
<kirkland> slangasek: okay, where should I put what I have?
<slangasek> I don't know ;)
<kirkland> slangasek: heh
<slangasek> but it's also certainly not server-specific
<Daviey> cjwatson: Okay, Okay! :)
 * cjwatson goes to look after the kids for a bit.  SMS me if needed
<Daviey> slangasek: Why doesn't linux-generic depend on the current kernel, Recommend on current-1, and let apt clear up?
<Daviey> slangasek: if users want a specific kernel, they should install it directly	
<slangasek> Daviey: because current-1 is not necessarily the kernel you last booted successfully or have running currently
<kirkland> slangasek: I'll post what I have to ubuntu-devel as a followup now
<kirkland> slangasek: well, as soon as I can
<infinity> Daviey: Because that doesn't help if the one you're booted... What he said.
<infinity> This really needs to be a kernel postinst hook, so we know right that moment what "latest installed" and "currently running" are.
<infinity> And we can mark them as auto-installed at that point, so autoremove reports them.
<infinity> (Mark the ones we don't want anymore, that is)
<kirkland> pitti: would a shell script, remove-old-kernels (that accepts an optional parameter of --all-but INTEGER number of kernels), be acceptable to the computer-janitor package?
<Daviey> current, and current-1 seems reasonable IMO.. if you have a troublemaker kernel, mark it as isntalled, and/or don't autoremove.
<slangasek> why are you asking pitti? :-)
<kirkland> Daviey: would the computer-janitor package (with its dbus dependencies) be acceptable for the server seed?
<slangasek> computer-janitor belongs to foundations
<kirkland> slangasek: sorry, I thought it was pitti's
<Daviey> How many users who get failed boot, would know to tap down to current-2 in grub?
<infinity> Daviey: We don't want people removing running kernels.
<Daviey> slangasek: pitti mentioned it had a cli backend, so i was discussing the project with him. :)
<slangasek> kirkland: I think we would prefer to see this included in apt itself
<slangasek> (which is where the kernel autoremoval blacklist already lives)
<kirkland> slangasek: okay, then I'm not of much help, then
<infinity> slangasek: What of my above suggestion?
<slangasek> I mean the apt package, not the apt binary
<slangasek> infinity: and have apt provide that hook?
<infinity> slangasek: I suppose apt could, since it'll ultimately be calling back there to update the auto/noauto status.
<Daviey> slangasek: We have 'recovery' mode on cd media to allow people to unblock themselves, right?
<slangasek> Daviey: er, if the currently booted kernel is current-3, there's no reason to install current-1 *at all*; so the last-good-boot kernel should still be the second boot option
<Daviey> slangasek: right, and there is no need to do security updates, ever.
<slangasek> non sequitur
<infinity> Daviey: The only two kernel people should have in a fully automated setup are "latest from the archive" and "currently running".
<slangasek> the kernels you care about keeping on the system are the one you're running, and the newest one
<Daviey> I think the problem is being overcomplicated IMNSHO.
<infinity> I think we just reduced it to something fairly simple, actually.
<infinity> But YMMV.
<Daviey> The target audience for this problem is powerusers or less-than-powerusers?
<infinity> Everyone.
<infinity> There's no difference.  No one wants their current kernel removed, some people just don't know they don't want that.
<Daviey> ok
<slangasek> among other things because removing the current kernel means you can't auto-load any of the modules it contains, which you might be in need of between now and your next reboot
<infinity> And it's also the only kernel we currently know actually functions on your hardware.
<slangasek> yes
<Daviey> a hook does allow granular end settings of behaviour easier, i suppose
<phillw> we use https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels as we never quite know what the user is up to :) (The advanced one is being re-written as it looks a mess!).
<infinity> phillw: *smirk*... I like the Problems section.
<phillw> infinity: we were really stuck, when a guy had done it!
<phillw> one of the forum staffers suggested about the link for when you are poking about.
<Daviey> *sigh*, who approved keystone?
<ScottK> Daviey: I did.
<ScottK> It's in universe and unseeded.
<Daviey> ScottK: No, it's no unseeded.  It's in universe, and showing in c-m.
<Daviey> I specifically said i was reviewing it.
<ScottK> Sorry.  Missed that.
<Daviey> Sorry, it *is* seeded.
<ScottK> Got that.  My mistake.
 * skaet notes gtk+3.0 is still building for armel, and blocking compiz. :P
<bdrung> hi, may someone look at the FFe bug #965659?
<ubot2> Launchpad bug 965659 in shunit2 "FFe: Sync shunit2 2.1.6-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/965659
<skaet> infinity,  compiz is build in proposed for all but the armel port 9which is waiting still on gtk+3.0) to build.   Any ideas how much longer its going to take?  am wondering if worth making a much and copying compiz over to -release, so we can start rebuilding the images....
 * skaet looks back at that sentence and shakes her head.
<skaet> compiz is building in proposed for all but the armel port (which id waiting on a gtk-3.0 in proposed that it doesn't need to, and armel isn't a factor for the images).   Any ideas how much longer the gtk+3.0 build is going to take, and then the armel for compiz?  am wondering if its worth making a "mess" and copying over the compiled compiz binary bits to -release so we can start rebuilding the images...
<skaet> infinity, slangasek, ^ thoughts?
<ogra_> skaet, armhf is there ?
<skaet> ogra_, yes armhf is done.
<skaet> we're waiting on something that we don't need from what I can tell.
<ogra_> well, it would need careful handling of the image builds ...
<skaet> https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.2-0ubuntu3
<tumbleweed> skaet: would you mind throwing a mention of seeded-in-ubuntu into future freeze announcement e-mails? We've noticed that most DMB applicants haven't come across it yet
<ogra_> iirc infinity did split the builds into armel/hf but you will likely still have to define ARCHES=
<ogra_> beyond that i dont see why armel shouldnt just be copied later
<slangasek> because you can't "just copy later"
<skaet> ogra_ http://pad.ubuntu.com/ubuntu-release has the commands, and they're split.
<slangasek> the binaries have to all go in at the same time
<slangasek> so either we wait, or we can't release any armel images for beta-2
<ogra_> slangasek, do we care about armel ?
<slangasek> (I'm not sure we need to release any armel images for beta-2 though, so that's the question)
<ogra_> as long as armhf is there i think its fine
 * skaet nods,  its not on the manifest. 
<ogra_> armel is a best effort thing now
<skaet> other than in core...
<ogra_> well, core doesnt carry compiz )
<ogra_> :)
<skaet> and its not in server either,  which is the other one that wasn't split.
<skaet> there is kubuntu preistalled though...
<ogra_> armel ?
<slangasek> that seems like a bug in the manifest, because there's certainly no kubuntu preinstalled being built for armel
<ogra_> hmm
<skaet> yeah,  manifest only calls for armhf,  so we should probably just edit the buidl script on this one.
<slangasek> skaet: so we're looking at roughly another 1.5h before compiz would be ready on armel; if we want to say compiz will not be installable on armel for beta-2, so be it
<slangasek> as long as we get another compiz upload after beta-2 to get it back in sync
<skaet> slangasek, yes, now the question is does someone feel confident in doing the copies over?
 * ogra_ doesnt get the "have to go in at the same time" part 
<ogra_> if i upload compiz to the pool the binaries wont show up at the same time either
<skaet> ogra_,  check out the backscroll,  good discussion earlier between cjwatson and infinity on the subject.
<ogra_> k
<ogra_> (indeed i didnt reall everything above :) )
<ogra_> *read
<slangasek> I also would point out here that gtk+3.0 in proposed doesn't seem to even be targeted for beta-2, so the fact that it gets in the way of a compiz rebuild is a telling example of how diverting everything to proposed for building is not a guarantee of keeping development velocity high during freezes without paying a price elsewhere
<skaet> yes
<slangasek> skaet: what are the packages in -proposed that are supposed to be copied?  Is it just compiz?
<skaet> slangasek,  its just compiz at this point.
<skaet> other bits were copied by cjwatson earlier
<skaet> http://pad.ubuntu.com/ubuntu-release
<slangasek> skaet: you know, another option we have is to do a no-change upload of compiz to the release pocket *instead* of the proposed pocket, which would get you x86 binaries as quickly as a pocket copy would, and arm* binaries within an hour
<skaet> slangasek,  that would work too, and I'd feel a bit better it being compiled against the pieces it was actually meant to be compiled against.
<skaet> s/it/compiz/
<bjf> skaet: just fyi: Oneiric, linux-3.0.0-17.30 and Hardy, linux-2.6.24-31.100 are ready to be copied to -updates at someones convenience
<skaet> bjf,  ok.
<slangasek> skaet: compiz -0ubuntu4 uploaded to precise
 * skaet hugs slangasek
<ogra_> slangasek, and another option would be to mangle the seeds to not install unity in armel, its not like it would actually be possible to *run* compiz on armel :)
<slangasek> ogra_: the seeds don't matter for this if we're not building armel images anyway; this is just about the archive consistency
<ogra_> though i guess that would end up in dependency hell
<slangasek> skaet: so if you can accept that immediately, we'll have compiz ready to go for x86 image builds within the hour
<ogra_> yeah, i wasnt 100% serious there :)
 * skaet doing
<ogra_> its just a shame that we get issues with SW that nobody is able to run anyway
<slangasek> i.e., we'll miss the :03 publisher run and catch the :33 run
<skaet> its approve now.
<cjwatson> skaet,slangasek: and for the record, a reupload was the *only* way to bypass the armel build here.
<ogra_> silly LP
<cjwatson> as I explained earlier, LP would have rejected an attempt to copy from -proposed while the armel build was still in progress, AIUI because doing so would have created another conflicting build job in the release pocket.
<ogra_> yeah, i understood that, still ...
<cjwatson> feel free to hack on LP to remove the need for the restriction!
<cjwatson> I don't think it's arbitrary given the current code
<skaet> we're going to need to be careful about what we upload to -proposed,  when there is a potential dependency in it, that is different from what's in -release.
<cjwatson> yep - until our tools are much improved, it should only be used when we know the benefits outweigh the costs
<Daviey> cjwatson: Debian doesn't allow migration from unstable to testing if there are still pending binaries aswell, right?
<Daviey> Did LP copy that logic?
<ogra_> debian doesnt allow it, but i think technically it would be possible with dak
<cjwatson> no, it's more subtle than that in Debian
<ogra_> (correct me if i'm wrong)
<cjwatson> the LP restriction arose independently, from what I can tell
 * Daviey cries at having what should be an init script, in /usr/sbin/
<cjwatson> in LP it's more a consequence of a limitation of the current model, rather than the (AFAICR sometimes overridable) policy decision that it is in Debian
<ogra_> anyway, we dont build any armel images at all apart from core and moving armel to best effort but then letting it block us based on a package you cant even run on that arch seems inconsequent
<cjwatson> certainly in Debian the restriction is not there to avoid triggering conflicting builds in different contexts
<cjwatson> the LP restriction here does not take any account of the "importance" of an architecture
<cjwatson> we can rail about that all we like but I respect their opinion that db integrity takes precedence
<Daviey> cjwatson: I do find it odd that after a given time, dep-wait's are allowed to move to testing.. but AIUI, the dep-wait won't be satisfied in testing ever?
<Daviey> as in, the build won't happen.
<cjwatson> err that sounds like a confused version of something
<cjwatson> dep-wait isn't something that applies to suites in that way, apart from anything else
<cjwatson> the rule in Debian for unstable to testing propagation is that the total uninstallability of testing may not be made worse by promoting a set of packages
<cjwatson> sorry, a rule, there are several
<Daviey> cjwatson: no, i mean - after the age is satisfied, whatever is built is migrated to testing, providing there are no ftbfs.. dep-waits aren't a factor, right?
<Daviey> And a dep-wait won't be triggered in testing, when the dep is satisfied, right?
<cjwatson> no, that isn't accurateq
<Daviey> cjwatson: the premise or the build?
<cjwatson> your statement
<cjwatson> another of the rules is that a package must be built on all the release architectures where it was previously built
<cjwatson> it doesn't matter why it didn't build, if it didn't
<cjwatson> ftbfs == dep-wait for this purpose
<Daviey> and if it wasn't previously successfully built on a given arch?
<cjwatson> then that isn't considered
<cjwatson> (this is policy rather than an implementation restriction, and may be overridden)
<Daviey> and when it does hit testing, if the dep-wait is satisfied, will it be given back?
<cjwatson> builds happen in unstable, not testing
<cjwatson> it's entirely possible for a dep-wait to be satisfied later in unstable, the package to be built, and the build for a single arch to be promoted to testing if it meets the other criteria
<cjwatson> this happens routinely
<Daviey> ok, thanks.
<cjwatson> it's quite deliberate that builds don't happen in testing, because that would make it difficult to apply the consistency checks to them
<cjwatson> though there is testing-proposed-updates for security updates to testing when unstable has diverged badly
<cjwatson> I wouldn't expect we'd want -proposed to diverge that much
<Daviey> That was my thought, but I thought that new bins couldn't be considered separately.
<Daviey> I was wrong. :)
<cjwatson> it's the only way for a new architecture to be added to testing; but it also happens when an arch is catching up for one reason or another
<cjwatson> Debian's archive system is very flexible, and the flexibility is used.  The price is that the Debian release team has to spend a lot of time babysitting the testing promotion process, because it's quite easy for lots of things to get intertwined in unstable - mainly though not entirely due to the enforced delay.
<cjwatson> But I think we could make use of much of the same code that implements the core logic, with different policy.
<Daviey> cjwatson: Do you think an enforced delay would be helpful in our dev cycle?
<Daviey> (and dropping/shrinking the freeze windows)
<cjwatson> Not really.  The purpose of it is to allow some time for release-critical bugs to be filed.  I'd rather hook it up to automated testing for that.
<stgraber> oh, fun, my gnome-keyring upload failed to build on amd64 and i386: https://launchpad.net/ubuntu/+source/gnome-keyring/3.2.2-2ubuntu2
<cjwatson> In general I think there's a lot to be said for the Debian testing process, but the delay is one of the least pleasant aspects of it.
<stgraber> anyone from desktop still awake at this time? (it's definitely not my one line change in a script that caused it ;))
<Daviey> stgraber: the perils of TIL :)
<Daviey> doko has caught me on that too many times.
<cjwatson> has gnome-keyring been built since the last p11-kit upload?
<Daviey> cjwatson: Yeah.. we've been doing automated CI to a testing PPA for much of the stuff we care for... But it doesn't stop other crap spilling in.
<cjwatson> Daviey: sure, I don't think we should be aiming for something that prevents all possible badness; we need to preserve velocity too
<Daviey> right!
<Daviey> cjwatson: limiting the ability to add crack as the freeze window looms is also desirable. :)
<stgraber> cjwatson: last upload was on the 1st of February, so no
<Daviey> stgraber: someone from my loco reported this morning,  < AlanBell> anyone else getting *** VTE ***: Failed to load terminal capabilities from '/etc/termcap' when launching gnome-terminal today on 12.04
<Daviey> So before your upload.. might be related..
<broder> Daviey: you have to close all terminals
<cjwatson> stgraber: hmph, there goes my best guess
<cjwatson> Daviey: gnome-keyring doesn't depend on vte
<broder> Daviey: gnome-term is a single process for all terminals, and it's running with the old libvte
<Daviey> okay, sure... seemed worthy to mention.
<cjwatson> stgraber: oh, wait, by "no" you meant ... err ... "no".  I forgot the sense of my question. :-)
<stgraber> cjwatson: right, by "no" I mean it's perfectly possible p11-kit is the problem :)
<stgraber> what's interesting is that only i386 and amd64 failed, I'm used to all the other ones failing ;)
 * cjwatson tries in a local sbuild
<stgraber> also wondering why the build on armel took 50 minutes but the i386 one took 3 hours...
<cjwatson> because it hung in the test suite and waited for the timeout
<cjwatson> I notice it failed a few tests before that, which don't (all, anyway) seem to fail locally
<stgraber> fun...
<Daviey> racey test suite \o/
<Daviey> django's is the same, i get scared each time i touch it.
<skaet> stgraber,  https://launchpadlibrarian.net/98459486/buildlog_ubuntu-precise-amd64.gnome-keyring_3.2.2-2ubuntu2_FAILEDTOBUILD.txt.gz
 * skaet reads the backscroll, and sees you're looking into it.
<skaet> sorry
<cjwatson> hm; well, for me, it's test-gnupg-collection that hangs
<stgraber> I guess I could hit retry until it builds, but that sounds like a waste of buildd power when we're not even sure it'd eventually succeed :)
<cjwatson> it doesn't look particularly unreproducible here
<cjwatson> hangs in the same place every time I run this test.  admittedly different, but my system passed a few tests that the buildds didn't, perhaps due to different kernel, so I don't think the buildd ever tried this particular one
<cjwatson> I mean the test suite is run with 'make -k check || true' anyway so you know in some ways it's slightly academic
<cjwatson> but it would be nice to at least have some idea that the resulting binaries aren't busted
<cjwatson> seems to be hanging while polling on an eventfd
<cjwatson> bigods I hate threads with an unbridled passion
<cjwatson> http://paste.ubuntu.com/901301/ <- thread apply all bt from the hang here
<cjwatson> hmm, 500000-second timeout there
<stgraber> that seems a bit high
<cjwatson> it ought to not matter
<cjwatson> I can't reproduce the buildd hang here, but maybe if I attack the one I've got ...
<cjwatson> can you reproduce it?
<cjwatson> it happened on two independent buildds, I'm not inclined to believe it's accidental
<cjwatson> http://git.gnome.org/browse/gcr/commit/gcr/tests/test-gnupg-collection.c?id=f3b9d46c75675e9b4b451164dd32ed9b1af0dfb1
<cjwatson> "Remove threading from testing framework, as gcr isn't threadsafe in all parts."
<cjwatson> ... thanks
<cjwatson> http://git.gnome.org/browse/gcr/commit?id=f3b9d46c75675e9b4b451164dd32ed9b1af0dfb1 (possibly more helpful, broader diff)
<stgraber> build is still running here (was busy with something else for a bit)
<cjwatson> that doesn't help though
<stgraber> ok, tests running here now
<stgraber> let's say where it hangs
<stgraber> *see
<skaet> stgraber, cjwatson - am going to go ahead with the image rebuilds at this point, unless you raise the flag.   compiz is built and published.
 * cjwatson tries upstream gcr
<stgraber> hangs at /gcr/gnupg-collection/load: here
<cjwatson> here too
<infinity> skaet: I'm a bit too lazy to read the results of the discussion in scrollback, but we don't build any armel images except core.
<skaet> infinity,  yes
<skaet> pad had us doing it for kubuntu pre-installed. fixed.
<infinity> skaet: It did?  It shouldn't have.
<cjwatson> './autogen.sh && make && make check' in gnome:gcr passes
<slangasek> cjwatson, stgraber: I notice that all of the hangy thread code is pulled from gnome-keyring git as a distro patch... debian/patches/00git_glib_2.31_deprecations.patch
<skaet> infinity,  we'll only image on the manifest for kubuntu preinstalled right now is armhf+omap4 so that's what its now set to.
<cjwatson> (it's been split out of gnome-keyring in the 3.3 series)
<skaet> s/we'll/well/
<slangasek> ah, but we're behind upstream and upstream has split the source?  useful
<cjwatson> slangasek: that might well be useful anyway, thanks
<cjwatson> oldest tag in gnome:gcr (3.3.1) fails but not in a hangy way
<cjwatson> oh, and not every time even
<infinity> skaet: The pad shouldn't have been defining any arches for kubuntu at all.
<infinity> skaet: And neither should the crontab (noting your note there)
<infinity> skaet: arches are already limited in etc/default-arches.  The only reason they're specified for ubuntu is to split the build into two jobs.
<cjwatson> some kind of similar errors from gnome-keyring bde64e94f83a6da4eaff6503744e200c9f1f0081 (which I think corresponds to the patch slangasek mentioned) built against gcr 3.3.1
<cjwatson> but no hang
<stgraber> cjwatson: apparently disabling only /gcr/gnupg-collection/load was enough here, all the others ran properly (no hang, not sure if some failed though)
<cjwatson> stgraber: ok, but that's not the test that hung on the buildd
<cjwatson> so I was hoping for something more fundamental ...
<cjwatson> what was the cause of setcap in debian/gnome-keyring.ubiquity failing, anyway?
<stgraber> not too sure about that one actually ... on all installs where it failed the file actually had the right attributes set and calling the hook manually would succeed
<cjwatson> 3.2.2 with bde64e94f83a6da4eaff6503744e200c9f1f0081 applied (and an extra build tweak) hangs; bde64e94f83a6da4eaff6503744e200c9f1f0081 itself succeeds
 * cjwatson starts bisecting
<skaet> infinity,  kubuntu preinstalled was releasing armhf+omap and armhf+omap4.  Manifest only has armhf+omap4 on it.
<infinity> skaet: The manifest doesn't have every arch built, true.
<infinity> *cough*powerpc*cough*
<infinity> skaet: If Kubuntu only wants omap4 built, however, that should be changed in default-arches, not hacked all over everywhere else.
<skaet> infinity,  agreed.  :)
<skaet> alternate images emerging on the iso tracker now.
<skaet> hggdh, pgraner,  ubuntu-alternate on the tracker now,  ubuntu-server, ubuntu-desktop should be emerging shortly.
<Daviey> neat
#ubuntu-release 2012-03-27
<hggdh> skaet: ack
 * skaet --> dinner
<slangasek> all for -proposed, I guess?
<infinity> slangasek: They were all for -release, I rejected them all and asked Robert to reupload to -proposed.
<slangasek> ah, ok
<infinity> I think he missed the "we're staging GNOME 3.4.0 in proposed" memo.
<slangasek> ah, well, I missed it too
<slangasek> :)
<infinity> Yeah, seb was doing gnome 3.4 in proposed so that it would all build and stage and they could just release it on Friday after Beta with no fuss.
<infinity> Which seems vaguely sensible.
 * slangasek nods
<cjwatson> stgraber: I give up for now; I'm not getting anywhere with this bisect / trawl through gnome-keyring/gcr history and I need sleep.  Sorry.
<stgraber> cjwatson: thanks for trying for so long, good night!
<skaet> heya,  who let all the packages through?
 * skaet goes and reads the backscroll
<infinity> skaet: Those are all in proposed.
<skaet> yup,  just saw that,  adrenaline levels subsiding.
<infinity> skaet: :)
<infinity> stgraber: queuebot could perhaps announce "$dist-$pocket", both on accept and removal.
<infinity> stgraber: Might reduce heart attacks.
<infinity> stgraber: Err, on in and out, I guess, don't want to overload "accept" in this context.
<infinity> stgraber: It would also be awesome if there was a way to identify how something was removed from the queue (accept or reject), but I'm guessing you don't have that info to work with, just that it's gone?
<stgraber> infinity: yeah, I guess I could look in the Done queue if the package is there and announce it as approved then
<stgraber> problem is, that "queue" (or status) is kind of long to list ;) so I'd have to check if there's an easier way in the API
<infinity> Oh, yeah, scanning done or rejected is a losing battle.  Don't bother.
<infinity> I forgot that queubot's just polling.
<infinity> But if you could change (component) to (dist-pocket/component), that would be awesome.
<stgraber> when we have the audit changes implemented it should be easy to just pull that record and show who accepted/rejected it
<infinity> And duplicate that info on Removed.
<infinity> (I assume you still have the info when you remove, as you're just pulling a member from a list or something?)
<infinity> stgraber: Or put it on a role account on one of your machines, so I can add cute little features when I'm bored. :P
<stgraber> let's try that
<stgraber> looks like it's working
<stgraber> infinity: happy? :)
<stgraber> infinity: you can always send merge proposals for lp:~stgraber/+junk/queuebot
<infinity> stgraber: You're missing dist.  Though, I guess that only matters if you have it scan non-release dists.
<infinity> stgraber: (Which would actually be really handy, as I often don't notice when something's uploaded to, say, lucid-proposed)
<infinity> s/non-release/non-devel/
<infinity> stgraber: Would be cool if it ran 24/7, and was useful for old dists too.  I'm being picky, aren't I? ;)
<stgraber> should be doable but would make it a bit slower as unfortunately we can't call getPackageUploads() on a distribution, it needs to be on a distro_series
<stgraber> so the bot would need to call if for every supported release
<infinity> Yeah, so you iterate through all supported series.
<infinity> Doesn't need to poll as often for non-devel.
<infinity> Shouldn't be too much slower, since you could call them all in parallel.
<infinity> I've heard pretty neat things about threaded programming.  It's all the rage, I hear.
<infinity> Ooo, but pocket on the removal message is already a huge win.
<infinity> skaet: Less heart-attack inducing? ---^
<stgraber> I'm sure we can get cjwatson to implement the threading ;)
<infinity> I'm not a python wizard, but it must have some really dead easy callback conventions, right?
<infinity> Seems like the sort of thing a modern high level language should have.
<skaet> infiniity,  stgraber - thanks.  :)
<infinity> queuebot: What, not going to spam us with the current queue status on connect this time?
<stgraber> nope, it usually doesn't do it, I'm just forcing it to do it when I want to make sure it works
<infinity> Ahh.
<skaet> :)
<stgraber> otherwise it doesn't do anything then the first entry it sees I get a backtrace and it dies ;)
<infinity> Poor bot.
<stgraber> I still need to make it's irc implementation a bit more standard compliant so it doesn't get killed for excess flood
<stgraber> though ignoring all the langpacks definitely helped there :)
<infinity> Yeah, there shouldn't be much call for rate-limiting most of the time.
<infinity> langpacks are a bit special.
<stgraber> infinity: implemented (watching all series)
<stgraber> just need a restart to make sure it works (and flood the channel some more ;))
<infinity> stgraber: Does it already do both NEW and UNAPPROVED?
<infinity> stgraber: I've never paid attention.
<stgraber> infinity: it can, but it's currently restricted to Unapproved
<infinity> stgraber: I'm guessing from the interleaved output there that you went multithreaded?
<infinity> stgraber: Looks good.
<stgraber> infinity: nope, single thread but once the set is built it's sorted by package name, that's why series are mied
<stgraber> *mixed
<infinity> Ahh.
<stgraber> I guess it'd make sense to change the order to first sort by series, then pocket, then package name, but it's only really useful when I get the bot to print everything at once
<infinity> Yeah, printing everything at once shouldn't be a common use-case. :P
<infinity> Unless you want to implement /msg ...
<infinity> At which point, I think we're missing the point of the bot. ;)
<stgraber> right :)
<stgraber> I've also started implementing the ISO tracker api in the bot so it can show in #ubuntu-release and #ubuntu-testing when a new build is published during milestone testing
<stgraber> as the builds are automatically published from nusakan that should be useful for both the release team and testers
<stgraber> but I need to cleanup the code a bit first to properly handle that... ideally keeping the code somewhat readable
<stgraber> infinity: I have a version of the bot now monitoring both Unapproved and New for all supported releases
<stgraber> infinity: http://paste.ubuntu.com/901523/
<stgraber> I think I'll need to add some logic to the bot to figure out if it's source or binary New and change what it shows
<infinity> stgraber: You can probably 's/ package//' from that to make the lines a bit shorter, but otherwise awesome.
<stgraber> as showing /none and non-existent => <version> is a bit pointless :)
<infinity> stgraber: And yeah, could do "New (source)" or "New (amd64)", etc.
<infinity> stgraber: And the bits you mentioned too.
<stgraber> infinity: http://paste.ubuntu.com/901540/
<infinity> stgraber: The anal retentive alignment freak in me wants to point out that if you remove the brackets from binary and source, it'll align perfectly with Unapproved. :P
<stgraber> oh, weird I didn't notice... /me fixes ;)
<infinity> stgraber: I guess it's also collapsing multiple binNEW entries into one?
<infinity> stgraber: (There are 3 for slphone right now, but only one on your list)
<stgraber> yeah, launchpad apparently does that for me
<stgraber> infinity: http://paste.ubuntu.com/901546/ <-- there, properly aligned now ;)
<infinity> Pretty!
<infinity> Shame about the collapsing behaviour.  Means we can't watch all 5 arches trickle in, we'll only know about the first.
<infinity> But it's still a good enough cue to go watch the queue.
<infinity> Which is mostly what I want it for.  I always forget to poll NEW, and end up surprised when there's 5-day-old binNEW stuff in there.
<stgraber> hmm, actually I might be able to separate the architectures looking at .display_arches
<micahg> ubuntu studio needs their default-settings-package above in and respun with it (can wait if other fixes are needed to be respun with it)
<micahg> s/default-settings-package/-default-settings package/
<infinity> micahg: Will review shortly.
<micahg> infinity: thanks, do you need a pad update?
<stgraber> oh, sweet, display_arches actually tells you if it's a source upload or a sync too
<infinity> stgraber: Interesting.
<infinity> micahg: If studio's already been respun today, I'll just do it again.
<micahg> infinity: thanks
<skaet> infinity,  ubuntustudio's just emerging now,  so a respin will be necessary
<infinity> Hahaha, indeed, it's actually building as we speak.
<infinity> TIMING.
<infinity> I'll kick off another build before I go to bed. ;)
 * skaet nods...
 * skaet likes stgrabers changes in the paste.bin too.  :)
<micahg> skaet: I won't be able to get to the onboard fix for xubuntu until the morning, the fix isn't needed for ubuntu or edubuntu, but they'd pick it up if they were respun afterwards
<skaet> micahg, please update the pad then, and we'll pick it up/respin as necessary.
<micahg> skaet: it wasn't on the pad to begin with
<skaet> micahg,  s/update/add it to/ :)
<micahg> I can add it though :)
<stgraber> skaet, infinity: http://paste.ubuntu.com/901559/
<stgraber> I simply added "(sync)" at the end if it's a sync, not sure if we want it more visible than that (it doesn't matter so much I guess)
<infinity> stgraber: My alignment!
<stgraber> or I could make it "Unapproved sync"
<stgraber> infinity: you can't have both the architecture and your alignment ;)
<infinity> stgraber: s,binary (amd64): wesnoth-1.10,binary: wesnoth-1.10/amd64,'
<skaet> stgraber, looking lovely to me.   :)   lots of lovely info without having to go look up.
<infinity> stgraber: Keeps source packages aligned with each other. ;)
<stgraber> infinity: true but then the format is no longer consistent :)
<infinity> stgraber: Well, there only one case that shows arch, it's never consistent.
<infinity> there's...
<infinity> stgraber: The perhaps more LP-consistent place to show it would be in the dist/comp brackets (maverick-backports/universe/amd64)
<infinity> But it's less immediately obvious there than it is tacking it right after the source package.
 * infinity shrugs.
<infinity> I'm picky about quickly parsable data. ;)
<infinity> (And slightly dyslexic)
<micahg> infinity: what do you think of me seeding mousetweaks in xubuntu for beta 2 vs this onboard bug fix
<stgraber> current format is basically: <queue> [<entry type>]: <pkg_name> (pkg_pocket[/<current_component>]) [current_version => pkg_version] (pkg_pkgsets) [(sync)]
<infinity> micahg: I'm completely not caught up on what's up with onboard.
<micahg> infinity: without mousetweaks it seems to barf without unicode encoding
<stgraber> infinity: but yeah, moving the architecture after the binary package name should be fine :)
<micahg> trunk was fixed to use unicode encoding, there's a point release in progress that will include that fix amongst others
<infinity> stgraber: Yeah, I'd just make that <pkg_name>[<arch>], and pull arch out of entry type, but again, I'm dyslexic, every bit of alignment helps me track.
<infinity> micahg: Not something you can easily backport/cherry-pick?
<infinity> micahg: I don't like the idea of seeding packages as a workaround on our last Beta before release.  It's not a particularly good way to represent the final product.
<micahg> infinity: there is a fix and it looks innocuous enough, but as there seems to be a less risky fix...
<infinity> micahg: (And means anyone installing with Beta keeps mousetweaks FOR EVA)
 * micahg wonders if apt-get autoremove would DTRT once it's unseeded
<infinity> No.
<infinity> Not unless we changed something recently.
<micahg> ok, I"ll try try to fix the patch in the morning, it doesn't apply cleanly ATM
<infinity> Either way, I'd still prefer to look at the cherry-pick, since that represents what the actual fix will be before final, right?
<stgraber> infinity: http://paste.ubuntu.com/901570/
<micahg> infinity: http://bazaar.launchpad.net/~onboard/onboard/0.91/revision/764
<infinity> stgraber: <3
<infinity> stgraber: You just couldn't live with source/arch, could you? ;)
<stgraber> infinity: no, wasn't consistent with the other messages ;)
<infinity> micahg: Looks remarkably straightforward.
<micahg> infinity: right :)
<infinity> There really needs to be a way to just tell python "all strings are unicode unless I cast them differently".
<infinity> Having to cast it for every string is ridiculous.
<micahg> infinity: you could try to PEPify that
<infinity> Ew, no.
<infinity> I'll just use C, like a sane person.
<infinity> And stop worrying about high level laguages only holding my hand sometimes.
<infinity> languages, too.
<infinity> GIVE ME POINTER ARITHMETIC OR GIVE ME DEATH.
<infinity> stgraber: Actually, to be consistent with other messages, I'd say the arch should be in square brackets, like the version is. ;)
<infinity> stgraber: (I may just be messing with you now)
<infinity> stgraber: It looks like a drastic improvement.
<skaet> I'm just looking forward to it rolling out...  and seeng the first message sow up.  :)
<stgraber> infinity: square brackets actually sounds like a good idea ;)
<infinity> Well here, have some messages.
<stgraber> infinity: would match the syntax used for Depends:
<infinity> stgraber: That too, yeah.
<skaet> *\o/*
<stgraber> square brackets upgrade ^
 * infinity hugs queuebot.
<stgraber> btw, why do we have new source packages in oneiric-proposed and oneiric-release?
<jbicha> the gnome:NextVersion thing didn't work right with gnome-shell, it's trying to depend on libmutter0 (>= 3.3), libmutter0 (<< 3.4)
<infinity> stgraber: NEW in proposed isn't unheard of.
<infinity> stgraber: NEW is release, let me look.
<infinity> stgraber: partner.
<stgraber> ah, that'd explain it indeed
<infinity> stgraber: The bot not showing component for source new would be why we didn't notice. :P
<skaet> infinity,  I'm reading the backscroll right in that when ubuntustudio-defaults-settings finishes building, a respin of ubuntustudio is being looked for?
<stgraber> I ignored the component for new source uploads as it'll default to universe for everyone, but apparently we're using it for patner, so I probably should show it anyway then
<infinity> stgraber: Actually, it shouldn't default to universe for EVERYTHING.
<infinity> stgraber: non-free maps to multiverse, and multiverse and restricted are left alone, if I recall.
<infinity> stgraber: Just that things that don't declare a component end up in universe.
<infinity> skaet: It's already done building, but when it's published in ~20 minutes, yeah.
<skaet> infinity, ok,  wubi's just about done, so that should line up nicely.   Sticking it on the pad.
<infinity> skaet: Pad away, if you want to drive, I'll wash my hands of it, then. ;)
<infinity> I was going to just be a rebel and spin it when you weren't looking. :P
<skaet> infinity,  if you're feeling rebelious,  I can go to bed.  ;)
<infinity> skaet: Works for me.  I'm up for a while.
<skaet> infinity,  coolio.   Will ping you when the wubi's done and you can kick it when it comes out of the publisher.
<infinity> stgraber: No new queuebot with source components?  Did bed happen? ;)
<stgraber> infinity: it's actually tricky to implement ;)
<infinity> stgraber: Oh.  I figured it would be the same as unaproved.  Silly me. ;)
<stgraber> nope, for anything that's been published once, getPublishedSources will give me the data
<stgraber> but for something that never was published I still haven't found a way to get it
<infinity> Ahh.  The queue entry itself has no hint?
 * infinity wonders where the web UI is pulling it from.
<stgraber> no, the queue entry is pretty limited: https://launchpad.net/+apidoc/devel.html#package_upload
<stgraber> I guess I could use archive_link which should work for partner
<infinity> I'm guessing source_package.latest_published_component_name is nothing for NEW sources?
<stgraber> well, for that you'd need a source_package record
<skaet> infinity,  typo on the wubi build,  exec: 111: cron.wub: not found *sigh*
<infinity> skaet: *slow clap*
<infinity> skaet: I can just do that with ubuntustudio. :P
<stgraber> 04:23 -queuebot42:#stgraber-release- New source: swauth (oneiric-proposed/primary) [1.0.2+git20111128-0ubuntu1.1]
<skaet> infinity,  do you want me to kick it off again now, or you want to fit it in with  ubuntu-studio.
<stgraber> 04:23 -queuebot42:#stgraber-release- New source: jonas-full-5.2 (oneiric-release/partner) [5.2.1-0ubuntu1]
<infinity> skaet: It already did the buildlive?
<stgraber> infinity: that's what I have currently, basically showing the name of the archive instead of the component for new sources (so primary or partner)
<skaet> infinity,  yup
<skaet> kapok.buildd starting at Tue Mar 27 03:45:52 UTC 2012
<skaet> cardamom.buildd starting at Tue Mar 27 03:45:52 UTC 2012
<skaet> kapok.buildd finished at Tue Mar 27 04:17:01 UTC 2012 (success)
<skaet> cardamom.buildd finished at Tue Mar 27 04:19:52 UTC 2012 (success)
<infinity> stgraber: That'll have to do for now.
<infinity> skaet: Kay, I'll finish up.
<skaet> infinity,  thanks.
<infinity> skaet: Done.
<skaet> infinity,  on the arm builder side,  mx5/ac100 are just finishing up,  then its kubuntu's turn,  and that's about it.
<infinity> skaet: Check.  I'm got IS working on some parallelisation love for me.
<infinity> skaet: Probably won't have it before we're done with B2, but we should right after.
<infinity> s/I'm/I've/
<infinity> Though, I guess it is only Monday.
<infinity> Maybe I can shake up the world before your last Beta spin. ;)
<stgraber> skaet: I'll spend a few minutes tomorrow to have the bot also poll the ISO tracker for new milestone (non-daily) builds and announce them here + #ubuntu-testing
<skaet> oooh,  stgraber that would be very nice indeed.   :)
<infinity> stgraber: New builds in general might be nice, though with milestone versus daily tagging?
<infinity> Or maybe that would seem too spammy.
<infinity> We do build a lot of image.
<infinity> images, too.
<skaet> infinity,  fingers crossed for that parallelization.   :)
<stgraber> infinity: yeah, turning it on for dailies too will be easy, but I suspect we don't want that kind of spam between milestones :)
<infinity> skaet: Oh, it's GOING to happen.  Just not sure it'll be before your last spin on Wednesday/Thursday.
<skaet> just hear from pgraner that the workaround seems to be effective,   so on that note of good news,  zzz time.
<stgraber> infinity: having the bot read image build failures would be kind of nice though as not everyone receives the e-mails
<infinity> Well, we can put the bot in the mail loop.
<infinity> So it doesn't need to poll.
<pgraner> all seems ok with light testing, QA will did deep in a few hours when europe comes online
<infinity> pgraner: Sounds good.
<pgraner> infinity, hasta get some rest
<infinity> What is this "rest" you speak of? ;)
 * skaet --> zzz  (can take a hint)
<infinity> micahg: studio respinning now.
<infinity> micahg: And done.
<pitti> Good morning
<pitti> kirkland: that script would also fit into update-manager, for example
<knome> morning pitti
<pitti> skaet: still there? I'm confused by the pad
<infinity> pitti: What's the confusion?  *goes to look*
<pitti> rebuild reasons 1, 6, and 13 do not exist in the list any more
<pitti> but some images are still marked for rebuild
<pitti> I look into the gnome-keyring FTBFS now, to unblock stgraber's fix
<infinity> Well, everything was literally just respun.
<infinity> So, I imagine she just didn't clear ac100/mx5 because they were in progress.
<pitti> ah, ok
<pitti> stgraber: ah, that timeout
<pitti> stgraber: unfortunately we hit that sometimes, due to builders running very old kernels
<infinity> pitti: Oh, I also just did studio.  Removed that trigger from the pad.
<infinity> pitti: But yeah, I think the stale ARM ones on the pad are because she went to bed while the build was still running. ;)
<infinity> pitti: If they all succeeded, that can be removed.
<pitti> infinity: ack, thanks
<infinity> Oh, crap, but the studio and wubi builds I did weren't run with the autopost environment.
 * infinity sighs.
<pitti> infinity: is that even necessary?
<infinity> I don't know.  The pad implies such.
<pitti> I forgot it as well the other day, and they were posted just fine
<infinity> Maybe it lies.
<pitti> if you confirm that as well, we can remove that from teh pad
 * infinity looks.
<infinity> yeah, the builds I just did autoposted.
<infinity> That info is stale.
<infinity> Delete away.
 * infinity wanders off to do $something_else.
<pitti> infinity: updated
<pitti> gah, gnome-keyring hanging again; we need to find a buildd with a non-hardy kernel, it seems
<slangasek> I wasn't aware that any of the distro buildds had hardy kernels?
<infinity> Most of them do.
<slangasek> hmm
<slangasek> why is that?  I thought the distro builds were at lucid, and it was only the virtualized builders that were on hardy
<pitti> I asked for cancelling them
<pitti> but might get no response
<pitti> it might be easier to do a no-change upload and assign thhem to zirconium and allspice manually
<infinity> I don't know if any of the x86 ones are !hardy.
<infinity> roseapple's one of the newest machines, and it's hardy.
 * slangasek scratches his head
<pitti> oh, I thought they were; darn
<pitti> so we just need to keep retrying until they succeed, or disable the tests on amd64/i386
<pitti> so, no response on launchpad-ops
<pitti> I guess we are blocking new rebuilds on that, right? so want me to do a no-change upload?
<pitti> hang on, got response
 * ScottK just did a qwtplot3d upload.  It's unseeded universe.  I'd appreciate it if someone would wave it through when it appears.
<ScottK> Thanks.
 * ScottK tries to go to sleep (again).
<pitti> *nod*, good night ScottK
<ScottK> There it is.
<ScottK> Thanks pitti.
<infinity> pitti: zirconium and allspice are still hardy.  Are you just hoping that a slightly newer SRU rev will do it?
<pitti> it's mostly just luck
<pitti> it doesn't usually fail twice in a row
<pitti> but now it does because we are waiting for it, and looking at it
<pitti> both built now, *phew*
<infinity> Special.
<pitti> so I guess I'll do some respins once that's published
<slangasek> so what changed to make g-k ftbfs on hardy kernels?  was it doing that before?
<pitti> slangasek: it's a sheer matter of luck
<slangasek> so this was a known problem before?
<pitti> yes
<pitti> it affects quite a few glib based packages, when they run tests
<slangasek> alrighty
<infinity> But it's definitely not reproducible on recent kernels?
<pitti> nope
<infinity> Yeah.
<pitti> we never experienced it locally
<infinity> Chalk up another argument for upgrading buildds.
<pitti> and we never got it on arm builds
<infinity> I'd rather fix the few packages that break for older releases than the other way around.
<infinity> (And lp-buildd is already employing the uname-2.6 hack to minimise the worst damage that 3.0 kernels will bring to old releases)
<infinity> Well, it would be employing it if it was running on precise. :P
<infinity> But the code is there and tested and rolled out.
<infinity> Hrm, I wonder if I should double the header in build logs to show both "real kernel version" and "kernel version reported to sbuild".
<pitti> gnome-keyring is published; rebuild galore, I figure
<pitti> image builds running, pad updated, time for breakfast
<knome> bon appetit
<cjwatson> stgraber: nice work on the bot!
<cjwatson> infinity: python all strings unicode> that's what python 3's for ...
<pitti> good morning cjwatson
<cjwatson> pitti: um.  g-k hung reproducibly for me in a local sbuild, albeit in a different test, and also for stgraber.  have you tried it recently?
<pitti> not 50 builds in a row or something such, just during normal package updates
<cjwatson> I mean, aside from the builds that just succeeded. :)
<cjwatson> I did wonder why we were a cycle back on g-k (and don't have the new split gcr), but I guess it's too late for that now
<pitti> we did investigate a hang in glib's test suite which also used GIOChannels, and found that it was due to the hardy kernel; I never got the keyring one locally, so so far I could just assume it was a similar problem
<pitti> cjwatson: LTS conservativism mostly
 * cjwatson nods
<pitti> cjwatson: g-keyring 3.4 got quite a dramatic rewrite in 3.4
<pitti> and while it's mostly working, we did get some regressions; these should be fixed now, but still..
<pitti> cjwatson: so, pad is up to date, respins are running for keyring
<pitti> need to run out for 30 mins
 * cjwatson hasn't really started yet, just looked in from phone
<cjwatson> but baby is asleep \o/
<cjwatson> stgraber: ^- "New: removed syslinux-legacy" should've had the arch names maybe?
<Laney> haskell-yesod is the last of that stack
<Laney> should allow the rest of those packages to be zapped
<cjwatson> yeah, I was just looking
<Laney> i'll do the partial removal bug later
<cjwatson> stgraber: are you relying on http://people.canonical.com/~ubuntu-archive/queue/ in any way?  I guess not since it doesn't have precise.  I was wondering if we should decommission that
<cjwatson> not as if it's up to date anyway
<cjwatson> (it was always a pre-API hack anyway ...)
<cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - wanna reseed a bunch of stuff before this falls out?
<Daviey> cjwatson: yep!
<bdrung> Laney: i commented bug #965659
<ubot2> Launchpad bug 965659 in shunit2 "FFe: Sync shunit2 2.1.6-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/965659
<Laney> bdrung: thanks, it was a gentle prod that the FFe was a bit bare :-)
 * pitti accepts the GNOME 3.4 -proposed uploads
<seb128> pitti, \o/
<pitti> oh, it now shows SRUs, too
<cjwatson> yep, stgraber had a hacking spree
<Laney> what's the analog of http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt for ports?
<cjwatson> s/testing/testing-ports/
<Laney> ta
<bdrung> can i sync eclipse 3.7.2-1 from Debian? according to upstream 3.7.2 is a maintenance release of the 3.7 branch.
<Laney> shouldn't armel and armhf be switched there?
<cjwatson> probably :)
<cjwatson> I thought pitti said something about doing that
<pitti> hm, I did switch it for _probs.html
<pitti> apparently I missed a spot for outdate
<ev> would someone on the release team please weigh in on whether they think bug 964508 is worth having in precise?
<ubot2> Launchpad bug 964508 in whoopsie-daisy "whoopsie uploads crash reports, including core dumps, when on a 3G connection" [Medium,Confirmed] https://launchpad.net/bugs/964508
<pitti> ah, all my rebuilds are done, updating pad
<pitti> ev: responded in the bug
<ev> pitti: any thoughts on a better way of handling that at_console bit, or is touch /var/run/console/whoopsie the best way forward?
<ev> and cheers!
<pitti> ev: oh, I haven't looked at the patch, just at the description
<pitti> bbl, lunch
<pitti> ev: eww -- can't we just fix NM's dbus policy to also allow root?
<ev> pitti: it's not running as root
<ev> it's running as the unprivileged whoopsie user
<ev> running as root will work just fine, but keeping root around just so we can use nm over dbus is a bit scary.
<ev> ah, just saw your comments in the bug
<stgraber> good morning
<stgraber> cjwatson: the new bot is using the LP API directly
<stgraber> indeed showing the architecture on removal of a binary package would make sense, I'll fix that one quickly
<cjwatson> OK, I'll nuke the old queue view then
<cjwatson> old queue view is gone
<skaet> good morning pitti, cjwatson
<skaet> thanks for the updates to the TechnicalOverview last night scott-work!   looks good.  :)
<stgraber> cjwatson: ^ happy with the new removal message?
<cjwatson> stgraber: great, thanks
<Laney> can it show seeds too, or would that be too much?
<skaet> cjwatson,  any new fixes beyond the server ones looming on the horizon?
<cjwatson> it'd have to be germinate output not seeds
<Laney> yeah, transitively
<Laney> and supported
<cjwatson> skaet: I'm not aware of anything just at the moment
<Laney> tumbleweed generates that data i think, if it's not in machine-readable form elsewhere
<skaet> Laney,  did you see the version in the backscroll (ref's to core, edubuntu, etc.)?
<Laney> skaet: yes, I see packagesets in there
<skaet> Laney,  okie.  :)
<Laney> http://qa.ubuntuwire.org/ubuntu-seeded-packages/seeded.json.gz
<jibel> ltsp is broken. Client session doesn't start
 * stgraber is looking into it
<stgraber> install is running now, should know more in 10-15min
<skaet> pitti,  release note https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/963470?
<ubot2> Launchpad bug 963470 in compiz "[regression] Unity 5.8+Compiz 0.9.7.2: Pressing Super+Tab or Super+W works, but unity does not respond to when Super is released." [High,Fix committed]
<skaet> or should we try for a cherry pick?
<stgraber> jibel: FWIW, I'm also doing a quick ltsp-live check to see if it's limited to alternate or also applies to Edubuntu
<tumbleweed> skaet, Laney: lp:~stefanor/+junk/ubuntu-seeded-packages
<Laney> ty
<tumbleweed> reads germinate output for supported seed, and manifests+lists for ISO contents
<Laney> how often is it regenerated?
<tumbleweed> hourly
<cjwatson> bug 963471 makes me suspicious
<ubot2> Launchpad bug 963471 in debian-installer "Not all OS shown in grub-install screen at end of installation" [Undecided,Incomplete] https://launchpad.net/bugs/963471
<cjwatson> something dodgy going on with FUSE there I think
<cjwatson> oh, bah, no, it's much more prosaic than that, os-prober is trying to use which
<cjwatson> boo
<skaet> ogasawara, apw - is there an ETA on a cherry pick fix to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961482?
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed]
<ogasawara> skaet: there's one in the works right now, just needs testing
<ogasawara> skaet: if it were possible, I would like to get it in for Beta-2, but the window for uploading is slowly closing in on us
<skaet> ogasawara, yes, indeed.   how widespread is it?
<cjwatson> oh, but I'm going to need a grub2 upload as part of 963471, so that'll have to be post-beta
<ogra_> geez, the slideshow is pretty slow on arm
<skaet> cjwatson,  ack.
 * ogra_ wonders if he will actually see the end before the install is done
<ogra_> hmm, no, only three slides
<skaet> ogra_ know if there's any progress on: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/963512
<ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed]
<ogra_> skaet, oh, i didnt know about that one
 * ogra_ checks
 * ogra_ goes to ask paolo ... 
<ogra_> it seems ot not affect everyone
<ogra_> skaet, paolo says he has a new kernel ready by tonight
 * ogra_ sighs that people dont subscribe ubuntu-arm to bugs anymore and subscribes to the linux-ti-omap4 package 
<skaet> thanks ogra_.  tonight in Europe?  ie.  am wondering if we can get the full set of respins with the kernels that fix both of these problems.
<ogra_> well, we only need to respin omap4
<stgraber> jibel: unable to reproduce on Edubuntu with ltsp-live, alternate install is finishing now
<ogra_> thats only two images ... we would have to skip netboot then though
<ogra_> but i think we can live with it
<ogra_> infinity, ^^^ any opinion ?
<skaet> ogra_, kubuntu is also an omap4 one.
<ogra_> does anyone test that ?
<skaet> Riddell, ^ ?
<ogra_> skaet, "<ppisati> ogra_: in a couple of hours"
<skaet> ScottK, ^ ?
<ogra_> that should suffice to get images ready tomorrow
<phillw> I have amd 64 of ubuntu & lubuntu, I can zsync up one for kununtu if you need a tester.
<ogra_> phillw, arm
<ogra_> do you have arm HW ?
<phillw> sorry, no.
<Riddell> ogra_: GrueMaster has previous tested kubuntu arm images but I believe won't be doing so any more
<ogra_> right
<skaet> thanks phillw,  there will be an amd64 kernel showing up a bit later too (me crossing fingers),  so testing of that will be welcome.  :)
<ogra_> i belive he wont be doing any testing anymore
<Riddell> I can test but I am quite certain it'll fail for me like every other precise image
<ogra_> Riddell, see the bug above :)
<ogra_> with that fix you should also see output on HDMI
<Riddell> ogra_: and that's the comment above from ppisati about in a couple of hours?
<ogra_> Riddell, right, he will upload in a few hours, kernel should eb ready by tomorrow so we can have new images with the output fixed
<Riddell> tomorrow will be a another sunny day if that works :)
<ogra_> :)
<pitti> skaet: I agree, it's far from critical
<pitti> skaet: will add it, thanks
<pitti> skaet: done
<skaet> thanks pitti.
<stgraber> skaet: tracked down bug 966267 to a race between plymouth and X causing X to explode if the user presses <enter>
<ubot2> Launchpad bug 966267 in ltsp "client session doesn't start" [Undecided,New] https://launchpad.net/bugs/966267
<stgraber> skaet: it's most likely LTSP's fault for not killing plymouth properly, I'm looking at it now
<stgraber> skaet: the bug affects Ubuntu alternate and Edubuntu on both amd64 and i386
<ogra> hmpf ... g-s-d just died in my fresh install
<stgraber> skaet: I'm hoping to have a tested fix within the next hour
<micahg> skaet: I have the onboard fix, but it's untested I was going to upload it and ask xubuntu people to test and let someone know in here if it works, sound ok?
<skaet> stgraber,  sounds good.    will keep those in mind for the respins.   Will probably wait to pick up kernel (if possible) before triggering.   If you want just one though to verify out the fix, can do.
<skaet> micahg, sounds good.
<ogasawara> skaet: we have a fix available (just unconfirmed via testing), but it's been sent to upstream stable already.  I'm inclined to upload as I think 961482 will affect quite a few systems and seeing as they're already rendered unbootable, it can't get much worse.
<stgraber> skaet: this fix is in LTSP itself so it's easy to test without reinstalling (for once ...)
<skaet> ogasawara, agreed.
<ogasawara> skaet: ack, I'll prep an upload with just that fix.
<skaet> ogasawara, is there an ETA on ppsati's fix for omap4?
<ogasawara> skaet: he was mentioning earlier that he said he'd have a fix by EOD
<skaet> ogasawara, Europe EOD or North America ?  ;)
<ogasawara> skaet: that he didn't clarify, but I'm assuming Europe
<ScottK> http://dissociatedpress.net/2012/03/27/ubuntu-were-not-linux/
<skaet> ogasawara, that would be my hope as well. :)
<ogasawara> skaet: ppisati has just sent the pull request to the list for omap4, tgardner should upload shortly
<skaet> ScottK,  thanks for flagging.   Will put an editorial eye on the wording of this one to avoid feeding that flamefest.
<skaet> s/this one/beta 2 TechnicalOverview/
<stgraber> skaet: ltsp uploaded, test verified here and by jibel
<skaet> stgraber,  :)
<skaet> ogasawara, goodness.
<ogasawara> skaet: omap4 kernel uploaded, could we get it approved in the queue?
<ppisati> ogasawara: you were faster than me :)
<skaet> ogasawara, ppisati - just waiting for the diff to generate.  :)  looking at it now.
<apw> the diff will likely scare you to death :)
<apw> ppisati, that upload is basically a revert to the known good kernel right ?
<ppisati> right
<skaet> cjwatson,  could you look at the update-manager one in the unapproved queue.   Seems its picked up lots of changes based on the diff,  ok to pull into the respins?
<skaet> Daviey,  couold you look at the OpenMPI one - do you want it?
<cjwatson> skaet: on the phone, sorry, what are the impending respins?
<cjwatson> well s/phone/G+/
<skaet> cjwatson,  fair enough.  we'll be waiting for kernel rebuilds so there's time.   its the update-manager am not sure if we should pick up or not.  in unapproved-queue.   (powerpc changes, and some others...)
<pitti> skaet: I can also look at u-m
<cjwatson> off G+ now
<pitti> skaet: but I wasn't aware we'll respin again?
<ogra_> omapr4
<cjwatson> if we take update-manager we should take python-apt too; not that it's required, but that way it will actually fix a bug
<ogra_> *omap4
<cjwatson> most of the changes in u-m are a routine mirrors update, and harmless
<cjwatson> wait that's python-apt I think, let me check
<infinity> skaet: The update-manager PPC changes are just because it includes an embedded copy of base-installer.
<cjwatson> right, yeah, that's normal
<cjwatson> demoted.cfg is syncing with state of archive
<skaet> okie
<cjwatson> mirrors.cfg is syncing with data from real world
<skaet> pitti, am assuming that was you accepting things into -proposed?   basically ok to accept anything there now,  since only changes we'll be applying to the release will be uploaded to -release?
<infinity> skaet: That was me.
<cjwatson> the https bit comes with tests
<pitti> skaet: I was going to, but someone beat me to it
<ogasawara> skaet: ^^ kernel uploaded, contains only the fix for 961482
<cjwatson> yeah, u-m looks fine to me if we're respinning for a kernel anyway
<skaet> thanks ogasawara
<cjwatson> python-apt looks fine too
<cjwatson> but we're not respinning all images, correct?
<skaet> ogasawara those graphics drivers (nvidia, cedarview) you as well?
<ogasawara> skaet: nope, not me
<pitti> skaet: it's mostly the gnome 3.4.0 stuff, of which 90% of the chagnes are updated translations, and the rest stuff that made it through the pretty harsh  hard freeze break review
<cjwatson> Daviey: what's "Hiding of tasksel when MaaS is selected"?
<infinity> skaet: cedarview is Jani, I'm sure.  It'll need some careful review. :)
<cjwatson> and are we intending to respin for bug 961482?
<ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix committed] https://launchpad.net/bugs/961482
<infinity> cjwatson: I think that's the plan...
<cjwatson> accepted update-manager and python-apt, then
<infinity> cjwatson: We're respinning for an ARM kernel (including an ABI bump) anyway, so it's a scorched-earth respin, d-i and all.
<cjwatson> whee
<skaet> yup
 * pitti scores them up, so that they go before the -proposed stuff
<skaet> cjwatson, yes,  all of the ubuntu ones at least.   Some of the flavors have already requested respins based on other things, so we'll pick them up.
<ogasawara> skaet: just got confirmation from an affected user that the patch resolves 961482
<skaet> ogasawara, :)  thanks!   thats good news.
<infinity> pitti: Shouldn't release have a higher score than proposed by default anyway?
<pitti> not usually
<pitti> well, devel should be >> devel-proposed
<pitti> but stable-proposed >> devel, IMHO
<infinity> Oh, I guess the scoring was based on the assumption that pockets are a post-release thing.
<infinity> So maybe never took into account the idea that -release could still be open.
<stgraber> pitti: btw, how did you get gnome-keyring to build? just hit retry until it worked or did you have to target specific buildds?
<infinity> Let me aim these kernels at fast buildds.
<pitti> cjwatson, skaet: bumped kernel, p-apt, u-manager
<skaet> thanks pitt
<pitti> stgraber: mostly, yes; with some help from launchpad-ops to kill hanging builds
<skaet> thanks pitti,  even.
<pitti> stgraber: they pretty much all run hardy kernels I was told, so the particular builder shouldn't matter; just a matter of luc
<pitti> k
 * skaet goes to update the pad to double check the builds/not for this afternoon.
<stgraber> pitti: fun :)
<infinity> There, kernels on roseapple and allspice.
<skaet> Riddell,  ScottK,  do you want new images to pick up the new kernel(s) and update-manager fixes for Kubuntu?
<skaet> scott-work,  do you want new images as well (kernel and update-manager fixes)?
<skaet> astraljava, phillw - how about for lubuntu?
 * ScottK hasn't been keeping track (busy with $work)
 * skaet notes Edubuntu and Xubuntu already slated for respin, so they'll get them.
<phillw> skaet: I've updated to lubuntu 20120327.1 But have been holding fire because of kernel issue.
<skaet> phillw,  so am guessing you want the new kernel then... ;)
<phillw> skaet: a working kernel is always nice :D
<skaet> phillw,  ok,  I've marked it to the list.  :)
<infinity> Given everything that was just let through in the name of respinning the world, we probably should just respin the world.  It's only Tuesday.
<phillw> no objections from me (not that i count ;) )
<skaet> infinity,  probably best at this point to keep it all consistent.
<infinity> Ed Zachary.
 * skaet was just wondering about how the testing is going. 
<infinity> Good practice for final release, where consistent is a requirement, not a suggestion. :P
 * skaet goes to google Ed Zachary
 * infinity lets in pittit's "make accountservice mirror ubiquitty's new LC_ handling" bit.
<pitti> infinity: ah, thanks; note that language-selector fixes the same thing, plus another bug
<pitti> I didn't consider either critical for b2, so I didn't poke the channel about those
<infinity> pitti: language-selector is just a dpkg-maintscript conffile handling change?
<infinity> pitti: Or did you collide with Steve, and aren't aware?
<pitti> infinity: oh, that's slangasek's
<pitti> infinity: no, he committed to bzr just fine
<pitti> so I uploaded a new version on top of his'
<infinity> pitti: As in, just now?
<pitti> infinity: so if you just want to let slangasek's in to fix conffile handling for upgraders, that also WFM
<pitti> infinity: no, this morning, like 10 hours ago
<infinity> pitti: Well, not sure where yours went. :P
<infinity> pitti: Unless it was proposed.
<phillw> I saw mention of bug 959224 earlier, is it due for fix this resin?
<ubot2> Launchpad bug 959224 in choose-mirror "Corrupt value for /etc/apt/apt.conf accepted during installation" [Medium,New] https://launchpad.net/bugs/959224
<pitti> infinity: oh, nevermind; I didn't upload it yet, just in bzr *blush*
<infinity> pitti: *slowclap*
<pitti> infinity: as I thought "no rush, can upload after b2 with potentailly more fixes"
<infinity> pitti: Upload it, if it matches the LC_ fixes everywhere else, seems worth it.
<pitti> infinity: anyway, slangasek's chagnes look fine, so if you are looking for good fixes to wrap into b2, that's ceratinly not the worst
<infinity> pitti: We're waiting at least 4 hours or kernels anyway.
<pitti> or need a package in main to refresh task headers or so
<cjwatson> phillw: no
<slangasek> my changes are all low-prio, I'm just picking things off the jenkins report
<phillw> cjwatson: okies, thanks
<infinity> slangasek: Yeahp, but low-prio on your maintscript changes also adds up to low impact, so I pick them up when I'm bored. :P
<cjwatson> phillw: it doesn't have a fix yet, and is in any case not serious enough to merit a respin
<slangasek> cjwatson: which reminds me; half the "obsolete conffiles" still listed on the jenkins reports are actually ones that have been taken over by replacing packages, so should fall out of 'obsolete' the next time the packages are upgraded, I think - is there really anything more we should be doing here? ...
<slangasek> ... https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-server/ARCH=i386,LTS=lts,PROFILE=server,label=upgrade-test/68/artifact/lts-server/obsolete_conffiles.log
<cjwatson> skaet: I suspect infinity means "exactly", rather than the rather unfortunate first google hit for "Ed Zachary" as such :)
<slangasek> (console-setup, file, fuse, grub are all in this category)
<cjwatson> slangasek: sounds like we should fix the autotester to notice that then?
 * pitti off for a bit to prep dinner
<cjwatson> I haven't been looking at obsolete conffiles at all, though
<pitti> cjwatson: it does?
<slangasek> cjwatson: prolly - just wanted confirmation you didn't think there was anything further we should do packaging side
<pitti> they become yellow (i. e. tests failed, but upgrade succeeded)
<skaet> cjwatson,  thanks.   was scratching my head a bit over that one.
<cjwatson> pitti: I mean it should not even list cases where some other package has taken them over
<pitti> ah
<slangasek> pitti: well, things we don't care about at all should IMHO be green, not yellow :)
<slangasek> (for whatever value of "don't care about" applies)
<cjwatson> slangasek: I don't *think* so; in my head that's something Replaces should deal with
<cjwatson> keyboard-configuration doesn't seem to do anything special to take over console-setup.conf
<slangasek> yes
<infinity> I thought Replaces did deal with it...
<slangasek> and none of these conffiles are listed as "obsolete" on my system
<cjwatson> remind me where the autotester moved to?
<slangasek> so I *think* it gets flushed when you do a subsequent upgrade of the replaced package
<cjwatson> sounds plausible, yes
<slangasek> lp:auto-upgrade-testing
<astraljava> skaet: I can't speak for lubuntu, but I'll ask around in the #xubuntu-devel. :)
<cjwatson> ta
<skaet> astraljava, thanks.  (and oops... sorry)
<slangasek> cjwatson: confirmed; apt-get install console-setup --> obsolete, apt-get install --reinstall console-setup --> disappeared
<slangasek> cjwatson: are you poing the auto-upgrade code?
<ScottK> skaet: Did you get an answer from Riddell on respinning?
<cjwatson> maybe something like http://paste.ubuntu.com/902501/
<skaet> ScottK,  nope,  went ahead and scored them for respinning to keep things consistent.  But if you and he disagree,  please flag here and update the pad.
<ScottK> No, I think that's reasonable.
 * skaet nods
<slangasek> cjwatson: LGTM
<cjwatson> minor errors in that, testing/fixing
<cjwatson> slangasek: is there a bug about this already?  (if not, don't worry)
<slangasek> cjwatson: not AFAIK
<cjwatson> slangasek: https://code.launchpad.net/~cjwatson/auto-upgrade-testing/obsolete-conffiles/+merge/99569
<stgraber> ^ initial ISO tracker notification support
<stgraber> (just a quick test)
<stgraber> looks good so far
<stgraber> I made it post queue status + iso tracker to #ubuntu-release and only iso tracker to #ubuntu-testing
<skaet> stgraber,   excellent.   Looks very good indeed!  :)
 * skaet figures it will get a work out this afternoon.
<slangasek> cjwatson: merged, thanks
<slangasek> cjwatson: oops, except not because I don't have commit access
<cjwatson> ... I did wonder
<slangasek> :)
<slangasek> jibel: could ubuntu-dev or ubuntu-core-dev have commit access to lp:auto-upgrade-testing?
<scott-work> skaet: does the new kernel include updating the lowlatency kernel?
<scott-work> skaet: if not, then i don't think ubuntu studio needs to have a respin for beta 2
<skaet> scott-work, haven't seen any updates to it, but not sure.
<infinity> scott-work: It should, but no one's merged and uploaded it yet, no.
<scott-work> skaet: infinity:  i guess a repsin will not hurt, so yes please :)
<infinity> scott-work: Is the only person handling -lowlatency Luke?
<skaet> scott-work,  ok.  will leave it on the list.
 * infinity would merge and upload, but doesn't want the package to get out of sync with git.
<scott-work> infinity: i believe the only person at this time handling -lowlatency is luke (although that is scheduled to change for q-cycle)
<infinity> ogasawara: Would your minions be willing to update -lowlatency to match the base linux (assuming one or more of them has commit access?)
<ogasawara> infinity: I don't think we have commit access
<infinity> Dang.  We should fix that.
 * infinity ponder just applying the tiny diff and letting Luke deal with the fallout later.
<apw> can anyone confirm/deny if the backgrounds for OSD messages is meant to have changed colour in the stuff in the archive 'now' ?
<infinity> apw: I'll answer your question if you update -lowlatency.
<apw> thats a community kernel :)
<infinity> apw: (The answer might be "I don't know", though)
<apw> they promised they would be responsive ... whats its base ?
<infinity> apw: They are responsive, it's only missing your latest -20.33 patch.
<infinity> apw: And Luke's probably asleep. ;)
<apw> any idea where the source even is?
<apw> infinity, its a good job none of the CDs have the image on
<infinity> apw: ubuntustudio does.
<slangasek> git://kernel.ubuntu.com/abogani/ubuntu-precise-lowlatency.git
<slangasek> (per the source package's Vcs-Git field)
<infinity> Curious, I would have expected it to be Luke's, not Alessio's, given who does all the uploads.
<slangasek> maybe the field's wrong, but that's what the package says
<apw> if its that one, its based on -16.25
<infinity> Yeah, it's not that one, then. :P
<slangasek> right
<infinity> Their current upload is -20.32
<infinity> (Well, -20.28, but based on -20.32)
<apw> hmmm ... fun
<infinity> apw: Don't worry too much about it, I'm sure Luke will notice when he wakes up, I've already pinged him.
<apw> ack
<pitti> skaet: anything you need me to do tonight still? otherwise I'd say good night and be online again in ~ 10 h
<skaet> pitti,  one last review of unapproved have what you want in the respin?
<skaet> but then,  yes,  after that,  sleep well.  See you on the flip.
<pitti> skaet: the only thing which might be worth considering is the new nvidia driver, but I don't have context
<pitti> skaet: when in doubt, I'd keep it for post-b2
<pitti> skaet: but it's  not on the ubuntu images anyway (only on ubuntustudio and mythbuntu)
<skaet> pitti,  I'll dig it it a bit this afternoon, but generally post b2
<pitti> the current one isn't terribly broken, so I'd rather have people update post-b2
 * skaet nods
<pitti> skaet: so in summary, nothing that I deem worthy and safe enough to take into b2 at this point
<skaet> THanks pitti.  sleep well.
<pitti> ok, see you tomorrow!
<skaet> good night.
<skaet> :)
 * skaet needs to break to go out for lunch,  seems a good time while builds are stil happening.
<skaet> yup,  linux still has to get through the arm builders...  :/
 * skaet --> lunch
<highvoltage> <troll> linux? you mean the ubuntu kernel? </troll>
<Daviey> cjwatson: Sorry, just saw your question.. When option 2 from the cd menu is selected, now show tasksel
<cjwatson> OK, I assume you'll fix that in maas-enlist-udeb?
<Daviey> cjwatson: yep
<Daviey> cjwatson: been sorting out rabbitmq first.
<cjwatson> 'db_set tasksel/first "standard, server"; db_fset tasksel/first seen true' or some such, I guess
<cjwatson> may have the value wrong
<Daviey> cjwatson: is it "server" or "Basic Ubuntu Server" ?
<scott-work> infinity: skaet : if getting the -lowlatency kernrel updated is putting the ubuntustudio images out of sync (or cadence) with other images then this may be too much trouble at this point for a beta 2
<cjwatson> Daviey: definitely not the latter, use the identifier not the display name
<scott-work> the current beta 2 images didn't include any critical bugs
<infinity> scott-work: Nah, it's no big deal.  The kernel being out of sync won't kill anyone.
<infinity> scott-work: Would just have been nice to have it updated to match, that's all.
<Daviey> cjwatson: ok
<Daviey> cjwatson: looks like, tasksel/first "standard, ubuntu-server"
<Daviey> scrub that.
<Riddell> skaet: evening, did I hear a respin was doine?
<phillw> Riddell: I believe they're waiting for the kernel to get through re-building, then yes - respins are due.
<cjwatson> will need a new d-i in between
<jibel> slangasek, I added ubuntu-core-dev. The admin of the team should have received an invite.
<stgraber> jibel: I'll take care of it
<stgraber> jibel: accepted
<jdstrand> skaet: hey, what project do I use to file a bug to make sure a release note is added?
<stgraber> jdstrand: https://bugs.launchpad.net/ubuntu-release-notes
<jdstrand> stgraber: thanks
<infinity> stgraber: Hrm, queuebot seems to get confused when binary NEW contains translations, and calls it source.
<infinity> (see above with linux-ti-omap4)
<stgraber> infinity: LP is confused ;)
<stgraber> infinity: let me check how I can detect these reliably
<Daviey> Pleae can, cobbler, maas and maas-enlist be accepted please.
<Daviey> beta-2 critical
<infinity> Daviey: Done.
<Daviey> thanks
<stgraber> infinity: ^ it "should" now be translation aware
<infinity> stgraber: Cool.  We'll find out next time it pops up.
 * skaet sees arm still building for linux... :P
<infinity> PPC just finished, though.
<infinity> Barely winning the race. ;)
<infinity> (ARM's nearly done too)
<infinity> But we'll need to iterate through some d-i uploads and such.
<infinity> And we need a new ti-omap4 meta.
<infinity> ogasawara: ^
<stgraber> skaet: is anything already building? if not, we have a few interesting fixes in ubiquity, none that are critical though (one is oem critical but I was told it can wait till Friday)
<infinity> ogasawara: I get in trouble when I upload meta without committing, so if you could? ;)
<ogasawara> infinity: yep, gimme 2min
<infinity> stgraber: Nothing should be building right now, we're still waiting on kernels and moving to d-i, etc.
<stgraber> infinity, skaet: ok, do we want a new ubiquity then?
<infinity> stgraber: If it's 100% regression-free!
<stgraber> http://paste.ubuntu.com/902845/
<stgraber> bug 963460, bug 964472 and bug 950282
<ubot2> Launchpad bug 963460 in language-selector "Ubiquity calls check-language-support with "zh-hans" instead of a locale (zh_CN)" [Medium,Fix committed] https://launchpad.net/bugs/963460
<ubot2> Launchpad bug 964472 in ubiquity "'Detect Keyboard Layout' detects the 'group' correctly, but does not update the selectable layout list" [Medium,Fix committed] https://launchpad.net/bugs/964472
<ubot2> Launchpad bug 950282 in oem-priority/precise "Installation failing with pop-up "The installer encountered an unrecoverable error and will now reboot."" [Critical,Confirmed] https://launchpad.net/bugs/950282
<infinity> Oh, I dunno about skaet, but I'd kinda like those fixes.
<skaet> stgraber,  what infinity said...  :) regression free welcome.
<ogasawara> infinity: that had an abi bump right?
<infinity> Testing all the changed keyboard/language handling stuff we've been messing with more widely would be good.
<infinity> ogasawara: Yep.
<infinity> stgraber: I say go for it, unless skaet objects strongly.  I really don't want all this lang mangling to bite us on release week if it's subtly wrong.
<skaet> infinity, see ^ comments.  ;)
<stgraber> infinity: I'm running it through the tests now, will read through the code again and will upload, eta 10min (it needs to build all d-i components for the tests ...)
 * infinity goes to mangle seeds and d-i for the omap4 ABI bump.
<ogasawara> infinity: uploaded
<infinity> ogasawara: \0/
<infinity> \o/ too.
<infinity> I need new fingers.
 * skaet wonders where she can sign up for those new fingers ;)
<skaet> s/those/some/ ... too.
<infinity> ^-- don't accept this d-i upload until all the kernels are published (I'll keep an eye on that).
<stgraber> ubiquity uploaded
<infinity> Oh, nice, omap kernels finished building just before the publisher started.
<infinity> So, d-i can build in about 20 minutes.
<stgraber> the diff should be easy to read except for the usual ubiquity-2.10.4/d-i/source/tzsetup/debian/common.templates changing for no good reason
<infinity> Heh.
<stgraber> cjwatson: do you have any idea why pretty much everytime I upload after you I get a delta in d-i/source/tzsetup/debian/common.templates ?
<infinity> Different versions of intltool/po-*?
<stgraber> cjwatson: I always clean the branch entirely (as in, remove any ignored file), then run debian/rules update to get a clean copy of d-i/source
<stgraber> infinity: well, it's ubiquity's embedded source copy, so nothing should touch these...
<infinity> stgraber: You sure it didn't also change in tzsetup itself?
 * infinity grumbles about the appservers getting behind on diff generation.
<stgraber> infinity: well, then we'd have a change in d-i/source/tzsetup/debian/changelog too...
<infinity> stgraber: Oh, fair point.  Well, maybe something in ubiquity's clean walks d-i/source and mangles all the translations?  Dunno.
<infinity> stgraber: Or maybe it just dislikes you specifically.
<stgraber> infinity: could be that ;)
 * infinity wishes there would be a bunch of gcc-4.7, kernel-team PPA, and golang-tip uploads all at the same time while we're trying to get things built for Beta.
<infinity> Oh, wait.  Yay.  I got my wish.
<stgraber> ;)
<infinity> stgraber: Will review and accept ubiquity in ~5 minutes when LP catches up with me, and then I'll jam it down the buildds' throats as best I can. :P
<micahg> infinity: I can upload more random stuff if you like :)
<infinity> micahg: Sure.  Chromium, Firefox, Thunderbird, and OpenOffice, please.
<infinity> micahg: Ideally security releases that firebomb 5 releases and eat every builder.  Thanks in advance.
<Daviey> skaet: Are you spinning all flavours soonly, or should i trigger a server one now?
<infinity> Daviey: We're rebuilding d-i.
<skaet> Daviey,  wait for it.
<infinity> Daviey: So, server will need a respin anyway.
<skaet> I'll add server in to the set for the full respin.
<Daviey> skaet: thanks.
<infinity> skaet: Is anything not in that set?
<infinity> skaet: I think we're pretty much at scorched earth "just do it all" land.
<skaet> infinity - do we need a set of netboot ones?
<Daviey> skaet: I believe everything we want in beta-2 is good to go now.  I'm looking forward to smoking a build.
<infinity> skaet: "netboot" = d-i, that's happening shortly.
<stgraber> skaet: netboot will be automatically posted on the tracker when my cronjob detects the new d-i
<Daviey> skaet: building d-i, builds a netboot.
<skaet> infinity,  stgraber,  cool was wondering how that worked.  :)
<skaet> Daviey,  thanks.
<skaet> Daviey,  are there some bug numbers associated with that maas upload?   changelog isn't mentioning any.
<Daviey> skaet: Can you ask the LOSA's to turn the buildd's up to 11, getting impatient :)
<Daviey> skaet: no
<astraljava> skaet: Apparently there's no interest for a respin of Xubuntu images. (sorry it took a while)
<skaet> Daviey,  the one you have to sweet talk on that subject is infinity... he's in discussions with them on improving the situation overall.
<skaet> astraljava - there's some rather nasty bugs we're fixing across the rest of the set, so I'm going to go ahead and respin it at this point.  However if team is happy with the images, we can release with what's on the tracker and tested now.
 * skaet will manually set it back to the current set if you don't want to do the restesting. 
<micahg> astraljava: doesn't xubuntu need the respin for onboard?  (I uploaded the fix specifically for xubuntu)
 * skaet nods
 * infinity scores a bunch of builds up and notes that it might be a good time for releasy people to take a breather.
<infinity> We won't be respinning for a "while".
<astraljava> micahg: Oh, sorry I forgot about onboard! I'll go testing immediately.
<infinity> Hour or two, at least.
<skaet> astraljava,  images won't be out for a couple of hours.  alternates first then desktop a bit after.
<infinity> s/couple/few/
<infinity> Unless I get a LOSA to firebomb the buildd network and take them all over.
<skaet> infinity,  please try.
<skaet> :)
<astraljava> skaet: Yes, I meant the onboard fix micahg has in a PPA.
<micahg> astraljava: use the archive version please :)
<infinity> astraljava: It's in.. What he said.
<astraljava> micahg: Yep, sorry, was offline for a bit and missed these news. :)
<micahg> infinity: it wasn't supposed to be accepted until he tested to made sure it was fixed, but meh :)
<infinity> skaet: Do you have a list of triggers other than d-i and ubiquity?
<infinity> skaet: I need to make sure everything's scored up if I'm going to go the firebomb route. :P
<skaet> astraljava,  if you want that fix,  at this point you'll be having to take the rest.
<skaet> infinity, see pad
<skaet> (and feel free to add any explicitly I've missed.
<astraljava> skaet: Yeah, I suppose that reverses my earlier statement, then. :)
<skaet> :)
<skaet> stgraber,  looks like there is a stale version of ubiquity (2.10.3) in proposed.   Remove it?
<stgraber> skaet: oh, yeah, it's been copied to precise already according to rmadison
<skaet> Daviey, there was some discussion on an openMPI fix earlier,  is that still on the list to land for beta 2, or are we release noting?
<Daviey> skaet: I spoke to rbasak who has touched openmpi for arm the most, and it's an opportunity, but not critical
<skaet> Thanks Daviey
 * skaet notices that linux kernel is now all built
<infinity> skaet: Yeah, hence why d-i is building. ;)
<skaet> :)
<skaet> just noticed that too now.
<infinity> So, I freed up ross for us to let PPC catch up.
<infinity> amd64 will catch up (and pass ARM) soon.
<infinity> We should be good.
<infinity> Still, it'll be a couple of hours before ubiquity's published everywhere, probably.
<skaet> infinity, thanks,  was wondering why amd64 + PPC weren't showing building symbols.   :)
<skaet> yes,  ubiquity is lagging on PPC and amd64 as well, as well.
<infinity> Well, I only freed up one PPC machine, so it's doing d-i first, then ubiquity.
<cjwatson> stgraber: you're running tests/build after debian/rules update, I bet.
<micahg> I've got another version of ubuntustudio-default-settings coming to clean up the conf file handling, won't need to respin for this now
<micahg> s/now/though/
<infinity> micahg: Meh, respins are a bit off on the horizon anyway, may as well let that in too.
<skaet> micahg,  we won't block on it, but if its ready, we'll pick it up.
<cjwatson> skaet: no need to remove old versions from proposed specifically - they won't cause a problem.  I'm working on an improvement to the pending SRU report to emit commands for that.
<skaet> cjwatson,  goodness.  :)
<Daviey> skaet: A potential slight regression.. investigating
 * skaet likes this stgraber!!!  
 * skaet doesn't have to go clickity-click on the project to see if done,  sweet.
<skaet> Daviey,  ack.
<infinity> stgraber: That seems a bit premature.  Where is it getting that "netboot" info from?
<infinity> stgraber: Given that that version of d-i hasn't been published yet...
<infinity> stgraber: And, in fact, is still building on amd64 and i386. ;)
 * skaet has to do clickty-click after all... :(   lol
<infinity> stgraber: If it's polling source, you might instead want to poll archive/ports.u.c/ubuntu{,-ports}/dists/precise/main/installer-$arch/$version
<stgraber> infinity: LP API
<infinity> stgraber: But just asking LP API if the source is published, I'm guessing?
<infinity> stgraber: Since it told me there were new images for all arches, and half of them are still building. ;)
<stgraber> infinity: yeah, I had to go read the script :) it's checking for PublishedSource
<stgraber> infinity: I'll add to the todo to port it to checking individual architectures and post them only when published for the architecture
<infinity> stgraber: I suspect from the POV of testers being able to actually test when the bot tells them, polling the mirrors would be more effective than asking LP.
<infinity> stgraber: Since even asking LP about published binaries will still be wrong for about 30 frustrating minutes.
<stgraber> infinity: hmm, indeed, hardcoding the path and reading the html may actually be easier than implementing the magic needed to check for the various binaries through the API :)
<infinity> Probably. ;)
<astraljava> skaet: Xubuntu should be ready for the respin now, thanks!
<skaet> astraljava,  :)
<cjwatson> well, not until d-i lands
<infinity> d-i and ubiquity should both publish for all arches in the next run.
<infinity> Except maybe ubiquity/ppc.
<infinity> It could be 30 seconds late.
<phillw> infinity: drat :(
<cjwatson> well, half-hourly runs ftw.
 * infinity nods.
<infinity> Though, it will literally be about 30 seconds if it's late. ;)
<infinity> Timing, yay.
<astraljava> cjwatson: Yeah. :) skaet: I'll be sleeping now, so if you have questions/anything for Xubuntu, please ask on #xubuntu-devel, if someone else is awake still. Thanks again for the whole team, see ya tomorrow!
<phillw> infinity: cjwatson so, will a ppc be there for 20120328 for the lubuntu ppc testers?
<infinity> phillw: You bet, it'll get built.
<infinity> phillw: Just commenting on archive publishing being late, the images will happen.
<skaet> astraljava,  thanks.  sleep well.
<phillw> excellent, that gives them a couple of hours to test before the QA meeting Wed evening and, hopefully, beta 2 on Thursday :)
<skaet> Daviey,  if you're still around,  do we have all the pieces accepted from the unapproved queue you want in tonight's images (/me must spotted rabbitmq-server there)
<Daviey> skaet: Yep! Rabbit needs to go in.. I thought that was already accepted.. well spotted
<skaet> debian/rabbitmq-server.init: emit 'rabbitmq-server-running' signal for  upstart as MAAS needs it.
<skaet> ok,  doing now
<Daviey> skaet: I have one more issue, working through it now
<skaet> Daviey,  put a note of the package affected on the pad,  under invesitgation, so I can remember to keep an eye open for it.
<Daviey> k
 * skaet is wondering why openmpi sources with the comments in them against arm are listed in edubuntu sets
<Daviey> skaet: Happy for me to remove triggers satisfied ?
<skaet> Daivey,  I'll do a clean sweep of it to the bottom, once all the pieces are ready and the rebuild startds
<skaet> *starts even.
<Daviey> skaet: Yep, but things blocking spin which are solved, you still want on there?
<skaet> yes,  I'll be doing a double check before kicking and its easiest that way
 * skaet not having to look in two places
<Daviey> k
<Daviey> skaet: you have 2 [23]'s
<skaet> Daviey,  good spotting,  fixing.
 * skaet sees ubiquity's almost done building.  :)
<infinity> skaet: Yeah, ppc missed.  We'll get it in ~45 mins.
<infinity> skaet: Could start with preinstalled at the end of this publisher run (~20 mins?) to give ARM a head start.
<skaet> infinity, debian installer's done.   should os-prober be accepted from the unapproved queue?
<skaet> infinity,  yup,  can do.  re: arm.
<skaet> infinity,  we may need to make sure the server bits are all in place for it though.  (rabbitmq-server landed)
<cjwatson> os-prober - no point unless you also accept the grub2 upload I haven't prepared yet
<cjwatson> that's a two-part fix
<cjwatson> it doesn't *hurt* on its own, but it won't gain much of anything
<skaet> cjwatson,  thanks.  ok,  we'll leave it in the queue then.
<infinity> skaet: Well, if we want to make the rebuild a simple fire-and-forget, then, ubiquity/ppc and rabitmq/all will both publish in the next cycle, so you can just press the big red "build everything" button in ~40ish.
<infinity> Assuming the publisher doesn't wrap itself.  Let's see. ;)
 * skaet likes simple....
<infinity> Okay, the publisher's not going to eat its own tail.  So, the above bits we're waiting on will be on-disk in 30ish.
<skaet> infinity,  all bits except rabbitmq-server (ubuntu3_all.deb) seem to have emerged,  will start off the arm ones now, and desktop;   will add alternate/server in as soon as I see that bit.
<skaet> can you see anything I've overlooked?
<infinity> skaet: Err, yeah.  Wait on desktop images that include PPC.
<infinity> skaet: Like I said, ubiquity/ppc is in this same run as rabitmq.
<infinity> skaet: (And if you want to just do one big build, hold off for ~20)
 * skaet thought ppc was there.... re-checking..
<infinity> Nope.
<infinity> Don't trust the LP UI.
<infinity> It marks things publishes as soon as the publisher starts.
<skaet> http://us.archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/?C=M;O=D
<infinity> Not sure what I'm meant to be seeing there, as PPC isn't on archive at all...
<skaet> infinity,  ah,  thats where I was checking.  educate please.  where should I be checking for it?
<infinity> skaet: ports.ubuntu.com/ubuntu-ports would be the mirror that has powerpc/armel/armhf binaries.
<skaet> infinity, *doh*  yes.  sorry.
<skaet> yeah,  ubiquity/ppc missed the :03 publishing run
<infinity> I know. :)
<micahg> ^^ fixes conffile migration for ubuntu studio, not needed on image, but needed in archive
<infinity> micahg: I'll accept it after we do the images, then.
<infinity> skaet: Publisher's done, you can rebuild the world anytime.
<skaet> infinity,  hmm,  not showing up on the ports mirror quite yet.   will give it 5 and then kick it all in motion.
<doko> infinity, yes I need to restart the rebuild. will do that on Wed
<skaet> ah,  its there.
 * skaet kicks
<infinity> skaet: All the builds operate from ftmaster directly, you're good.
<phillw> the clock is sticking guys, No sod the clock.... about what time, in UTC, do you fantastic guys reckon the re-spins will be done? Ah, UTC / Vs BST... it is Wednesday here :)
 * skaet goes to reset the iso tracker.
<infinity> phillw: Well, they're starting now.  So.  Sometime later than now. ;)
<skaet> phillw,  alternate should be done within the hour,   desktop will be a bit longer.
<phillw> Hey guys, having sat on this channel for a couple of days, I will admit I understand less than 50% of what you discuss. My question, for lubuntu, is quite simple. Have we enough testing reports in to maintain our current set of Lubuntu variants? i.e. the Mac stuff.
<infinity> phillw: For any given flavour/arch combination, one good boot/install smoketest is all we're really looking for.
<infinity> phillw: Someone to say "it booted and didn't eat my pets when I clicked on stuff".
<infinity> phillw: We hold Ubuntu itself to a higher standard, but for community flavours/ports, we understand that testing bandwidth is limited, and we just need to know we're not building and shipping dud images.
<phillw> infinity: it does drive the testers mad, they report that the beta 2 release installs (even with bugs), then the next day - it is all gone? how does that work?
<infinity> phillw: It all goes away when there's a new image candidate (as is happening right now).
<infinity> phillw: Since it's the image itself we're testing, not the state of the archive, we need to know the image we ship is known-good.
<skaet> phillw,  the results are all still there on the tester,  just reported against the prior image.
<phillw> infinity: so, no matter what testing has been done - it counts for nothing for when the decision is made to release, in this case, the beta 2?
<skaet> phlllw, http://iso.qa.ubuntu.com/qatracker/milestones/210/history
<skaet> will show all the prior bugs found
<phillw> skaet: so, if it has been shown to be tested, is that enough to drive it forward?
<skaet> phillw, the testing does matter.   Several times we've held off on releaseing images if the testing indciated key problems.
<infinity> phillw: For betas, you can cheat and nominate an old image, and say "please just ship that", but for final release, yeah, the only one that matters is the last one we build.
<cjwatson> "Counts for nothing" is a bit strong, but the weirdest things can cause images to fail.
<infinity> phillw: That said, any testing leading up to the final image is, obviously, good.
<cjwatson> We tend to be paranoid.
<phillw> cjwatson: my aopolgies,
<skaet> phillw,  if it has been fully tested on one instance, and then spot tested,  it's likely to go through.  its the entire history that matters.
<cjwatson> phillw: no need :)
<skaet> phillw, for each of the flavors I try to make sure that the leads and QA reps are comfortable with the images before we make the ship/not decision.
<phillw> what I meant was, there are guys testing the ppc / Mac stuff. And I really find it hard to ask them to run every test at every stage of a respin
<skaet> phillw,   just ask them to spot check at this point if they've done the full set already.
<phillw> As long as it noted that testing has been done, that will be excellent news to them
<skaet> as infinity says, for the final release its different - we do need to know all is well, but for the beta's if all the tests have been done, and no irregularities show up with last image from spot testing,  all should be reasonable risk.
<phillw> skaet: I am aware that this is a major re-spin, but if they cannot get them all done by about midnight Thursday, which is Beta 2 release day, will their previous tests count?
<cjwatson> Even knowing that the image still boots is somewhat reassuring, though installability in at least one mode is nice.
 * cjwatson is still slightly scarred by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368969
<ubot2> Debian bug 368969 in squashfs-tools "rounding error causes generation of invalid filesystems" [Critical,Fixed]
<skaet> phillw,  as cjwatson says,  if they've all been done at some point,  and the spot testing looks good.  we're fine for beta.
<infinity> cjwatson: Good times.
 * skaet goes to look at that bit of history... 
<cjwatson> that's also https://launchpad.net/ubuntu/+source/squashfs/1:2.2r2-2ubuntu2
<phillw> thank you. the last thing I wanted to do was to give false hope to the new band of ppc / Mac 64 testers.
<cjwatson> And in some ways was the genesis of our current practices ...
<infinity> phillw: Like i said, a quick boot/install smoketest is all we really require of most flavours/ports anyway.  So, hopefully that's not too onerous for them.
<phillw> infinity: it will be done.
<cjwatson> (Background: we changed something completely inconsequential.  Suddenly the Ubuntu desktop image kernel-panicked.  We had no idea why until Scott stared at it for a few solid hours.)
<infinity> phillw: I think people get the wrong idea about how much testing they MUST do.  As always, more is better, and we love bug reports (and patches), but to be able to ship and image, we just need to know it's not completely DOA/broken.
<infinity> s/and image/an image/
<cjwatson> Of course, it's silly to fight the last war, and we probably won't see that kind of image misgeneration again.  But everyone still likes to know that *somebody* has tried any image we release.
<phillw> infinity: would a PM be allowed?
<infinity> phillw: Depends on which PM it is.  If it's not Stephen Harper, sure.
<slangasek> infinity: the threshold for betas is considerably higher than "not completely DOA/broken"
<phillw> infinity: im on my name in here
 * micahg thought that was alpha criteria
<slangasek> hmm, now why did the daily upgrade test not spit out any results for lucid-server today
<infinity> slangasek: I said what we need to know, not what we like to know.  I'd like to think that the flavour folks won't ship an image that doesn't look/do as they think it should.
<infinity> phillw: I think you missed my sarcasm.  PMs are fine. :P
#ubuntu-release 2012-03-28
 * phillw just what we need in a testing cycle.... sarcasm
<infinity> micahg: Did your ubuntustudio-default-settings forget a Pre-Dep on a dpkg that supports maintscript-helper, or was it already there?
<infinity> micahg: Ahh, nevermind, it was already there.
<pgraner> skaet, ETA on images dropping?
<skaet> pgraner,  they've started posting now.   alternates and server are all up
 * pgraner needs to plan his drinking accordingly
<infinity> pgraner: That's some solid prioritizing.
<skaet> :)
<pgraner> infinity, dude two nights of late drops... you're lucky I can type
<infinity> pgraner: Timezone shift, man.  Drink in the morning, work at night.
<infinity> pgraner: As a former manager of mine used to remind me, "it's always happy hour somewhere."
<skaet> ubuntu alternate,  ubuntu dekstop, ubuntu server, ubuntu server arm should all be up.   ubuntu preinstalled arm are building now.
<skaet> ubuntu dvd will be a while.
<pgraner> infinity, I look at the whole day/night drinking times as limitations, I don't like being limited
<skaet> LOL
<pgraner> skaet, yep they are rolling in, I'm doing ARM first, then alternate, and desktop last
<skaet> pgraner, sounds good.   flag here if any ugglies.
 * skaet crossing fingers no ugglies.
<cjwatson> slangasek: oho, aptitude 0.6.6-1
<slangasek> hmm!
<slangasek> cjwatson: are you going to merge it?
<cjwatson> can do though not tonight
<slangasek> ok, cool
 * slangasek assigns you the bug then ;)
<cjwatson> <- sucker
<infinity> Oo.
<infinity> It has the magical m-word.
<skaet> stgraber,  only selected images being published are being reported in the channel.  Anything special needs to be done?
 * infinity wonders idly where he can find 13MB to drop off the Ubuntu/PPC image.
<stgraber> skaet: the bot was disconnected after flooding freenode earlier
<skaet> stgraber,  gotcha.  thanks.
<stgraber> added an hack to delay messages a bit to avoid being kicked out
<cjwatson> that maas-enlist change is kind of important to avoid a rather obvious error
<cjwatson> I've reviewed and accepted it
<cjwatson> if pad.ubuntu.com will talk to me ...
<cjwatson> hm, server was already built in this round
<cjwatson> so I guess it's up to the server leads to ask for a respin if they want one
<infinity> It was only *just* rebuilt, spinning it again wouldn't be world-ending, I bet.
<infinity> And that bug seems annoying.
<cjwatson> As well as the bug described, the particular manifestation of it will include the maas-enlist-udeb installer step failing with a red screen, I think.
<hggdh> cjwatson: does d-i output 'question will be asked' even if a response is in the preseed?
 * hggdh sees an error on server raid, seemingly because of that
<cjwatson> hggdh: Not normally.  Point me to details?
<hggdh> cjwatson: we run, under Jenkins, the ISO tests for server. For the new ISO, I got a failure on the RAID test. Looking at the current (failed) syslog, I see a 'question will be asked'. Since I look for it, I cancelled the run automatically
<cjwatson> Do you have a URL for me?
<hggdh> cjwatson: but looking at the *previous*, successful, run, I also see a 'question will be asked'
<hggdh> yes
<hggdh> cjwatson: https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/126/console
<hggdh> the full syslog is in here: https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/126/artifact/126/test-results/
<cjwatson> hggdh: Well, firstly, grub-pc/install_devices isn't preseeded (perhaps you're thinking of grub-installer/bootdev).  But it shouldn't be preseeded anyway.
<cjwatson> hggdh: Secondly, this question is INPUTted in a kind of weird environment, and (although I can't see precisely why right now) it's quite possible it might say "question will be asked" when it in fact won't be.  If I were you I would disregard that one unless it's actually causing an automatic install to hang for itself.
<hggdh> cjwatson: thanks. I will correct the code so that it will only fail the test if we are stuck on a
<cjwatson> It is a bit weird, but debconf debugging was designed for human consumption rather than machine :-)
<hggdh> 'question will be asked' right now. Later on I will look at the first point you made
<cjwatson> Well, the first point doesn't contain any action for you
<cjwatson> Your preseed looks fine from this point of view
<hggdh> even better :-)
<hggdh> this is a timing error on my code, then (and the first time since jaunty (when we added this test) that it happened
<cjwatson> If it actually hangs, obviously, I'd like to know about it
<hggdh> ack
<cjwatson> looking at the successful log, this is something to do with passthrough weirdness, indeed
<cjwatson> https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_raid1/125/artifact/125/test-results/d-i-syslog.log.gz
<cjwatson> after the first "INPUT high grub-pc/install_devices", there's some fiddling around with DATA (which transfers template information from one debconf frontend to another) and SUBST, and then it reissues the INPUT
<cjwatson> the second time, it gets "question skipped"
<hggdh> k
<cjwatson> Oh, of course, this is a consequence of debconf-apt-progress
<cjwatson> Sorry, for extremely limited values of "of course" probably confined to the person who wrote the code
<hggdh> :-)
<cjwatson> I'll explain in case anyone cares
<phillw> Just so as this little borg drone knows before he goes for regeneration cycle, how are the respins going?
<cjwatson> debconf-apt-progress deals with bridging apt download and install progress bars into debconf progress bars so that they can be displayed nicely, particularly in the installer
<cjwatson> This involves two instances of debconf, one for the progress bar and one passing through questions from the package(s) being installed
<cjwatson> (Not to mention cdebconf, which runs in the installer environment and is what actually displays everything - they're all chained together in a way that took me weeks to get working to start with but now I just ignore it most of the time)
<cjwatson> Now, it's painful to run two instances of debconf normally, because they both want to lock their config database when they start up
<cjwatson> So what you do is you take the one that passes through questions from the package being installed, and give it a database which amounts to /dev/null; it just shunts everything over to the instance that's running the progress bar
<cjwatson> This means that the debconf instance that *first* sees the INPUT command here has no idea that the question has been preseeded
<cjwatson> It isn't until it forwards it to the second one, which actually has a database worth talking about, that it knows about the preseeding so you get "question skipped"
<hggdh> ah
<cjwatson> This certainly makes machine parsing challenging, but that was never in the plan for that debug output :-)
<cjwatson> So I don't feel too bad about it
<hggdh> heh. It will be easy to fix my code, anyway -- just compare previous 'question will be asked' line with the current -- if they are the same, then we are stuck
 * cjwatson idly notes that debconf-apt-progress is one of the few debconf programs nobody has got round to reimplementing for cdebconf yet ...
<phillw> cjwatson: I do not suppose that any time soon you could explain that for us mere mortals? But, if you have got the handle on it & we will have isos, I trust in you guys just as I trust in MOTU's.
<cjwatson> phillw: I think that was the best I could do without a whiteboard
<cjwatson> As for respins, the desktop/DVD sequence seems to be working on Lubuntu at the moment
<stgraber> now with tested anti-flood protection, hopefully it won't get kicked out any time soon
<cjwatson> or rather the desktop sequence, looks like DVDs are being done in parallel with that
<cjwatson> skaet: any particular reason bug 959224 is listed as a target of opportunity?  I don't plan to look at that this week.
<ubot2> Launchpad bug 959224 in choose-mirror "Corrupt value for /etc/apt/apt.conf accepted during installation" [Medium,New] https://launchpad.net/bugs/959224
<cjwatson> It's only a validation bug; certainly a bug but there are more important things and it doesn't block installation
<phillw> cjwatson: I am guilty, it just seems a really silly bug
<cjwatson> Sure, but it shouldn't be tracked here
<phillw> cjwatson: it does not, but it blocks updates
<cjwatson> Only if you entered it wrongly during installation.  It doesn't block otherwise.
<cjwatson> What I mean is it isn't a blocker for everyone, or even most people.
<skaet> cjwatson,  noted it there from earlier discussion, wasn't sure.   remove it if you're not looking at it,  no worries.
<phillw> cjwatson: it was only a suggestion, as it may have tied in with the wriong mirrors being suggested.
<cjwatson> Wrong mirrors being suggested?
<cjwatson> (Bug#?)
<phillw> cjwatson: sorry, seems to be same bug
<cjwatson> phillw: OK, well, that bug only affects the proxy setting
<cjwatson> I'm happy to try to fix it for final if I have time
<cjwatson> Though it's very unlikely to be new; I suspect it goes back a long way.
<phillw> cjwatson: both lubuntu and another flavour reported it.
<phillw> cjwatson: remove that, the bug 966450
<ubot2> Launchpad bug 966450 in debian-installer "Kubuntu doesn't prompt for a password on encrypted LVM boot (dup-of: 966403)" [Undecided,New] https://launchpad.net/bugs/966450
<ubot2> Launchpad bug 966403 in debian-installer "Lubuntu Install (entire disk with encryption) doesn't prompt for disk password." [Undecided,New] https://launchpad.net/bugs/966403
<phillw> which is an install bug
<cjwatson> FWIW I did such an installation earlier today (or was it yesterday?) and it was fine
<cjwatson> It's actually probably not an installer bug
<cjwatson> That's first boot, so it's more likely to be cryptsetup or plymouth or something
 * cjwatson sends it over to cryptsetup as a first pass
<cjwatson> (which for the avoidance of doubt means somebody else will probably need to figure it out ...)
<phillw> cjwatson: do you have the time to set the bugs as such and see if it comes back? I've seen reports of encryption bugs earlier & would like to clear the ground on them. Thanks.
<cjwatson> "set the bugs as such"?  don't understand, sorry
<phillw> cjwatson: well, either fix released, or needs more information? The two bug reports have a lot of data, but if there has been a release that retrospectively makes them invalid, then a simple "please check with latest release" will suffice?
<cjwatson> I don't think that would be appropriate; he only just reported it
<cjwatson> and I don't know what information is needed, not being a cryptsetup expert and being fairly rusty on plymouth
<cjwatson> so it's best if somebody else looks
<cjwatson> "fix released" would certainly be wrong since (a) chances are it's just that it happens on his system and not mine for some reason or other (b) even if it had been fixed I can't point to the fix
 * slangasek reassigns to plymouth
<phillw> cjwatson: has there been any testing of encrytpted in ubuntu
<cjwatson> slangasek: right :)
<slangasek> phillw: I test it every time I reboot
<cjwatson> phillw: it's on the routine test cases so it's tested at every milestone
<cjwatson> but it's important to be aware that this kind of thing can easily be hardware-specific
<phillw> cjwatson: slangasek in which case, how do these bugs arrive? Please do understand that I am really new & trying to learn
<cjwatson> even successful testing doesn't immunise you from hardware-specific problems
<cjwatson> or the category of problem described by http://en.wikipedia.org/wiki/Race_condition
<stgraber> which sadly makes for the majority of these annoying bugs...
<cjwatson> plymouth (the software that handles input/output multiplexing at boot, and also displays a splash screen) takes some quite different code paths dependent on the graphics card, for instance, and is also more prone than most to delicate race conditions that take ages to track down
<phillw> cjwatson: I saw that as bug earlier, I'm gradually getting used to this weird and wonderful language you speak in :)
<phillw> I'm pretty much barred from speaking about the installing of 'strict' GTK3 rules. But I am getting better to understand that #shit happens#
<phillw> how you guys do this? WOW
<cjwatson> http://people.canonical.com/~ubuntu-archive/pending-sru.html <- "The following packages have an equal or higher version in the release pocket and should be removed from -proposed:"
<cjwatson> whee
<cjwatson> (hand-checked and processed)
<cjwatson> I do wish lp-remove-package.py would tell you about the pocket it's removing from in its output.  Always gives me heartattacks.
 * skaet just goes to look at the link.  :)
<skaet> looking good cjwatson.  :)
 * skaet --> evening dog walk,  biab
<cjwatson> Is anyone with cocoplum access still using any of the old crap in ~lp_archive/python/?
<cjwatson> I'm not seeing anything likely elsewhere in ~lp_archive/, and I strongly suspect it's all been superseded by launchpadlib-based stuff in ubuntu-archive-tools.
<slangasek> not me
<cjwatson> I'll nuke it tomorrow morning unless somebody shouts that they care.  Speak now or forever hold your peace.
<infinity> cjwatson: Not I.
<infinity> cjwatson: Also, regarding lp-remove-package.py heart attacks, I could have sworn someone filed a bug about better verbosity, like, 6 years ago.  But I can't find it.
<skaet> pitti, infinity,  only images left to come off the builder are wubi, and ubuntu mx5/ac100 kubuntu omap4.   pad has been updated.
<skaet> good night.
 * skaet --> zzz
<infinity> stgraber: queubot's seeing double.
<phillw> infinity: please tell me that is a joke.....
<infinity> stgraber: (See all the double entries for mosh)
<infinity> stgraber: Or, triple...
<pitti> Good morning
<pgraner> morning pitti
 * pitti accepts the -proposed uploads
<pgraner> ogra_, is the TI icon supposed to be in the launcher on omap4 desk top?
<pitti> everything else in unapproved is seeded somewhere
<didrocks> pitti: if I use mass-sync.py to sponsor some bug fixes sync from debian (and for universe), that won't bypass the freeze, isn't it?
<pitti> didrocks: I don't know about mass-sync; why not just use syncpackage?
<pitti> didrocks: in the past, syncs from cocoplum went straight through, without being held in unapproved
<didrocks> pitti: can use syncpackages with -n -e options
<didrocks> pitti: I guess it's not very important for 2 packages in universe, right?
<pitti> didrocks: -s for sponsoring, please
<didrocks> ah ok, yeah, seeing -s :)
<pitti> -n/-e are for --no-lp syncs
<didrocks> ok ;)
<didrocks> so, it's in unapproved :)
<ogra_> pgraner, theoretically yes, practically i dont think anyone but tobin has teswted desktop in a while and technically we planned to switch to jockey for the driver and just add a wiki page for the codecs from the PPA
<ogra_> (in which case we dont need the icon anymore)
<ogra_> the latest pvr drivers are sitting in NEW so they wont make beta2, the old ones in the PPA are broken, so the icon is moot anyway atm
<ogra_> (broken for precise)
<cjwatson> infinity,stgraber: not so much seeing double, as misrepresenting binary as source.
<cjwatson> didrocks: mass-sync.py is decommissioned for everything except backports.  (I forget whether I actually made it not work for syncs.)
<didrocks> cjwatson: ah, thanks for the hint, I'll have a look at the wiki page later and probably make a note if not there already
<cjwatson> aha, I actually made mass-sync.py call syncpackage if you try.
<cjwatson> But mass-sync's interface is kind of awkward so you might as well call syncpackage directly (preferably without --no-lp).
<didrocks> ah, it was a trap then! :)
<didrocks> (btw, I still have syncpakcage running and not closing the sync bug until the universe sync is approved)
 * cjwatson will be starting work properly in a few minutes and will look then
<ogra_> pgraner, what is the bug you tracked as bug 966858 on the tracker, LP gets me to an error page for it
<ogra_> (and given it seems to block the panda images it would actually be good to know what it is)
<cjwatson> didrocks: ^-
<didrocks> cjwatson: thanks :)
 * ogra_ wonders why oem-config always takes so long to come up ... the ac100 usually gets you to lightdm in less than 15sec from powering on ... the installer takes about 2min to start ubiquity-dm
<cjwatson> mvo: doesn't skype-bin need to be Multi-Arch: foreign?
<mvo> cjwatson: ups, yes you are right, let me fix this
<infinity> cjwatson: Ahh, were those binary NEW with translations, by any chance?  stgraber was having issues making those DTRT.
<cjwatson> infinity: Not sure at this point.
<infinity> cjwatson: Hrm, no they're not.
<infinity> cjwatson: So, a regression while he was trying to fix the other case, I guess. :P
<mvo> cjwatson: I will upload a new skype in a bit with the missing multi-arch: foreign and also with a conflicts/replaces for skype-bin on older skype versions. anything else you can think of that I may have missed? is the general direction sensible for the lucid->precise skype upgrade or do you have a alternative idea that might work, the -bin package is a little bit ugly
<cjwatson> mvo: that was all I noticed.  Also Breaks/Replaces rather than C/R I think
<mvo> thanks!
<pgraner> ogra_, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/966858
<ubot2> Launchpad bug 966858 in gnome-settings-daemon "[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode()" [Undecided,New]
<ogra_> pgraner, oh, i filed the same yesterday, funny that apport didnt point you to it
<ogra_> but given it respawns fine, why did you mark the image failed ?
<ogra_> its surely a wart (like the missing icon) and should be noted in the release notes ... but the image generally works
<ogra_> i.e. "good ehough for a beta"
<ogra_> *enough
<Riddell> no images listed for testing http://iso.qa.ubuntu.com/qatracker/milestones/210/builds/14369/downloads
<pitti> Riddell: for which milestone should that be?
<pitti> err, image
<pitti> http://iso.qa.ubuntu.com/qatracker/milestones/210/builds has quite a lot
<Riddell> pitti: for ubuntu desktop beta 2 armhf+omap4
<cjwatson> Mm, I think it just doesn't know the URLs.
<Riddell> I think so too
<cjwatson> should be http://cdimage.ubuntu.com/daily-preinstalled/20120328/precise-preinstalled-desktop-armhf+omap4.img.gz
 * Riddell eyes up pitti as a member of the ubuntu desktop team who has powers to add them
<cjwatson> He does?  It needs DB access.
<cjwatson> I think.
<Riddell> no it's all improved
<Riddell> just needs admin access to that site
<cjwatson> oh maybe so, I was logged out
<cjwatson> I can do it then
<pitti> looking
<cjwatson> pitti: I'm on it, unless you want to
<pitti> cjwatson: ah, thanks
<pitti> I just found where to set that
<pitti> so, please go ahead
<cjwatson> OK, it's pretty cumbersome and manual, but done for armhf+{omap4,omap}
<Riddell> is a release sprint happening this release?  how do I get invited along?
<cjwatson> https://wiki.canonical.com/UbuntuEngineering/Sprints/PreciseReleaseSprint
<Riddell> cjwatson: lovely, and I get invited along by just putting my name on there and magically a hotel room will be allocated to me?
<pgraner> ogra_, yea I agree
<cjwatson> Riddell: I don't know, you should probably ask Kate
<Riddell> skaet: hello
 * phillw sulks ... not allowed to even view https://wiki.canonical.com/UbuntuEngineering/Sprints/PreciseReleaseSprint
<phillw> btw, was last night / this morning the final respin for beta 2 RC?
<Laney> that's because it contains next week's lottery numbers
<phillw> Laney: I recall a 0 day horror that had the devs attending the release party all locked up and respinning whilst the forum went into melt down with people screaming "Why is not released yet!".... I'll give it a miss :P
<Daviey> cjwatson: What was the upload from a few days ago for inclusion ?
<Daviey> from roaksox ?
<skaet> Riddell,  release sprint participation in london is being limited explicitly,  we're looking into setting up a G+ hangout for those not able to be there in person.
<cjwatson> Daviey: powernapd
<Daviey> ah
<Daviey> I didn't think it was critical for beta-2 TBH.. but ok.
<cjwatson> That's fine, then just bump the bug milestone
<Riddell> phillw: it held next door to MI5 and opposite MI6 so it's pretty tightly controlled
<Riddell> phillw: there have been respins, we won't know if they're final or not until they are all tested to work correctly
<apw> skaet, we have a further (single) report of issues with aspm on the latest kernel.  after long discussions we think it is better to leave things as they are and make sure its documented in the notes.  this is based on the belief this may well be a bios issue, and that there should be work arounds we can document.  therefore we would much prefer to leave the code in to find out if there any other
<apw> affected machines with a note in the release notes; all this for B2, using the results of that to make an informed decision for release
<skaet> apw,  please add the release note to the TechnicalOverview, along with bug number.   if there are workarounds available, release note should be ok.   We're getting to late to do another respin unless its a kitten killer.
<apw> skaet, yeah that was my feeling
<skaet> apw,  if things change as the testing emerges,  flag me please.
<apw> skaet, ack
<phillw> Riddell: thanks, we're just waiting on powerppc for lubuntu to be tested and we are good to go :)
<skaet> jibel,  any concerns on your list from the testing so far,  other than the kernel bug ^ referenced?
<skaet> pitti,  cjwatson - pad is looking quiet,  any concern areas showing up on your radars?
<pitti> not from here
 * skaet hopes the trend continues.... :)
<skaet> thanks
<cjwatson> all quiet on the western front so far
<skaet> phillw,  lubuntu test team rocks!   just saw that almost all the images have been tested now. sweet.  :)
<jibel> skaet, nothing from me.
<jibel> testing mac now
<skaet> thanks jibel.  :)
<highvoltage> hi, shouldn't https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/913731 be a release critical bug?
<ubot2> Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed]
<highvoltage> I just had a colleague tell me that ubuntu server installations have been broken for the last few weeks because he doesn't get a login prompt, and it's reasonable to expect that many, many ubuntu users will think the same when installing it
<skaet> Daviey,  ^ thoughts?
<ogra_> Riddell, did you get to test the panda image ?
<Daviey> looking
<Daviey> skaet: It's something i'm happy to release note for b2.. I don't think it's a blocker.  I'd surprised I hadn't seen it myself TBH. :)
<Riddell> ogra_: yep
<ogra_> Riddell, aaaaand ?
<skaet> Daviey,  thanks.  Release note it is.
<Daviey> cjwatson: I see bug 913731 is assigned to foundations, is it on your hit list for release?
<ubot2> Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed] https://launchpad.net/bugs/913731
<Riddell> ogra_: same bug in the graphics driver bug 961133
<ubot2> Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133
<Riddell> found a new monitor where it works using the other port at 640x480
<doko> infinity, test rebuild started
<ogra_> Riddell, ohh, intresting, can you note that on the bug and also talk to robclark in #ubuntu-arm ot #pandaboard ?
<Riddell> ogra_: bug is updated, I can try pinging rob
<skaet> highvoltage,  could you take a pass at updating the https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview for Edubuntu?
<cjwatson> Daviey: hmm, not right now, slangasek, what do you think?
<cjwatson> slangasek: (913731)
<highvoltage> skaet: will do
<Daviey> It's not critical but a nicety IMO.
<skaet> thanks!  :)
<stgraber> highvoltage: I'm currently in a meeting but I can have a look at the TechnicalOverview in an hour or so if you don't have time to look at it now
<highvoltage> stgraber: thanks, I'll try to take a stab at it in the meantime. is it confirmed that we should include all the changes since the beginning of the cycle?
<stgraber> highvoltage: for Edubuntu, I'd prefer we do that yes, maybe hilight changes from beta1 but IIRC the only change is translation update and bugfix releases of epoptes and ltsp
<pabelanger> Morning, I just created a FFe (bug 967195) to help resolve bug 965484.  If a bug manager would be kind enough to help triage it, thanks
<ubot2> Launchpad bug 967195 in ruby-rack "FFe: Sync ruby-rack 1.4.0-1 (universe) from Debian wheezy (main)" [Undecided,New] https://launchpad.net/bugs/967195
<ubot2> Launchpad bug 965484 in redmine "redmine : Depends: ruby-rack (>= 1.4.0) but 1.3.5-1 is to be installed " [High,Triaged] https://launchpad.net/bugs/965484
<Riddell> pabelanger: bug triagers I think are in #ubuntu-qt and universe packages are maintained by MOTU who I think are in #ubuntu-motu
<ogra_> Riddell, yeah, that would help for sure, rob maintains the graphics drivers for the panda (sorry in meetings atm)
<pabelanger> Riddell: right, but I though I needed somebody from ubuntu-release to first triage the FFe, before having somebody in MOTU sponsor the sync process
<Riddell> pabelanger: ah for the FFe yes that needs approval from ubuntu-release, but it'll be much easier if a MOTU has already commented on the bug "yes this is good we want it"
<pabelanger> Riddell: okay, let me get that for you
<infinity> stgraber: Did you look into queubot's confusion about binary NEW from last night?
<infinity> stgraber: The queue entries that confused it (mosh, on a few arches) are still in oneiric-backports/new.
<stgraber> infinity: nope, I saw it in the backlog but haven't tried fixing it yet. I'm currently looking into an LTSP bug, then have the edubuntu techoverview to look at and the perf review stuff to get done (now that HR fixed my account). So I'll look at the bot this afternoon/evening
<infinity> stgraber: Oh, yeah, not a priority by any means, was just curious if you caught the backscroll.
<Daviey> skaet: Would like to do a server rebuild in ~2 hours.  If you are happy, I'll make sure all testcases are satisfied on the new build.
<pitti> skaet: I'm off for TKD/dinner, etc.; will check back in after it to check for any new fires, but it seems rather quiet ATM
<hggdh> Daviey: We, the sufferers, will also test it ;-)
<Daviey> hggdh: What would we do without you?
<ogra_> suffer yourself indeed :)
<skaet> thanks pitti.
<skaet> Daviey,  ok for the respin if it helps.
<phillw> guys, a bit of bad news :( bug 967257
<ubot2> Launchpad bug 967257 in lubuntu-meta "PPC Install CD from 28 Mar does not boot" [Undecided,New] https://launchpad.net/bugs/967257
<phillw> Lars is a good tester for mac stuff. If he says it's broken, it's broken.
<cjwatson> Has he tested any other powerpc images successfully?
<cjwatson> I'd like to know whether this is Lubuntu-specific for some reason.
<cjwatson> Or any images from earlier?
<cjwatson> I can have a look in qemu, but the download will take the best part of an hour and I suspect I'll have finished for the day by then.
<cjwatson> So any narrowing down of where/when things broke would be helpful.
<phillw> I've asked him. We did have working isos from ppc before.
<infinity> I've asked for a bit more verbosity on "doesn't boot".
<phillw> http://iso.qa.ubuntu.com/qatracker/milestones/210/builds/14310/testcases
<slangasek> cjwatson: bug #913731> so I actually sat down at the global jam and worked through this question; we have a tentative fix for plymouth, but I'm concerned that it could be racy
<infinity> cjwatson: Possible that the default yaboot config might be aiming at powerpc instead of powerpc-smp?  Though, I'm pretty sure I got every such case I saw.
<ubot2> Launchpad bug 913731 in plymouth "non-X installs still have vt.handoff=7" [High,Confirmed] https://launchpad.net/bugs/913731
<phillw> my guess would be that the iso does not get recognised as a boot CD
<cjwatson> infinity: It's a good possibility
<slangasek> cjwatson: i.e., that having plymouth chvt carries a non-zero risk that installs *with* a GUI will get dropped to vt1
<cjwatson> I couldn't think of any other sensible approach, unfortunately :-/
<slangasek> cjwatson: what about probing for a DM when deciding whether to put vt.handoff on the commandline?
<slangasek> (though this could go pear-shaped in a number of ways and I'm not keen to make this change late in cycle either)
<cjwatson> Possible, but I have similar reservations; in particular it's quite possible for a DM to be installed after the last call to update-grub
<slangasek> yep
<slangasek> or removed
<cjwatson> I'll grant you that that approach is better than hardcoding it at install time, though
<infinity> dpkg triggers to the rescue?
<slangasek> possibly
<cjwatson> Starts getting hairy
<infinity> Combined with DMs shipping the vt.handoff bit as a config snippet, rather than grub doing it heuristically.
<cjwatson> I don't want to introduce new triggers at this point
<slangasek> so the race I'm seeing is as follows:
<slangasek> - rc is nearly empty, so finishes first
<infinity> Well, no triggers, then, just ship vt.handoff as a config snippet, and update-grub in DM postinsts.
<slangasek> - plymouth-stop is called with JOB=rc
<slangasek> - 'plymouth quit' runs and shuts down the splash screen
<slangasek> - DM starts up, sees no splash running, chvt and starts X
<slangasek> - plymouth-stop calls chvt
<slangasek> *maybe* 'plymouth stop' could do the vt switch itself, but that also makes me nervous
<slangasek> 'plymouth quit' I mean
<cjwatson> Can we atomically say "chvt but only if we're on our own VT"?
<slangasek> I don't know
<cjwatson> And also, yes, I thought 'plymouth quit' already chvted
<slangasek> probably not
<cjwatson> and --retain-splash stayed on the same vt
<slangasek> yeah, let me dig into the code then and see
<cjwatson> Doing the chvt outside of plymouth itself does seem doomed to raciness
<slangasek>   if (terminal->initial_vt_number == terminal->vt_number)
<slangasek>     {
<slangasek>       ply_trace ("can't deactivate initial VT");
<slangasek>       return false;
<slangasek>     }
<slangasek> that'll be it
<slangasek> so plymouth only handles a chvt on quit if it started on a different vt than the one it used for splash
<slangasek> seems fixable, but definitely needs some double-checking to make sure there are no races w/ the DM
<infinity> phillw: Grabbing the lubuntu/ppc ISOs, I'll see if I can reproduce and/or debug after an early lunch.
<phillw> infinity: thanks, Mars is grabbing the ubuntuppc - again about an hour.
<stgraber> can I get someone from -release to review bug 967320 before I forward to the MIR team? thanks!
<ubot2> Launchpad bug 967320 in xcompmgr "[MIR] Please promote xcompmgr to main for LTSP" [Undecided,New] https://launchpad.net/bugs/967320
<stgraber> ^ is actually a FFe + MIR
<stgraber> (just updated the title now)
<cjwatson> Huh, the Lubuntu powerpc image claims to be "3.2.0-18-powerpc"
<cjwatson> Oh, sorry, false alarm, that's an out of date Ubuntu one
<cjwatson> Current Lubuntu claims to be "3.2.0-20-powerpc-smp", which is correct
<cjwatson> It's sitting at a black screen in qemu.  Hard to tell if that's just slow or hung.
 * cjwatson tries with --verbose
<cjwatson> But at any rate, from the bug, this isn't the same thing.
<phillw> cjwatson: Julien did say it takes a while with qemu.
 * skaet --> lunch,  biab
<stgraber> skaet: I'm also out for lunch, be back in 30min, will take a look at Edubuntu's tech overview then (sorry, trying to get LTSP's bandwidth usage down and performance up took a bit longer than anticipated)
<phillw> bug 967257 --- YAY!!!!!
<ubot2> Launchpad bug 967257 in lubuntu-meta "PPC Install CD from 28 Mar does not boot" [Undecided,Invalid] https://launchpad.net/bugs/967257
<phillw> As to why he had issues? ... pass. He's a darn good mac tester.
<joshuahoover> can i get someone on the release team to give us the go/no-go on these two freeze requests: #956077 and #851810
<joshuahoover> bug #851810 and bug #956077
<ubot2> Launchpad bug 851810 in ubuntuone-client "[FFe] Notify clients when volumes info from server is ready" [Medium,In progress] https://launchpad.net/bugs/851810
<ubot2> Launchpad bug 956077 in ubuntuone-control-panel/stable-3-0 "[UIFe] Colour changes for the QT control panel" [High,Fix committed] https://launchpad.net/bugs/956077
<stgraber> highvoltage: I think I'm done drafting the Edubuntu techoverview, can you have a look and maybe improve a bit?
<skaet> :)
<joshuahoover> skaet: can you help with getting someone to give us the go/no-go decision on those two freeze exceptions i listed? :)
<skaet> joshuahoover,  they won't make it for Beta2 at this point.
 * skaet going to look at them now,  and see who else needs to review.
<joshuahoover> skaet: right, but we'd like to have them for final if possible, especially the color change
<skaet> joshuahoover,  problem is that the UIFe didn't land last week,  and screen shots have started being taken.
<stgraber> skaet: if you're into FFe reviews, can you look at bug 967320? ideally I'd like xcompmgr to be pulled by the next LTSP upload (scheduled for Friday)
<ubot2> Launchpad bug 967320 in xcompmgr "[FFe][MIR] Please promote xcompmgr to main for LTSP" [Undecided,New] https://launchpad.net/bugs/967320
<skaet> jbicha, ^  how far along are we with the screenshots for the docs?
<joshuahoover> skaet: i'll personally update screenshots if that would help :)
<skaet> joshuahoover, jbicha may take you up on it ;)
<skaet> (and yes it might well help)
<skaet> documentation freeze is tomorrow.
<skaet> joshuahoover, 851810 is approved as long as we can get it landed early next week.
<skaet> joshuahoover, could you take a review pass at https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, and make sure its got all the key changes that have happened in Ubuntu One captured?
<joshuahoover> skaet: yep, was doing that just a bit ago...then got distracted ;)
<skaet>  stgraber,  challenge will be getting MIR resources to look at it in time.    details in bug.
 * micahg wonders if changing the i386 default to PAE is worth release noting (or has this been hashed already)
<micahg> *default kernel
<slangasek> I would think so
<slangasek> changes in the hardware we support installing on are generally a big question; better to document that up front
 * skaet nods
<micahg> do you want a release notes task on a bug?
<jbicha> joshuahoover: we don't have any screenshots of ubuntuone in the system docs
<joshuahoover> jbicha: perfect :)
<joshuahoover> skaet: so, bug 956077 should be ok to do since we don't do screenshots of u1 in the sys docs - sound good?
<ubot2> Launchpad bug 956077 in ubuntuone-control-panel/stable-3-0 "[UIFe] Colour changes for the QT control panel" [High,Fix committed] https://launchpad.net/bugs/956077
<skaet> joshuahoover, sounds good,  thanks jbicha
<skaet> micahg,  just go into TechnicalOverview wiki page and add in some text for now.   Most of that will be transfered to formal Release Notes, next week.
<micahg> skaet: sorry, I don't think I'm the right person to do this
 * skaet still needs to scrub out old release notes from that project, so we have something we can work with next month.
<jbicha> skaet: joshuahoover: yes, updating ubuntu-one isn't a problem for Precise docs
<skaet> micahg,  ack,  I'll add a sentence after its free to edit, and we'll get apw or ogasawara to review.
<micahg> skaet: thanks
<Daviey> Riddell: are you editing the tech overview?
<stgraber> Daviey: it's the other Jonathan ;) (highvoltage)
<stgraber> Daviey: and yeah, he's still editing (we're discussing discussing some changes now in #edubuntu)
<Daviey> ok, groovy
<skaet> joshuahoover, yes.  have updated bug.
<joshuahoover> thanks
<highvoltage> stgraber: oops, yes, 10s...
<highvoltage> (I mean Daviey)
<highvoltage> Daviey: ok I'm out of it
<Daviey> ta
<skaet> Daviey,   when you're done,  let me know,  have some edits queued up.
<Daviey> skaet: Can you go first?
<skaet> Daviey,  ok.  going in now.
<skaet> Daviey, am out now.   All yours.
<Daviey> Thanks!
<stgraber> am I the only one who gets LP oopsing every time I try to report a bug?
<skaet> Thanks highvoltage, stgraber,  Edubuntu part looks good.
<stgraber> I reported it in #launchpad for now but didn't get a reply yet, tried around 10 times, get an oops every time and no bug registered (otherwise it wouldn't be too bad)
<stgraber> that's fairly annoying when doing ISO testing
<stgraber> FYI
<stgraber> 21:26 < spm> stgraber: we appear to have a partially broken rollout; fixing atm.
<stgraber> always nice to have at the middle of milestone testing...
<knome> err, does that mean rebuilding images?
<slangasek> no
<knome> good
<slangasek> that only refers to launchpad having trouble accepting bug reports
 * knome was about to get worried ;)
<knome> btw, what's with the upgrades in the iso tracker?
<knome> i mean, the upgrade tests
<stgraber> knome: what about them?
<knome> stgraber, they keep on saying "rebuilding"
<stgraber> oh right ... not sure who did that...
<knome> :)=
<stgraber> jibel: why did you disable the upgrade tests?
<stgraber> (yay for audit trail!)
<stgraber> oh no, actually the audit trail may be wrong
 * stgraber checks
<stgraber> right, not even history to find these
<stgraber> skaet: any reason to have the upgrade tests disabled?
<skaet> stgraber,  was rebuilding the images last night,  all hadn't finished before I went zzz,  oversight.
<skaet> should reflect for today's images.
<stgraber> skaet: so do we reset them all or just turn back on?
<skaet> stgraber,  reset them is best.  we do have the history.
<stgraber> I have automated test results that finished 5 minutes ago and didn't publish because they were turned off :(
 * skaet is sorry.  
<stgraber> skaet: done
<skaet> should have checked this morning on it.
<skaet> thanks for flagging knome
<knome> no problem
<stgraber> skaet: oh, just noticed that we didn't have wubi upgrades, should I remove the one I just added?
<skaet> stgraer, did the RFC go through?
<skaet> stgraber, ^
<stgraber> skaet: AFAIK we still have it on the media and it's still under discussion
<stgraber> skaet: though either way, doing upgrade testing of wubi system still seems relevant even if the installer isn't on a media
<skaet> stgraber,  probably better leave it then.
<slangasek> the upgrade doesn't refer to the CD though, does it?
<slangasek> right, what stgraber said
<Daviey> stgraber: Most of the server test cases have automated testing coverage, currently someone copies passes back to the tracker by hand.  Can you provide some guidance on how to automate this?
<Daviey> Are there apidoc's?
<stgraber> Daviey: there isn't one yet but I can give you some examples of what's currently used for the upgrade testing (and maybe some of GrueMaster's tests, not sure if he's using the API yet)
<jibel> stgraber, uh ? I didn't, I enabled them yesterday, they were marked for rebuild
<GrueMaster> stgraber: I was using it for core images, and was gearing up to use it for netboot & server arm testing.  Unfortunately, my workload has changed in recent weeks so won't be implementing it.
<stgraber> jibel: yeah, I know, I thought I had a better audit trail for these but I just had the uid of the one adding them :)
<Daviey> stgraber / GrueMaster: Just some code snippets well probably be enough :)
<stgraber> Daviey: http://paste.ubuntu.com/904637/
<stgraber> that's based on GrueMaster's code with some added comments
<GrueMaster> Yep.  Only changes I made were for product info and SSO_LOGIN stuff.
<Daviey> stgraber: the api doesn't support trying but not save()'ing?
<stgraber> Daviey: right but I could probably update the stagging server for that if you want
<Daviey> stgraber: happen to know if Desktop do it by hand still?
<Daviey> stgraber: if you have a throwaway staging server to hand, i wouldn't object :)
<stgraber> Daviey: I think they do, though jibel asked for the exact same API example a week or two ago, so maybe that changed :)
<stgraber> oh, apparently my staging canonistack instance was killed :(
<infinity> Welcome to the cloud.
<stgraber> yeah, I'll just copy my development lxc container to one of my server (you know some good old hardware in a rack ;))
<infinity> Server-hugger. :)
<infinity> (I *love* that that's being used as a "derogatory" term for IT people who are cloud-resistant... So silly)
<stgraber> ;)
<Daviey> The irony of reliance on the cloud.. Yesterday, Openstack upstream trunk was closed, because the gating process relied on cloud instances to test, their cloud provder was broke.. meaning no code could land.
<Daviey> could*
<infinity> Can't fix the cloud without the cloud?
<Daviey> yup.
<infinity> Sort of like people who can't find their glasses without their glasses, I guess.
<Daviey> Gut generally, if you are damaged by an instance going AWOL, your design is wrong IMO.
<Daviey> Plannign for a rack of real hardware going away, is identical to trusting the cloud.
<infinity> Sure, you don't "get" cloud computing if losing an instance hurts.
<infinity> On the other hand, if you only have one instance, because you're cheap, the rules change. ;)
<Daviey> Sadly, i would fall deeply in that category
<stgraber> Daviey: container is crossing the atlantic now, ETA 10 minutes for the transfer + 5 minute or so to route it an IP
<infinity> stgraber: Did you name it Titanic, to tempt fate?
<Daviey> stgraber: I thought it was faster to copy data to an ssd, and use surface mail, than Canadian interwebs.
<infinity> Daviey: Where did you get that strange notion?  We're not Australia.
<knome> stgraber, http://www.youtube.com/watch?v=saalGKY7ifU <3
<infinity> Daviey: We have the best speed/cost ratio for home users in the world, according to recent surveys.
<Daviey> infinity: Ah, cheaper, not faster.. http://tinyurl.com/bms8jjv
<stgraber> Daviey: I'd have agreed with you in the past but I now have a new and shiny 25/7 connection :)
<GrueMaster> stgraber: Is there a way to unsubscribe en mass from the iso tracker?  unsubscribing from each individual image is a bit tedious.
<infinity> Daviey: As a personal data point, I recently *downgraded* my service to 100/10, because 250/15 wasn't worth it.
<Daviey> O_o
 * micahg would love 10Mbit up
<infinity> Daviey: Also, that particular jpeg was a protest against usage based billing that didn't happen.
 * micahg has 25/2 ATM
<infinity> We may not be as awesome as South Korea's fiber-to-every-bedroom (though they do pay for the priviledge), but, like I said, we're not Australia. :P
<stgraber> Daviey: I also recently got native IPv6 giving me a nice 10 hops route to my server in Germany (native-v6 to native-v6!)
<infinity> Now, if only we could get rid of our pesky government...
<stgraber> infinity: lucky you, 25/7 is the maximum I can get here (with a decent upload) and not have quotas, without having fiber installed and pay thousand of dollars in setup fees
<stgraber> though I run most of my stuff on a server with gigabit connectivity so it's not too bad
<infinity> stgraber: QuÃ©bec's always been a backward place. ;)
<infinity> stgraber: And yeah, I run all my critical stuff on a server in San Jose with GigE.
<stgraber> infinity: I won't comment ;) I know mdeslaur and some others may be watching
<infinity> (Which seems silly, with this much bandwidth at home, but old habits die hard, and it's nice to have off-site backups)
<infinity> And by "critical stuff", I mean screen sessions with irssi in them.  Obviously.
<stgraber> infinity: to be honest, I probably would be able to get much faster internet, close to what you have if I was living in Montreal, or at least a bit closer to Montreal
<infinity> stgraber: Yeah, I'd assume Videotron offers something along these lines.
<infinity> stgraber: If not, they need to pull their socks up.
<stgraber> infinity: AFAIK the best you can get with videotron is 120/20 but with a total cap of 500GB, so completely useless for me
<stgraber> infinity: as any extra GB costs $1.5
 * knome fortunately doesn't need >500GB upload bandwidth :)
<ajmitch> stgraber: gee, poor you :P
<stgraber> I don't use "that" much, between highvoltage and I, we're just using around 800GB/month
<tumbleweed> has highvoltage explained ZA pricing to you? :)
 * ajmitch has a 20GB cap
<stgraber> tumbleweed: yeah ;)
<ajmitch> tumbleweed: I'm guessing it's even worse than NZ?
<stgraber> tumbleweed: ZA-internet being his measurement unit for internet speed and price ;)
<highvoltage> hehe
<highvoltage> we were just talking about that a few minutes ago
<knome> how come nerds are talking about upload speeds and prices
 * knome doesn't understand all this fuzz ;)
<infinity> Because we're nerds.
<highvoltage> knome: if you don't understand it, then you probably have good upload speeds and no quotas
<tumbleweed> ajmitch: probably fairly similar. 250ms to US, ~60 EUR pm for 20GB cap at 10Mbps
<stgraber> the problem I have with the 500GB cap on a 120Mb/s connection is that you can go through your quota in less than 10 hours!
<infinity> And because Daviey made disparaging comments about Canada.
<knome> highvoltage, or no need for any better for my taste :)
<ajmitch> tumbleweed: sounds about what I have
<GrueMaster> stgraber: Is there a way to unsubscribe en mass from the iso tracker? unsubscribing from each individual image is a bit tedious. (repeated)
<stgraber> GrueMaster: not yet, that page is still work-in-progress, I can remove all subscriptions for a given uid if you want though
<GrueMaster> Yep, remove mine.  Only thing I currently care for now is netboot armhf+armadaxp (and that may change soon).
<infinity> stgraber: Shaw has done something clever with caps (or, rather, is about to).  Instead of billing per GB (ew), or throttling (EW!), they're... Upgrading.
<infinity> stgraber: If you go over, they just bump you to the next highest plan for the month (including the speed).
<infinity> stgraber: First time's free.  If you do it two months in a row, you pay.
<stgraber> qatracker=> DELETE FROM qatracker_user_subscription WHERE userid=26110;
<stgraber> DELETE 40
<GrueMaster> infinity: That's just sick.  How non-capitalist of them.
<stgraber> GrueMaster: ^
<GrueMaster> stgraber: Thanks.
<infinity> stgraber: I guess I'll see how that plays out.  But it's curious to do service improvement instead of degradation (I lived in Australia for far too long with bandwidth-throttling on caps)
<stgraber> infinity: that actually sounds nice, though videotron/bell are way too evil to do that, it's a lot more fun making you pay every single GB over your cap :)
<infinity> stgraber: Yeah.  And worst case scenario here would be hitting their top plan (250/15/unlimited), which is only 130/mo, so probably way less than people are hitthing with usage-based-billing.
<infinity> stgraber: But the cooler thing (I think) is that people who don't really care about speed THAT much can just get the cheapest plan and have it autoupgrade if they miscalculated.
<stgraber> infinity: yeah, my guestimate was that I'd get a $950 bill from videotron with their move from unlimited to 500GB quota for business connections
<stgraber> infinity: (instead of $80 that's)
<stgraber> instead I moved to teksavvy a few weeks ago, for now it works fine and they are actually faster, have native v6 and offer no-cap plans
<stgraber> Daviey: http://iso.qa.dev.stgraber.org/
<stgraber> Daviey: sorry for the delay, forgot that now that stgraber.org is signed by DNSSEC it takes me a bit longer to update ;)
<Daviey> stgraber: not yet working here.. i'll check in at a decent time.. thanks!
<infinity> WFM.
<utlemming> straber: can you add http://cloud-images.ubuntu.com/precise/20120328/ to the ISO tracker?
<phillw> stgraber: are you in USA?
<stgraber> phillw: canada
<phillw> stgraber: I can ask a friend of mine who works for one of the major providers over in USA/CA to see if he can get a deal for you? He does the installs, so gets 25% off for friends.
<phillw> utlemming: you really need to work on a wiki page for http://cloud-images.ubuntu.com/precise/20120328/ I know cloud exists, but.....
<utlemming> phillw: you mean http://cloud.ubuntu.com/docs/ ?
<utlemming> cloud.ubuntu.com is a great place to start
 * phillw :-X
 * skaet wonders if who's cleaning out the unapproved proposed queue, and thanks them. 
<phillw> how many respins do we expect? http://pad.ubuntu.com/ubuntu-release says none. Can I announce that the RC for beta 2 on lubuntu is a "GO"?
<phillw> skaet: ^^
<skaet> phillw, not expecting to do another respin at this point.    Still gathering data from the testing though.
<skaet> So far,  all we've seen we can release note (or not release the image).
<slangasek> skaet: the only removal from unapproved I see is my own reject of a verification-failed SRU that I've just reuploaded... :)
<phillw> skaet: when is the cut off time? I do not want to to a release note before you are all happy.
<phillw> unlike some other 'news' sites.
<skaet> phillw,  thank you.  :)   release decision time will be happening tomorrow at some point,  release is official when the announce goes out, so coordinate to that.
<skaet> We'll be getting the QA reports in,  and talking to the various teams about which images they have reservations about, what looks solid.   Then figure out what's safe to ship.
<skaet> If we don't end up respinning,  likely around end of day for Europe.
<skaet> phillw,   please make sure all the bugs you don't want folks to stumble into are documented under Lubuntu in the known issues section.    I'll be doing a pass as well.
<skaet> but more contributing to it,  better its going to get.
<phillw> skaet: but dooooo, pleeaaseee let me know if lubuntu has passed for beta 2? The lads are really chewing at my neack!
<phillw> s/neack/neck
<skaet> phillw,  I'll ping you as soon as soon as I know its all looking good.   Its fairly likely that the images you have right now will be the ones to go out with.
<skaet> :)
#ubuntu-release 2012-03-29
<phillw> skaet: I know the bugs were logged. but as the respins go on, they get dropped off. Where are they all kept?
<skaet> where it says /builds on the iso tracker put in /history
<skaet> then you should see them all.
<phillw> skaet: an oops ... PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: "history" LINE 4: WHERE (qatracker_build.id = 'history') ^: SELECT qatracker_build.note AS value FROM {qatracker_build} qatracker_build WHERE (qatracker_build.id = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => history ) inÂ qatracker_block_noticeboard()Â (lineÂ 81Â ofÂ /srv/drupal-qa-tracker/www/bzr/new/modul
<phillw> can you give me a clean link for them?
<skaet> stgraber, ^
<skaet> phillw,  will do.
<skaet> http://iso.qa.ubuntu.com/qatracker/milestones/210/history
<skaet> phillw,  who's been doing the amd64+mac tests?   jibel may want to contact them in the morning to see if they're seeing a problem he is on his ubuntu tests.
<phillw> skaet: Mars cleared the ppc error, I'm guessing it was a dodgy download that snook through the lower level error checking.
<skaet> ok.  what about the intel macs?
<phillw> skaet: do feel free to call him, but while he is really 100% on lubuntu release.... the offer of cookies, chocolate may help :)
<phillw> skaet: may I speak freely?
<phillw> skaet: or should this be done in PM?
<skaet> PM if its sensitive people wise,  otherwise speak freely.
<infinity> If "speaking freely" won't violate the code of conduct, go to town.
<phillw> skaet: we do not have a log bot. I always adhere to CoC
<skaet> :)
<phillw> skaet: I am, after all a ubuntu member, I just do not use that cloak.
<skaet> phillw,  comment on CoC was from infinity ;)
<phillw> Long story, cut short .... xubuntu was the best option for ppc, then it got bloated & needed lots of work arounds.
<phillw> when it was mentioned that lubuntu "may" do a ppc release, the ppc people were all over us
<micahg> phillw: xubuntu would add PPC back if there were committed testers
<phillw> we said that to so required testers.
<phillw> micahg: you seem to forget Charlie handing in his resignatation?
<micahg> phillw: charlie never tested PPC
<phillw> micahg: I am not currently chatting about xubuntu? I am chatting about ppc / mac testers?
<phillw> please do let me finish before you start.
<phillw> skaet: I am finished. I am an admin, catch me on PM anytime
<skaet> phillw,  very much appreciate getting the ppc testing happening this release.    Was curious who was doing the intel mac testing right now,  since jibel has seen an issue with ubuntu on intel mac, and would like someone to compare notes with.
 * skaet looked at your bugs on those ports and didn't see anything like he was worrying about,  so just trying to figure out if its an ubuntu specific problem or wider problem.
<phillw> skaet: Life is real complicated for me, Julien gave a way to test for us lubuntu people at https://wiki.ubuntu.com/Lubuntu/Testing/PPC#How_to_test_on_any_architectures_.28using_qemu.29
<stgraber> skaet: the error message above is actually right 'history' isn't an integer ;) I guess it wouldn't hurt to check the input before running the select against the DB though :)
<skaet> stgraber,  :)
<skaet> phillw,  yes,  that does look complicated for ppc macs.   Who is testing intel macs and are they using the same proceedure?
<skaet> phillw, or are they working on bare metal.
<slangasek> you're not going to get a useful test of amd64+mac under qemu.
<slangasek> (qemu doesn't implement uefi, as far as I'm aware)
<slangasek> I would also question whether it's wise to use qemu for validation of ports images, since the entire point of validating the ports images separately is to pick up on hardware-specific issues not caught in the x86 testing, and qemu gives you a very narrow view of "hardware"
<infinity> slangasek: They have bare metal testers for PPC as well.
<slangasek> in which case I have no objection
<infinity> slangasek: Those instructions are more of a "for other who want to add more test results", AIUI.
<infinity> s/other/others/
<infinity> slangasek: But the guy filing lubuntu/ppc bugs is doing so on real hardware.
<slangasek> ok, good :)
<infinity> Even burning actual coasters to do so.  *shiver*
 * phillw are the http://iso.qa.ubuntu.com/qatracker/milestones/210/builds for lubuntu 'good to go' ? As in can I announce them as our beta 2 officially instead of the likes of 'certain' threads announcing while we are still testing?
<slangasek> phillw: it's inadvisable to announce until the testing is all done and the images are published as a beta - which has not been done yet
<slangasek> phillw: and by "all done", I mean done for all images, not just lubuntu ones; testing on another flavor could yet turn up a showstopper issue that lubuntu would want to consider respinning for even if it wasn't caught in your own testing
<slangasek> and there's still the question of whether amd64+mac is actually releasable despite having been signed off for lubuntu, since there's an as-yet-unconfirmed report that it corrupts partition tables
<phillw> slangasek: if you need Lars to test on another system, do feel free to give him a poke in the ribs. Vocal he may be, but he has access to kit to test things on.
<slangasek> how do we get ahold of Lars if ribs need poked?
<phillw> slangasek: https://launchpad.net/~lubuntu-qa
<phillw> let me just dig up his email
<phillw> slangasek: P okay?
<phillw> PM
<slangasek> sure
<phillw> slangasek: from zero to where we are, does IMHO, inforce the lubuntu commitment to lower spec machines.
<phillw> our reports back just generally, is that ubuntu have made a massive difference to those guys. We have testers, you are the guys who make it happen. for that, I know I can speak on behalf of them all..... THANK YOU.
<infinity> Gah, who just let all that stuff into -release?
<infinity> Or were those all rejects?
<infinity> slangasek, skaet: ?
<stgraber> infinity: my e-mails says they were accepted
<skaet> infinity,  not me
<skaet> stgraber,  is it possible to change removed in the bot message to accept or reject?
<infinity> skaet: Not easily.
<skaet> ok.  just an idea.
<infinity> skaet: Requires scanning DONE and REJECTED which is hugely time-consuming and vile.
<stgraber> skaet: what he said :) hopefully the API for the audit changes will make that easier
<infinity> (I suppose one could also blindly hit the package/version record, and if it doesn't exist, assume reject)
<infinity> stgraber: ^
<stgraber> infinity: true, I was just thinking about that actually ;) if the source is "published" (as far as LP knows at least) and the package was removed from the queue, that should mean it's been accepted
<stgraber> I guess I can implement that and we'll see how well that works
<infinity> Well, if the source exists at all in a !new state, it's accepted (or better).
<infinity> Since unapproved sources don't have source records yet.
<infinity> Actually, I guess new doesn't either.
<infinity> Only new binaries do.
<stgraber> actually, it looks like I can keep the URL of a build record then query for its status when it's removed, that should tell me if it was rejected or not without scanning the queue
<infinity> stgraber: I suspect "published" won't catch the "just accepted" state (which can last up to 30m), but I haven't looked at the API for SPRs.
<infinity> But for unapproved, if there's a source record at all, that should mean "accepted".  I think.
<infinity> Anyhow.  Whoever did the above just leaked in some gnome transition bits and other stuff.  *sigh*
<stgraber> please wait on that bcfg2 upload
<stgraber> I'll use it to test the bot ;)
<infinity> Though, maybe it was all universe.
<skaet> hmm... hasn't solved the mystery of who just let all that code into -release.
 * phillw not guilty... 
<stgraber> infinity: can you reject bcfg2? it's one of my uploads, I'll re-upload after that so we can test "approved" :)
<infinity> stgraber: I can just pull it out of rejected after I do, no need to reupload.
<stgraber> infinity: ah right, forgot you could do that
<infinity> Oh, except then we won't be able to test the unapproved->accepted route.
<infinity> So, reupload. :P
<stgraber> yay!
<stgraber> uploading now
<stgraber> the current code is: if not "Rejected" => "accepted"
<stgraber> so as the above worked, accepting should work too
<infinity> stgraber: As in, if source record exists -> accepted; else -> rejected?
<infinity> Something like that should be close enough to the truth for most cases we care about anyway.
<stgraber> nope, I'm actually storing the URL of the build record, then pulling an updated version of the object when I noticed it dropped out of the queue
<infinity> "build record"?
<stgraber> that object happens to have a status property
<infinity> There are no build records for unaccpted source...
<stgraber> s/build record/package upload/
<stgraber> https://launchpad.net/+apidoc/1.0.html#package_upload <-- that stuff
<infinity> Ah-ha.
<infinity> Much more elegant.
<skaet> looks like that worked.   ;)
<vanhoof> thanks skaet :)
<vanhoof> >
 * skaet did those ^ on request from vanhoof.
<vanhoof> >
<infinity> vanhoof: You poked me?
<stgraber> skaet: we haven't seen any "accepted" yet :)
<vanhoof> infinity: same question
<vanhoof> infinity: last minute drama, and a decision was made to yank them
<infinity> vanhoof: Oh, was that all of them, not just the older ones?
<vanhoof> infinity: that all of em
<infinity> vanhoof: I guess it's a good thing I didn't get around to reviewing them for jani yet. :P
<infinity> queuebot: Wake up and poll already.
<infinity> \o/
<stgraber> wow, that worked!
<infinity> stgraber: Magic.
<stgraber> now looking into what happened with mosh
<stgraber> that's if LP stops timing out when trying to look at the records in the Done queue :)
<stgraber> right, so the problem is indeed that they are binary packages but not detected as such...
<infinity> stgraber: Was that perhaps fallout from trying to handle the binary+translations case?
<stgraber> could be, the check for binary/source was written before I actually add access to pkg.arch ;) I'm doing a test run now where I won't do silly hacks to detect source vs binary
<stgraber> and instead simply check if pkg.arch == "source" which should be a bit more reliable
 * infinity nods.
<stgraber> infinity: well, what you currently see in #stgraber-release is actually a "debug" version where the versio number in "New: source" packages is replaced by the architecture
<stgraber> ok, looks like all source packages in New have "source" as their architecture, good
<slangasek> infinity: accepts> wasn't me
<infinity> slangasek: Great.  We have a mystery queue manipulator.
<infinity> stgraber: Also, when a package is accepted, can the bot /msg every member of ~ubuntu-archive and ask "was that you, fess up, was it you?!"
<infinity> stgraber: Thanks in advance.
<stgraber> infinity: hehe, should actually be easy to do ;)
<slangasek> infinity: though AFAICS, the only one that was in main was mousetweaks, which went to -proposed; so whoever's doing it hasn't actually broken anything
<stgraber> infinity: I can query the list of team members on LP, then their IRC nick and ask each of them, then we'll have an "audit trail" (assuming nobody lies and everyone replies ;))
<infinity> slangasek: Yeah, I came to a similar conclusion later, but it still would have been nice to have someone annotate the accept spam.
<slangasek> stgraber: we'll also see a sudden spate of retirements from ubuntu-archive, I trust :P
<infinity> stgraber: Perfect!
<stgraber> slangasek: :)
<infinity> slangasek: That might not be a bad thing either.  Probably should thin the herd a bit.
<slangasek> I'd rather not
<slangasek> the NEW queue is long enough without reducing manpower :)
<stgraber> ^ that's with this morning's bug fixed and some better handling of syncs in the New queue too
<stgraber> (as LP also considers 'sync' as a valid architecture apparently)
<slangasek> stgraber: is there a bzr branch for the queue bot yet?
<stgraber> slangasek: lp:~stgraber/+junk/queuebot
<slangasek> ok :)
<stgraber> slangasek: might move to ~ubuntu-core-dev or similar, I guess ~ubuntu-release or ~ubuntu-archive would technically be better but I don't have access to these
<slangasek> I think ubuntu-core-dev would be fine anyway
<slangasek> not like being able to edit the bot confers any superpowers that should be tied to release :)
<stgraber> well, you can confuse the archive admins and release admins quite a bit by messing in the code, but nothing worse than that ;)
<infinity> stgraber: You're not in -release?
<infinity> But yeah, -core-dev seems fine.
<stgraber> infinity: nope, might poke skaet about it at some point though :)
<stgraber> infinity: I'm the team owner though (through coredev) ;)
<stgraber> s/coredev/TB/g
<infinity> Yeah, I'm jealous of your horsey.
<skaet> stgraber,  if you want to be in -release,  am happy to put it forward.   You've done alot to make our lives easier between the ISO tracker and this queue bot.   Anytime.
<infinity> Can we make him our mascot?
<stgraber> so, to reflect our private discussion: yeah, I'd be happy to join the release team
<stgraber> slangasek: queuebot moved to https://code.launchpad.net/~ubuntu-core-dev/+junk/queuebot
<infinity> stgraber: Probably doesn't need the junk...
<stgraber> don't we have to link a branch to a project?
<infinity> We could create a project for it.
<infinity> Then I could file bugs instead of pestering you on IRC!
<infinity> Progress.
<skaet> :)
<stgraber> not sure, sounds like a slower process causing more interruptions for me (unless you don't say anything on IRC ;))
<infinity> stgraber: No, no.  I'd write a second bot that polls lp/queuebot/bugs and pings you on IRC when they're filed.  Duh.
<stgraber> right so queuebot would crash, crashbot would see it, file a bug, then nagbot would post the bug number here for ubot2 to post the LP description?
<stgraber> at this rate we'll soon have more bots than human in the channel
<infinity> There's probably a critical mass of bots we can reach where we obsolete ourselves.
<infinity> Please don't write sarcasmbot, I'll be out of a job.
<stgraber> ;)
 * stgraber adds to the TODO
<slangasek> the blueprint approval for that one should be fun
 * skaet giggles
<stgraber> slangasek: are you planning a plymouth upload shortly after freeze? I just noticed bug 904622 (the original, not sure why it was marked as duplicate) on one of my servers using the text theme
<ubot2> Launchpad bug 904622 in unity-greeter "Still says 11.10 on precise on boot (dup-of: 892394)" [Low,Fix committed] https://launchpad.net/bugs/904622
<ubot2> Launchpad bug 892394 in unity-greeter "Greeter logo needs to be updated for 12.04" [Medium,Fix released] https://launchpad.net/bugs/892394
<stgraber> I started looking to fix it and noticed you already figured it out and there are changes pending in the branch for a while now
<stgraber> including what looks like a fix for the missing "chvt 1" that was mentioned earlier today
<slangasek> stgraber: I'm planning a plymouth upload, yes, though probably only once the chvt thing is *properly* fixed
<slangasek> the 'chvt 1' is almost certainly wrong and should NOT be uploaded
<stgraber> yeah, that's definitely wrong. We only want the chvt if nothing will show up on vt7, which definitely sounds a lot easier than it really is to implement
<RAOF> slangasek: If you're touching plymouth, can I bring https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/939283 to your attention?
<ubot2> Launchpad bug 939283 in plymouth "[hybrid-gfx] Blank screen on boot due to failure to follow primary framebuffer" [High,New]
<slangasek> I think I have the crux of it, but I need to make sure we're entirely race-free
<slangasek> RAOF: I'm aware of the bug, but I have no good solution for it
<slangasek> the difficulty is that plymouth starts before we even know we're on a hybrid system, and has no good way to either wait, or switch cards when it turns out there's a better one
<stgraber> slangasek: ideally we'd ask upstart if any job said it could emit "login-session-start" if we don't get any back, we'd emit "no-login-manager" and have that used to stop plymouth, sadly even though upstart knows what events each jobs can emit I don't think it exposes it yet
<stgraber> slangasek: actually "initctl show-config | grep login-session-start" should work
<stgraber> initctl show-config | grep -q login-session-start || echo "chvt 1"    <= that should do it, assuming all login managers actually emit that (I just looked at lightdm)
<stgraber> or more specifically explictly say they might emit it
<stgraber> I know that the above won't work with LTSP but if you go with something like that, it's trivial to fix in our existing upstart job
<RAOF> slangasek: Does/can plymouth monitor udev events?  You could watch for fb device creation, correlate that with the associated DRM device, and switch fbs iff the new fb is associated with a drm device with attached outputs and is currently on a fb associated with a drm device with no attached outputs.
<RAOF> Or, now that I think of it, you could just bring it up on each and every output, like the drm backend already does.
<slangasek> stgraber: I think that would be papering over the real issue; I'd like to take a little more time to get it right in the plymouth code
<slangasek> stgraber: but if I don't pull it off, that does sound like a viable fallback, thanks
<slangasek> RAOF: there's no monitoring of udev events, no
<RAOF> That shouldn't be too hard to add?  I'm blissfully unfamiliar with the plymouth code, though.
<slangasek> I don't think this would be a safe area to make changes to post-beta, sorry :/
<slangasek> regression-testing plymouth is effectively impossible at this point
<kees> release folks, I'm not sure, but this seems like a rather bad behavior for the LTS openssl: bug 965371
<ubot2> Launchpad bug 965371 in openssl "HTTPS requests fail on some sites on Ubuntu 12.04" [Undecided,Confirmed] https://launchpad.net/bugs/965371
<slangasek> kees: do you know why TLSv1 is disabled by default?  I would assume that's because it's insecure?
<slangasek> RAOF: not that it's a fix for your bug, but I just saw your followup and I wonder if double-tapping 'Esc' brings the splash screen up for you?
<RAOF> slangasek: That's a good question; I'll try it next time it triggersl.
<kees> slangasek: TLSv1 is slightly less secure than 1.3, but none of the browsers are using it yet.
<kees> which is why no one has noticed that paypal can't talk to a 1.3 tool
<kees> the changelog for openssl 1.0.1 seems to indicate that they fixed autodetection, but it's clearly a lie. :P
<kees> they turned on 1.3-by-default in the 1.0.0 release at some point
<slangasek> ok
<slangasek> triaged and assigned for follow-up
<infinity> stgraber: Hrm.  queuebot just helpfully told us about 18-hour-old uploads...
<infinity> stgraber: Oh, no.  Nevermind.  It really is in the queue twice.
 * infinity double-takes.
<infinity> How... Is that in the queue twice?
<micahg> you can upload multiple times to unapproved
<infinity> micahg: With the same version?
<micahg> yep
<infinity> That seems broken.
<infinity> The only queue without constraints should be rejected.
<micahg> would make it easier to detect collisions :)
<infinity> Oh well, I'll reject the older one.
 * skaet --> zzz
<pitti> Good morning
<infinity> pitti: We made some improvements to the bot today.  Enjoy.
<pitti> looking forward to trying them out :) I have some -proposed stuff to accept
<infinity> pitti: Well, not sure what was landed yesterday and what was today, but it now knows unapproved versus new, displays dists and pocket, knows source versus binary, and the most important part, now understand how something was removed (reject or accept).
<pitti> hm, at this point we certainly don't consider respinning server again?
<infinity> pitti: Oh, and announces images being posted to the tracker.
<pitti> reject vs accept> yay!
<pitti> very helpful indeed
<pitti> saves the "^ don't panic, it was a reject" followups
 * infinity nods.
<infinity> Oh, and stgraber dumped it in lp:~ubuntu-core-dev/+junk/queuebot, if you feel the urge to peruse and suggest other improvements.
<infinity> Soon, the bot will do our jobs for us.
<pitti> can it point out bugs in debdiffs yet?
<infinity> Soon.
<pitti> I'll do the pre-publishing now, so that it has some time to mirror around the world
<pitti> cjwatson, skaet ^
<pitti> ah, we don't put Kubuntu on release.u.c. any more
<pitti> cjwatson, skaet: pre-publishing done
<pitti> cjwatson, slangasek: FYI:
<pitti> bzr commit -m 'sru-release: Add --release/-r option for copying to release pocket, for staging uploads in development release'
<infinity> pitti: \o/
<infinity> pitti: Both to the pre-publishing and the sru-release change.
<pitti> working on making the SRU report show non-DONE builds, to see what can't e copied yet
<pitti> e -> be
<pitti> LibO will be a fine test for this for the next two days
<infinity> Heh, yeah.
<infinity> Someone really needs to talk to them about splitting it out into modular bits.
<infinity> (Which, ironically, it mostly is in the source anyway, they just need to release it that way)
<pitti> in fact they just merged their individual component gits back into one
<infinity> Meh
<infinity> It's insanity, even on x86.
<infinity> Fixing a small bug should be a short build and a small download away, not a day of build time and pushing 150MB to users.
<micahg> infinity: it's almost as large as the kernel (~12M lines of code)
<infinity> micahg: Yeah, but the difference is that no kernel build uses all of the source.
<infinity> Also, the kernel workd.
<infinity> s/workd/works/
<infinity> pitti: I kinda wonder who I'd need to talk to about doing componentised distribution and releases without being laughed at.
<pitti> that's a question for Sweetshark
<infinity> pitti: Cause if the argument is just "but, but, Windows...", I'd seriously commit to spending a weekend or two writing them a nice package installer / manager / updater for Win32.
<infinity> (I'm sure my parents would love it if Office suite updates were 5MB instead of 150...
<infinity> )
<cjwatson> slangasek: you mentioned an unconfirmed report that amd64+mac corrupts partition tables; do you have a bug number or anything for that?
<jibel> cjwatson, not a corrupted partition table but after installing ubuntu on a Mac, none of the MacOS disk tools can manage the partitions. They cannot erase, resize, ...
<jibel> cjwatson, I'm wiping the disk and will redo the installation
<cjwatson> curious, I don't know what their constraints are exactly
<Riddell> what time are we expecting to release today?
<Riddell> "Thu Mar 1 22:21:43" says the beta 1 announce, no rush then :)
<jibel> for example, resize (to a smaller) or erase partition reports: "Error -5344 Mediakit reports not enough space on device for requested operation" or "cannot update partition map"
<jibel> it may be a hardware issue, there are fsck errors on every boot.
<jibel> "unrecognized file system" is another error but the filesystem type is JHFS+
<cjwatson> I probably won't be able to investigate that; sounds like the sort of thing you really need to be in front of ...
<tumbleweed> err whoops, that ubuntu-dev-tools upload can be rejected. It appears bdrung already synced it, but the publisher hasn't run since then
<tumbleweed> oh, 3 mins before
 * bdrung was faster than tumbleweed. :)
<pitti> tumbleweed: that was a sync
<pitti> tumbleweed: oh, you mean you did an upload just now?
<tumbleweed> I just did a second sync
<pitti> right, rejected
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseBeta2TestReport
<jelmer> hi
<jelmer> I'm going to update the tevent package from upstream release 0.9.14 to 0.9.15 by syncing 0.9.15-2 from unstable
<jelmer> 0.9.15 is a bugfix only release, though it's got a fair amount of noise because it unpacks waf upstream and has some changes to bundled libraries that aren't used by the package.
<skaet> good morning
<stgraber> good morning skaet
<skaet> :)
<skaet> pitti,  cjwatson - based on the test report,  am thinking Ubuntu amd64+mac and ppc probably shouldn't ship this time around.
<skaet> thoughts?
<pitti> skaet: good morning
<skaet> :)
<cjwatson> The notion of coverage for amd64+mac is pretty bogus.  Most of the amd64 tests apply equally to it; making sure that it builds and installs should be enough to carry over the rest of the coverage.
<pitti> skaet: no strong opinion on that, but amd64+mac seems to at least work
<pitti> skaet: and it's by and large identical to teh amd64 one, so "it boots, it works" comes pretty close IMHO
<pitti> heh, yes, what cjwatson says
<skaet> pitti,  worry point is that jibel can't get behaviour post install on his hardware (partition map table)
<skaet> cjwatson,   tests should probably be edited then for amd64+mac to be just those for that configuration, so they aren't so bogus.
<pitti> skaet: as we have only one test on ppc, and it's failed, ok with not releasing
<skaet> jibel,  ubuntu core (armel + armhf) - who's testing?  any results?
<jibel> pitti, on Mac I did I installation, after this installation I couldn't do any operation with MacOS disk utils and had to reformat the machine (which took a while from the Net) I'm restesting it to check if it's a problem with the hardware.
<cjwatson> Did you have the same problem (or know whether you did) with previous versions?
<cjwatson> i.e. is this a regression?
<stgraber> hmm, wondering if "disabled" would be better than "marked for re-build"
<skaet> superm1 - not seeing any testing on the Mythbuntu images,  any testing going to happen in next couple of hours?
<skaet> utlemming,   how do the cloud images look?
 * skaet not seeing them on the tracker.
<skaet> ogra_, infinity,  any testing of the ac100 or mx5 images?
<ogra_> i tested yesterday
<skaet> ogra_,  sorry - misread a line.
<skaet> appologies.
<ogra_> and noted it on the tracker
<ogra_> ah, k
<ogra_> infinity wanted to do mx5
<skaet> thanks ogra_
<sladen> skaet: the wallpapers have finally turned up.  Should I play with the compression and rush them up for tonight, or hang back?
<skaet> sladen,  play with compression and aim for tonight's build.
<sladen> skaet: (and yes, still waiting on Otto to upload the default wallpaper, but it has now been decided)
<sladen> skaet: okay-dokey
<skaet> stgraber,  yeah, at this stage a separate button maybe to indicate "don't ship"  might be appropriate - and then mark it disabled.   Usually it is rebuilding.
<utlemming> skaet: the cloud images look fine
<utlemming> skaet: I did ask last night to have them added to the tracker
<utlemming> so....can I have http://cloud-images.ubuntu.com/precise/20120328/ added to the tracker?
<stgraber> utlemming: yep, doing that now
<utlemming> stgraber: thank you kindly :)
<jibel> cjwatson, I don't know, it is a new machine and 1rst time ubuntu is installed on it
<stgraber> utlemming: done
<utlemming> stgraber: much obligded
<skaet> thanks utlemming
<cjwatson> jibel: There have been some partitioning changes recently-ish (parted 2.3-8ubuntu4).  But it's also quite possible that this has always been broken.  If you have time, I think it would be worth trying e.g. oneiric for comparison.
<jibel> cjwatson, ok, will do.
<skaet> scott-work,  ubuntu-studio looks like it had pretty good testing earlier in the week.   you comfortable no regressions with the current images and they should go out?
<skaet> Riddell,  ScottK - not seeing much testing on your images in the history or current.   Are they safe to release?
<skaet> s/your/Kubuntu/
<Riddell> skaet: yes I'm behind in updating the iso tracker
<Riddell> but no problems so far
<Riddell> skaet: any relase time in mind?
<skaet> Riddell,  ok,   please update the tracker.
<skaet> Riddell,   soon as all the data is gathered,  so we know what's safe to ship.  :)
<skaet> (yes, you're on critical path right now ;) )
<slangasek> skaet: if jibel's testing shows that this mac partitioning tool issue is a pre-existing bug, are you happy to release amd64+mac with beta-2?
<Riddell> ok I need to get back to a real computer to update the tracker this one is too fiddly for that
<scott-work> skaet: i'll be honest, i'm not sure currently, the last image didn't get much testing and i believe we were getting a new kernel (plus luke and alessio were making some adjustments as well)
<scott-work> skaet: can we have at least until this evening to make one (or several) last tests?
 * scott-work does acknowlege the past testing were very favourable, but is mainly worried about the new kernel
<skaet> scott-work,  understood.   we'll likely release before this evening,   but get the results you can, and I'll ping you later.   Problem is coordinating with other time zones.
<scott-work> skaet: ack'd
<scott-work> skaet:  one team member is progressing with very particular tests on the kernel, i would expect to have answers within a few hours
<skaet> scott-work,  :)  that should work.
<astraljava> skaet: That one team member would be me, and with that said, I'd want to hear how much time I have on Xubuntu tests, still, too. :)
<skaet> slangasek.  not sure.    lubuntu did quite a bit of testing of amd64+mac configs on their image and didn't report issues,  but don't want to muck with disk corruption issues for users with a beta either.
<slangasek> skaet: as cjwatson says, this may be a definition of "corruption" that only applies to the OS X partitioning tools
<slangasek> i.e., no runtime impact and no risk of data loss
<cjwatson> skaet: This is why I want to know if it's a regression from oneiric; if we released 11.10 with the same thing, then ...
<skaet> slangasek, cjwatson, understood, and yes that does remove risk.   Other challenge is that they also just don't have much testing on the Ubuntu side, but there is the overlap with amd64 images, so....
<skaet> am seriously on the fence on this one.   waiting more data.
<skaet> Daviey,  TechnicalOverview - server's still looking a bit bare on content,   ETA for additions?
<Daviey> skaet: That was all i was going to ship TBH, but i can elaborate
<utlemming> skaet: cloud images are good to go
<skaet> thanks utlemming
<jibel> another installation of Precise is successful, and MacOS can still manage its partitions. I reformatted the disk, reinstalled MacOS and installed Ubuntu alongside.
<pitti> skaet: do you want to wait with the publishing of the images still, or should we go ahead with this now?
<pitti> skaet: also, WDYT about lifting the freeze now?
<pitti> cjwatson: did you already run cron.src? if not, I can start it now
<jibel> then I wiped Ubuntu partitions with MacOS tools and everything seems to be working correctly
<slangasek> jibel: identical parameters for the partitioning at every stage?
<slangasek> (bearing in mind that if there /is/ a bug, it might be related to precise partition sizes / offsets...)
<skaet> pitti,  now that we've heard from the cloud side,  we'll be going with the images we have.   Challenge is which to publish and not.
<cjwatson> pitti: oh, no, I didn't, please do
<Riddell> kubuntu is just short of wubi testers
<skaet> pitti,  so am fine about lifting freeze.   Just don't know which image we'll ship.
<pitti> skaet: "which image"?
<pitti> cjwatson: running
<skaet> ubuntu core armhf and armel - no results on tracker (current or history)
<pitti> skaet: I pre-published the current ubuntu desktop/alternates/servers this morning
<pitti> ah
<pitti> these don't get pre-published, so *phew*
 * ogra_ votes for an image of a kitten 
<ogra_> they always get good reception
<ogra_> :P
<jibel> slangasek, yes, I resized the hfs partition to 250GB leaving 500G free space + an EFI and a recovery partition and selected 'Install alongside' in Ubiquity
<skaet> ogra_, hmm,  don't want to be refered to as a kitten killers please.  ;)
<cjwatson> hmm, any of my recent changes ought to have been entirely deterministic
<skaet> jibel, was that on oneiric then?   so we have a regression?   or on precise (and hence good to ship).
<jibel> skaet, on Precise
<pitti> cjwatson: any reservations about lifting freeze now?
<skaet> pitti,   OEM has taken their snapshot as well, so they're fine with opening it.
<cjwatson> pitti: I'm fine with it
<pitti> ok, doing then
<cjwatson> so -proposed will shut again for a bit ;-)
<skaet> :)
<cjwatson> however my branch to open it all the time is approved
<superm1> skaet: checking with team what's up with the testing situation
<skaet> thanks superm1
<skaet> pitti,  cjwatson,   would like to keep the actual archive in pre-release freeze though (like we did in Oneiric).
 * skaet likes the queue bot.
<pitti> skaet: err, too late, I'm afraid; that's what I just asked about?
<skaet> pitti,  I though you were asking about letting the packages that had built up get added in.
<skaet> sorry
<pitti> skaet: well, both really
<pitti> skaet: we can certainly ask IS to freeze it again, but do we really want to review everythign for a whole month?
<skaet> pitti,  given its an LTS,  and there's some area of high churn,   it seems prudent.
<pitti> I'll also copy the installable bits from -proposed
<Laney> we used to freeze for release at RC freeze
<skaet> Laney,  in Oneiric we just left it freeze.
<skaet> after Beta 2
<skaet> ScottK,  ^  thoughts?
<Laney> i.e. two weeks before release
<pitti> I also copy the installable bits from -proposed to release
<Riddell> two weeks seems a sensible time for final freeze, but isn't that scheduled?
<skaet> Laney,  Riddell,  that's too late,  I'd like the release Candidate to actually have a realistic chance of shipping this time.
<Riddell> yes April 12th
<Riddell> we don't have a release candidate scheduled
<skaet> Riddell,  we'll be putting out the image the Thursday before.   (candidate week concept we discussed at UDS).
<Riddell> so that's April 19th  ?
<skaet> yes,  final Freeze is April 12,  then only bugs requested by release team.
<Laney> what do you want between now and then?
<skaet> before that we certainly want bug fixes,  but don't want regressions
<Laney> in terms of uploads/accepts
<pitti> well, we never want regressions :)
<skaet> and bad system interactions....
<skaet> some fixes may be too risky,  libraries, kernel as things get closer to final freeze.
<Riddell> I expect to upload qt 4.8.1 and kde sc 4.8.1
<Riddell> no kde sc 4.8.2
<skaet> Riddell,  when?
<Riddell> toot sweet
<Riddell> qt is out now, kde sc on monday
<skaet> Riddell, no issues with it going in if Kubuntu and Edubuntu both want it.
<Riddell> stgraber: what say you?
 * skaet figures it still has time shake out at system level.
<stgraber> Riddell: shouldn't be a problem for us, we really only use kdeedu
<pitti> GrueMaster, ogra_, skaet: should we publish the armhf+omap4 images? They look like all fail in the iso tracker
<GrueMaster> Ask the person that marked them as fail.  I'm no longer testing images.
<pitti> ah, ok
<pitti> pgraner and Riddell did apparently
<skaet> pgraner, ^ comments on if armhf+omap4 safe to publish,   looks like not per the tracker.
<stgraber> knome: did you push your changes to lp:ubiquity-slideshow-ubuntu? I'm ready for the upload now
<Riddell> pitti: kubuntu works for me bug with a bug in the graphics driver, ubuntu desktop doesn't but only because the bug means I get it at 640x480 and ubiquity gtk doesn't work at that
<pitti> skaet: I'm not sure whether we ever published mx5
<Riddell> I don't know what pgraner's beastie iss
<pgraner> skaet, yes it is, its harmless and dosen't affect much
<skaet> pitti,  we did publish mx5 before.
<skaet> pgraner,  thanks.   pitti,  which specific one armhf+omap4 are you refering to Ubuntu,  Ubuntu Core or Ubuntu Server?
<pitti> skaet: desktop
<pgraner> pitti, desktop is fine to ship
<pitti> core armel and armhf weren't tested at all
<pitti> and server looks fine
<skaet> pgraner,  ubuntu core.
<skaet> ?
<pgraner> skaet, we don't have anyone testing them
<ScottK> skaet: I've been offline most of the last 24 hours, so I'm OK with whatever.
<skaet> pgraner, we won't ship them then since they haven't been tested.
<skaet> pitti, ubuntu core armel, armhf won't go out with beta 2,  please disable.
<pitti> done
<skaet> thanks pitti
<pitti> skaet, Riddell: kubuntu desktop powerpc -> disable, too?
<pitti> i. e. not ship?
<Riddell> pitti: right don't ship it
<pitti> mythbuntu also hasn't been tested, at least not the current images
<Riddell> my powerpc died years ago
<pitti> Riddell: nice to see the Kubuntu Active passes!
<Riddell> we like to be an active bunch :)
<jibel> skaet, 3rd install of desktop amd64+mac in a row without problem.
<skaet> jibel,  :D   ok, pitti,  let it out.
<pitti> skaet: ok, waling through http://iso.qa.ubuntu.com/qatracker/milestones/210/builds again
<pitti> walking
<skaet> :)   I'll do a pass too.
<pitti> Mythbuntu <- not tested
<pitti> ubuntu desktop mx5 and omap <- not tested
<pitti> ubuntu studio i386 <- not tested, but amd64 ok
<pitti> except of those three, we are good
<skaet> pitti,  Mythbuntu,  Ubuntu Studio are running tests now.
<skaet> ubuntu desktop mx5 and omap,  not ship.
<pitti> disabled those two
<skaet> thanks pitti.
<skaet> superm1,  scott-work, astraljava  ^ any updates on the tests and whether the images are safe?
<Riddell> pitti: do you know if kubuntu active will end up at http://cdimage.ubuntu.com/kubuntu-active/releases/precise/beta-2/ ?
<pitti> Riddell: not for sure, we haven't published it yet
<skaet> Riddell,  can you take a pass through the Kubuntu images and make sure the ones not safe to ship are marked out as well.
<Riddell> skaet: on where?
<astraljava> skaet: I'm still running the tests, sorry.
<skaet> Riddell, on iso tracker please.
<skaet> astraljava,  thanks.   any preliminary feel?
<Riddell> skaet: Kubuntu Alternate amd64+mac  and Kubuntu Desktop amd64+mac can be marked out
<skaet> Riddell,  ok,  please do.
<Riddell> mm, I don't think I know how
<pitti> Riddell: just check them and click "disable selection"
<astraljava> skaet: Studio seemed to have the up-to-date low-latency kernel, and I didn't notice any hiccups. Xubuntu has had most of the mandatory tests run, so I have great confidence in it already.
<pitti> Riddell: can do for you if you wish, of course
<pitti> astraljava: so studio i386 installs?
<Riddell> ooh it works
<astraljava> pitti: I'm testing the amd64 currently, I'll start a test install of i386 in a matter of minutes.
<pitti> astraljava: thanks muchly
<pitti> superm1: any idea about the state of the current mythbuntu images?
<astraljava> pitti: Thank you! :)
<pitti> oh, mythbuntu i386 is fully tested now \o/
<skaet> \o/
<pitti> skaet, cjwatson: as it's very likely that mythbuntu amd64 and ustudio i386 work (as their amd64/i386 counterparts work), I propose I start the publishing work, as this takes a couple of hours to complete (syncs, etc.)
<pitti> if these really fail, we can still pull them again
<pitti> thoughts?
<cjwatson> sounds sane to me
<skaet> pitti,  +1 from me.
<pitti> I'd like to do it before starting dinner, so that it can sync over dinner
<skaet> we may have some pulls, as the data comes in.  but as you say,  we can pull.
<pitti> and it seems all other images are golden
<pitti> ERROR: Cannot handle type active for kubuntu
<pitti> Riddell: ^ hmm, at least publish-release doesn't know about it yet
<pitti> Riddell: can you figure out the right publish-release incantation for it?
 * pitti makes a backup of www/ now, so that we can experiment a bit
<pitti> not sure whether cdimage even knows about it yet :/
<cjwatson> Riddell did do some work on that
<Riddell> I don't know if I've done anything speifically publish-release for it
<cjwatson> Err.  I can't see that error message anywhere
<Riddell> it should be type desktop
<cjwatson> $ grep -r Cannot bin
<cjwatson> bin/semaphore:  echo "Cannot acquire lock on semaphore $SEMAPHORE!" >&2
<pitti> cjwatson: from publish-image-set
<cjwatson> There's no such script
<cjwatson> oh, ubuntu-archive-tools
<pitti> right
<pitti> last time I tried it, I wasn't able to come up with the right publish-release incantation
<pitti> but if Riddell added that now, we just need to plug that into publish-image-set
<cjwatson> one moment
<Riddell> mm I'm not sure I have
<infinity> pitti: It shouldn't be kubuntu, type active, it should be kubuntu-active, type desktop.
<infinity> pitti: Unless we really want to rename it and jam it in the same directory.
<cjwatson> I'm working it out now
<pitti> infinity: sounds fine to me to keep it as a separate project
<cjwatson> http://paste.ubuntu.com/905906/ seems plausible
<cjwatson> just do all the same things that were done for kubuntu-mobile
<pitti> ack
<Riddell> kubuntu-mobile was type mobile as I remember
<pitti> $ ARCHES='i386' for-project kubuntu-active publish-release daily-live 20120328 active named beta-2
<pitti> No daily for precise i386 on 20120328!
<pitti> err, sorry
<pitti> $ ARCHES='i386' for-project kubuntu-active publish-release daily-live 20120328 desktop named beta-2
<pitti> works fine
<pitti> fixing publish-image-set accordingly
<skaet> pitti,  Netboot armel+omap and armhf_omap isn't tested,  marking it don't ship.
<infinity> skaet: Good luck not shipping it.
<infinity> (We don't "publish" netboot beyond the archive, where it's already published anyway)
<pitti> cjwatson, Riddell: publish-image-set.py change committed for active; based on cjwatson's patch with the additional "type = desktop" fix
<skaet> infinity, yup indeed.   marking it explicity for tracking purspose then.
<skaet> (and to ask questions about later... ie.  do we need to produce it for the final image set, etc.)
<infinity> I'm not sure how we suddenly seem to have dropped omap support/testing, but there seems to be a serious miscommunication somewhere. :/
 * skaet nods
<Riddell> thanks pitti
<slangasek> skaet, stgraber: why is Ubuntu core armhf marked for rebuilding?
<skaet> slangasek,  its marked for not shipping, because it wasn't tested.
<infinity> Err, I can test core in 2 seconds.
<infinity> Which other cores are marked not shipping?
<slangasek> infinity: armel + armhf
<infinity> Right, I'll poke them both.
<skaet> infinity,  cool.  We can re-enable them and ship if they're ok.
<slangasek> skaet: armhf is rather er, core to Core; if testing is (ever) needed, feel free to ping me
<skaet> slangasek,  will do.
<skaet> (and thanks)
<utlemming> is there a bug with the armhf core?
<utlemming> s/bub/bug number/
<infinity> There are no bugs, it just didn't get tested.  Doing now.
<utlemming> infinity: ah, okay.
<pitti> erk, I was apparently typing into the void and got disconnected
 * pitti replays
<pitti> cjwatson: oh, did you fix publish-release to put the corrent "Beta-2" into the HEADER.html files?
<infinity> skaet: core/armel and core/armhf are both fine.
<pitti> I don't see any having "Daily Build" any more
<pitti> anyway, looks like publish-release is DTRT now, sweet
 * skaet welcomes pitti back.   infinity is testing out the Ubuntu Core armel and armhf images so we'll be likely to ship
<pitti> skaet, cjwatson: "rel -15 mins" steps 1 to 3 done
<pitti> skaet, cjwatson: i. e. all images published, .manifest and .htaccess mangled, etc.
<infinity> pitti: ^
<pitti> mirrors are syncing now, which will keep them busy for an hour or two
<pitti> skaet, cjwatson: if it's alright with you, I'd leave for dinner now; I'll take my mobile phone with me for emergencies?
<pitti> infinity: yep, publishing these two along then
<skaet> :)
<skaet> If they're added,  enjoy dinner.   :)  Will call if urgent.
<skaet> thanks pitti.
<pitti> reenabled
<pitti> (in the tarcker)
<utlemming> skaet: whats our current ETA on making things public?
<skaet> pitti,  don't disable Beta 2  in the tracker.   Results still coming in on those other projects.
<pitti> utlemming: you can start publishign the EC2 images
 * skaet nods
<cjwatson> pitti: HEADER.html> hmm, I don't recall
<pitti> skaet: nope, wasn't planning to
<pitti> cjwatson, skaet: I don't remember, should or shouldn't I remove beta-1 from releases/cdimage at this point?
<skaet> pitti,  thanks.   I'll do it after we get those last data points,  before the dailies kick off again.
<cjwatson> pitti: it probably wants to go to old-images
<pitti> I can move them to old-images
<pitti> ack, will do
<skaet> thanks.
<skaet> utlemming,  still a couple of hours off for the announce, but getting things ready with the images is good (what pitti says)
<fabsh> when's the eta for the release
<pitti> oh, and moving alpha-2 to old-images as well
<SpamapS> Daviey: around?
<pitti> cjwatson, skaet: alpha-2 and beta-1 removed; should free quite a lot of space on cdimage mirrors then
 * pitti off for dinner then, please call my mobile on fires
<skaet> cjwatson,  am wondering if I should update the links in  to point to old-images for the Alpha2 and Beta1 TechnicalOverview,  so folks know where to find them.   (after Beta 2 goes out).   useful?
<arosales> skaet: will there be an ubuntu-release meeting tomorrow?
<knome> stgraber, nope, we didn't have anything now
<cjwatson> skaet: old-images is not publicly accessible
<cjwatson> so no, not useful :)
<skaet> arosales,  no meeting planned right now - this release is causing some late nights.    Please have detailed status in and we'll handle by email.   Call one on monday if somethings need wider discussion.
<skaet> cjwatson,  fair enough.  :)  thanks.
<cjwatson> perhaps you're thinking of old-releases, but we only do that for actual final releases, not alphas/betas.  old-images is a staging area before old milestone releases get backed up to tape.
<stgraber> knome: when are you expecting your changes to land?
<cjwatson> we can recover them via IS if we have to for archaeology, although not necessarily quickly.
<skaet> fabsh,  lots of things to sort still,  couple of hours out at a minimum.
<skaet> fabsh,  announce email will signal we've stopped making changes ;)
<arosales> skaet: ok, thanks.
<knome> stgraber, well i don't know, we're not planning anything... ;)
<utlemming> skaet: cloud-images are published
<knome> stgraber, i was just asking for the future, and for ubuntu studio too
<skaet> thanks utlemming,  I'll start checking links and let you know if I spot glitches.
<stgraber> knome: oh, good, I thought you had some stuff to update already, I certainly won't complain that you don't have to do last minute translation template update ;)
<knome> ahh, nope ;)
<skaet> jbicha,  how are we looking on ubuntu-doc freeze?
<Laney> has the default wallpaper materialised yet?
<jbicha> skaet: umm...
<jbicha> I only got half the screenshots done, I don't expect to be able to finish the rest until this weekend
<skaet> Laney,  default wallpaper change isn't supposed to affect screen shots based on earlier discussion.
<skaet> jbicha,  are all the strings ok,  for the translators to start?
<jbicha> skaet: I'm going to give it a final lookover and ping you & dpm when I'm done
<skaet> jbicha,  sounds good.
<skaet> thanks
<SpamapS> Can I get an ACK on this juju FFE? https://bugs.launchpad.net/ubuntu/+source/juju/+bug/962507 .. Daviey ACK'd it last week, but there have been a few additional changes and I want to make sure its ok before upload.
<ubot2> Launchpad bug 962507 in juju "[FFE] Latest juju snapshot enables maas provider" [High,New]
<superm1> pitti: Daviey is going to test amd64 shortly, but not too much worry as i386 is looking good
<skaet> superm1,  ok.  :)
<pitti> syncs are making progress, but will still take a while
<jbicha> skaet: I believe we'll be good to freeze ubuntu-docs, technically that happens at 2100 UTC, right?
<skaet> jbicha,  yes.   and thanks.   that's good news.
<jbicha> skaet: except for the other half of the screenshots like I mentioned
<skaet> astraljava,  all still looking ok on Ubuntu Studio.
<skaet> jbicha,  noted.  :)
<astraljava> skaet: Yes, I've been running some exhaustion tests on the kernel, and it's looking quite good. Still need some more time on the i386, but looking good thus far.
<astraljava> (...there was a set-back with the test machine I use for i386 tests, hence it's been delayed a bit...)
<skaet> astraljava, sounds good we'll keep on the path of assuming they'll be releasing then.
<astraljava> skaet: Absolutely, no reason not to.
<pitti> skaet: hm, I see that ubuntu amd64+mac got disabled, but it was tested; why wouldn't we release this?
<pitti> once the big sync is done, I'd like to publish it as well
<skaet> pitti was disabled before jibel, gave us the +1 its ok.
<pitti> ok, re-enabling and publishing
<skaet> since we know its ok,  reenable.
<skaet> :)
<pitti> 'k, done
<pitti> will wait with another sync-mirrors push until the current one is done, though
<skaet> pitti,  there's some community arm ports being tested and may get results for later today.   If they don't make your big push,  handle tomorrow?
<pitti> skaet: I can queue them up now
<pitti> or later, yes
<skaet> pitti,  not sure yet which ones will make it.  so later is probably better.
<pitti> skaet: so far my plan was to take a break for an hour or so, as there's not much I can do to speed up the rsync now
<pitti> skaet: I'll check back in maybe 1.5 hours, check sync status, and publish the rest
<pitti> sounds ok?
<skaet> pitti.  that works for me.  Am on editing of the announce.  Would like you to take a pass at it in about an hour or so if possible?
<pitti> sure
<skaet> Thanks.  :)
<pitti> re
<pitti> ah, sync seems to be mostly done, xubuntu is there
 * pitti pushes the next sync run
<skaet> pitti, amd64+mac images not showing up under ubuntu yet.  can you check?
<pitti> skaet: covered in this run
<pitti> also the removal of alpha-2/beta-1
<pitti> ahh, these are now gone from http://cdimage.ubuntu.com/edubuntu/releases/12.04/
 * pitti watches cdimage.u.c. take a deep breath from freeing some GBs
<pitti> skaet: any new image verifications since then?
<pitti> skaet: http://cdimage.ubuntu.com/releases/12.04/beta-2/ has amd64+mac now, and the rest should be there now, too
<infinity> pitti: Where was that proposed build status page you whipped up?
<pitti> infinity: http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html
<pitti> right next to all the others
<infinity> Oh, that's just uninstallibility reports.
<infinity> I though you had something detailing out-of-date/unbuilt.
<pitti> infinity: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<pitti> argh, but now that precise is thawed it doesn't actually show that any more
<pitti> I'll fix that
<pitti> ... tomorrrow
<pitti> infinity: do you know what's up with https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.1-1ubuntu3/+build/3367726 ?
<pitti> that looks strange
<pitti> and the previous version did build on amd64
<pitti> and the delta to this is just a typo fix in Depends:
<infinity> That looks like someone asked webops to "cancel" it instead of killing it.
<infinity> Build records in that state can't be fixed without DB surgery.
 * infinity wonders why that was done, and by whom.
<astraljava> pitti: skaet: I've been running the tests on both amd64 and i386 for Studio, and I believe I can now say in confidence that they are working just fine.
<astraljava> with confidence*
<pitti> infinity: right, I guess we'll need another upload to rescue this? (sigh)
<pitti> astraljava: splendid, thanks!
<SpamapS> FYI, i need to do an upload of mysql soon, there's a new upstream w/ security fixes
<astraljava> Thanks to you guys!
<SpamapS> just giving release team a heads up :)
<infinity> pitti: Or sort out the DB surgery with wgrant and have it hotfixed by webops.
<infinity> pitti: It's just a single update to a row.
<infinity> pitti: Given that ARM has been building it for a good while, it might be nice to fix the build record.
<pitti> yes, absolutely
<skaet> astraljava,  great!   and thank you.
<skaet> Riddell,  where should the Kubuntu Active image being showing up?   am not seeing it in the Kubuntu page.
<pitti> skaet: http://cdimage.ubuntu.com/kubuntu-active/releases/12.04/beta-2/
<pitti> skaet: sorry, DSL dropout; I /msged that to you, but I guess it got lost
<skaet> pitti, thanks.   Will go add the link.
<pitti> skaet: so DSL + the late hour might want to tell me to go to bed :)
<skaet> pitti,  thanks for your help.   understand.   I think we're pretty close.
<skaet> I'll impose on infinity or slangasek if there are remaining issues spotted.
<pitti> cheers, so good night, and good luck with the remaining bigs!
<pitti> bits
<skaet> Good night pitti,  sleep weel.
<skaet> well even.  lol
 * skaet doesn't have the excuse its late,   just lots of typing today.
 * knome sends skaet some replacement fingers
<skaet> :)
<Daviey> \o/
<scott-work_> skaet:  did you get an answer from astrlajava about the studio images?
<skaet> scott-work,  astraljava just gave them a +1 in the backscroll.   we're good.
<skaet> (about 23 minutes ago)
<skaet> web site up - check
<skaet> links to mirrors working - check
<skaet> links on annouce email working - check
<skaet> yup, guess its that time....
<skaet> Beta 2 is released.
<fabsh> nice
<fabsh> i can publish my news article now :)
<mdeslaur> congrats!
<skaet> thanks for waiting fabsh - very much appreciate it!!!
<fabsh> its my job :)
<ScottK> Sigh.
<skaet> Riddell,  scott-work,  knome,  stgraber,  highvoltage, astraljava, gilir - we're live now.
<ScottK> Announcement still refers to an Ubuntu kernel.
<knome> skaet, yup, our beta2 announcement is up since "<skaet> Beta 2 is released" + 15 secs:)
<stgraber> yay!
<skaet> ScottK - in announce we say its clearly based off upstream Linux kernel.   Not trying to hide where it comes from.
 * knome rejoices with some good rum
<ScottK> That's true.
<Riddell> awooga
 * fabsh has Talisker
 * knome prefers ron zacapa 23yo
<skaet> thanks pitti, cjwatson, infinity, Riddell,  slangasek for getting those bits all nice and sorted.  :)
<ScottK> skaet: Fair enough.  It seems reasonable.
<fabsh> knome: it was a gift, i won't complain
<knome> fabsh, heheh, yeah, i wouldn't either... :)
<astraljava> A huge thanks for the whole release team!
<skaet> :)
* ChanServ changed the topic of #ubuntu-release to: 12.04 Beta 2!  Precise Feature Freeze in effect.  Archive:open  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin 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 chocolate covered ants | melior malum quod cognoscis
* ChanServ changed the topic of #ubuntu-release to: 12.04 Beta 2 released!  Precise Feature Freeze in effect.  Archive:open  | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin 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 chocolate covered ants | melior malum quod cognoscis
<fabsh> ok, peeps. my news item is submitted and pending editorial review. i'm off to bed. good luck with the beta! :)
<wgrant> infinity: The button was added to fulfill the long-standing request for a button to permanently kill a build so the user couldn't retry it.
<wgrant> infinity: eg. if it's a buildd-killing build.
<wgrant> infinity: (except that the button doesn't work for non-virt builds, so I guess a WebOps manually did this one with SQL)
<skaet> Daily builds have been turned on.
<skaet> default milestone has been pointed back to Precise Daily.
<infinity> wgrant: I can't see why anyone would have manually done it, since we want that build to happen.
<wgrant> infinity: pitti requested some LO builds killed last night.
<infinity> wgrant: Anyhow.  I think we might need a duckie-accessible way to undue the pain that button brings, if we insist on keeping it.
<wgrant> I'm not sure if that was one of them.
<infinity> wgrant: The ones he requested were a previous version.
<infinity> wgrant: But someone may have oopsed.
<infinity> wgrant: Anyhow, would it be doable to resurrect that build record?  Don't really want to reupload and reset the whole process on other arches.
<wgrant> aaaaaaa
<wgrant> infinity: Best is probably to convince a webops to reset the status to FAILEDTOBUILD
<wgrant> infinity: Then you can retry normally.
<infinity> Sure, is that all it takes?  It's just in a broken status?
<infinity> (do they know the SQL for this by rote, or do I need you to give them a query?)
<wgrant> infinity: You'll need to ask them.
<wgrant> I don't know all their secret repositories.
<stgraber> skaet: did the matching changes on the tracker
 * stgraber killed the bot to avoid the flood
<stgraber> that's an interesting side effect of marking a milestone as released ;)
<stgraber> will need to fix that...
<knome> khihi
<skaet> stgraber,  :)  looks good.
<phillw> will http://iso.qa.ubuntu.com/qatracker/milestones/210/builds tidy itself up, or do one of you good people need to that manually?
<stgraber> phillw: what do you mean? it's now archived as it's and shouldn't ever change anymore
<phillw> stgraber: it shows the aborted mac builds as rebuilding?
<knome> awwwh
<stgraber> sorry for that
<stgraber> phillw: yeah, we mark them for re-build when we know they won't be released
<stgraber> so I at least confirmed that moving a milestone from release to testing makes the bot spam everyone which is the intended behaviour :)
<phillw> okies, just I know someone will ask me 'when will they finish rebuilding?' :D
<stgraber> now let's say if archiving no longer spams us :)
<stgraber> *see
<stgraber> so far so good
<stgraber> still good, now let's see if we get spammed
<stgraber> apparently not, so looks like the fix worked
<GrueMaster> Ok, looks like Beta 2 is now archived.  I can say that I have run through all arm images and everything passes (with bugs).  I have a list of bugs as well.  Just can't enter them in the tracker.
<stgraber> ... who re-enabled the milestone? :)
 * skaet reopened the Beta 2 release to get some more results added to the tracker.
<skaet> stgraber,  I'll set it back again as soon as those results are added.
<stgraber> skaet: ok :) I'll find a clever way to prevent the bot from flooding both channels when moving a milestone back to testing
<skaet> stgraber,  sounds good.
<knome> hrmm?? stgraber
<stgraber> at least we confirmed that the bot no longer gets killed for flooding LP :)
<stgraber> knome: what? the bot is doing what it's supposed to ;)
<knome> oh, right
<knome> ...
<knome> a very good FLOODBOT then
<knome> :)
<skaet> knome,  sorry,  few last results came in we wanted to add to release.
<knome> np :)
<skaet> stgraber,  I'll give you some warning when we're done, and you can switch back to test out your new non-flood version... ;)
<skaet> when you're ready.
<skaet> or I'll just do it,  either way is fine.
<stgraber> skaet: switching back won't flood, I added code for that
<stgraber> as testing => release is expected milestone status change
<stgraber> released => testing isn't :)
<stgraber> skaet: just looked at the code again, it's going to be pretty difficult to differentiate someone moving a milestone from released to testing vs someone adding the first set of images to a new milestone
<stgraber> besides checking how many entries and not doing anything above a given threshold
<skaet> stgraber,  ok,  I'll switch it back now.   New results have been added.
<stgraber> skaet: added flood protection, if there are more than 25 images added at once it'll just print a single message ;)
<stgraber> let's see if that works :)
<skaet> heh,  notice you just did
<skaet> :)
<infinity> 25 seems like a pretty high threshold.
<stgraber> infinity: yeah, but I still want notifications when we add all the upgrades
<skaet> hmm... did I just cause that quit, by doing the switch back to release?
<stgraber> skaet: nope, I'm fixing a bug
<skaet> :)
<skaet> stgraber,  I've done what I need to.   Will let you test as needed now.   ;)
<stgraber> skaet: thanks :)
<infinity> stgraber: Well, what's the theoretical largest number you can get in one go?
<infinity> All arches for any given CD build is only 4 at the moment.  All subarchaes for d-i is a bit more, if they all published at once.
<infinity> subarches, even...
<stgraber> qatracker=> SELECT count(*) FROM qatracker_product WHERE siteid=1 AND status=0;
<stgraber>  count
<stgraber> -------
<stgraber>    117
<stgraber> (1 row)
<stgraber> total number of products with status active on iso.qa.ubuntu.com
<infinity> Well, yes.  I didn't mean how many are there, I meant how many would post simultaenously.
<infinity> I'd guess that anything over 10 is an "oops, we touched everything" flood.
<stgraber> ok, almost working ;)
 * infinity likes the %s.
<infinity> printf is hard.
<stgraber> infinity: currently, the maximum number of products we've been adding at once is 16
<stgraber> infinity: that's when we add all the upgrades
<infinity> Seriously?  16?
<stgraber> infinity: yep
<infinity> I guess I'm thinking from a cdimage autopost perspective, where it's technically impossible right now to post more than 4 things at once.
<stgraber> yeah, upgrades are added either by a script that pushes them all at once with the current date as the version or by someone in the admin UI selecting them all and clicking "add build"
<stgraber> both of them result in all of them appearing in the DB in a single transaction
<infinity> Check.
<infinity> I'd almost argue for a lower flood protection, but special-case upgrades.
<infinity> "Upgrades were added for %d products: product arch, product arch, product arch"
<stgraber> ok, %s fixed ;)
<infinity> Cause I don't want to see 16 lines of output, even if it's legit. ;)
<stgraber> yeah, I guess that'd be an idea. For now the limit of 25 prevents the "oh, here's everything showing up again". The other cases (website failure, ...) are already dealt with in the code (and it's been hitting that bit a few times over the past 2 hours)
<phillw> who maintains the page http://releases.ubuntu.com/ ?
<slangasek> the release team / cdimage team does
<infinity> phillw: Why do you ask?
<infinity> Oh, cause it doesn't list all the flavours.
<slangasek> infinity: if you're fixing, should probably pull Gobuntu off there while you're at it since it's EOL
<phillw> I've had mutterings from the ranks that lubuntu isn't on there!
<slangasek> (was desktop, last released with hardy)
<infinity> And change some wording.
<infinity> And it should probably also point out that cdimage/releases hosts unsupported Ubuntu images too.
<infinity> Or even supported ones that we just don't put on releases. :P
<infinity> lubuntu's a less ambitious and easier fix, though.
<phillw> thanks :)
<infinity> Err, if that text actually showed up anywhere in the source...
<infinity> Oh, it's not generated.
<infinity> Just a static header.
<infinity> Derp.
 * infinity rearranges alphabetically to avoid people complaining about Kubuntu being special.
<phillw> we're all a bit tired, me thinks! I was going to bed 3 hours ago!
#ubuntu-release 2012-03-30
<infinity> If only I could spell Ubuntu...
<infinity> phillw: How does that look, other than my typo?
 * stgraber likes alphabetical order ;) at least until someone creates Abuntu or similar
<infinity> Aardbuntu.
<infinity> For aardvarks, of course.  Not to be confused with Arrbuntu, for pirates.
<skaet> stgraber, going through the b2 milestoned bugs - https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/862867 looks resolved from comments,  can it be closed?
<ubot2> Launchpad bug 862867 in ubiquity-slideshow-ubuntu "Screenshot for Web slide in Ubuntu slideshow is focused on English text" [Medium,Confirmed]
<phillw> infinity: looks great, thanks. It is little things like that which I get nagged at for :)
 * infinity wonders if there's a way to make "The cdimage server also hosts other Ubuntu images not found on this server" either more vague or more usefully informative, without writing a long paragraph about how some of the Ubuntu images on cdimage are "supported", but not published to releases, while others are community best-effort, and, and...
<infinity> Maybe I'll just leave it the vague way I wrote it.
<phillw> infinity: Â The cdimage server also hosts other Ubnuntu images not found on this server. ???
<phillw> Now, I know I'm tired.... but that does not make sense!
<stgraber> skaet: yeah, I quickly confirmed we indeed have the olpc website now and marked as fix released
<infinity> phillw: "this server" being the one you're reading (releases.ubuntu.com).
<infinity> Maybe I need to spell that out instead of using a pronoun.
<skaet> thanks stgraber.  :)
 * infinity also thinks it might not be a bad idea to have a short plug/tagline for each derivative in brackets after the link...
<infinity> Edubuntu (stgraber can write this one), Kubuntu (featuring the KDE desktop), Lubuntu (featuring the LXDE desktop), etc...
<slangasek> infinity: sounds like asking for a maintenance headache to me, updating the text in response to requests?
<slangasek> the references are there to tell users "this is wrong page, go -->there"
<infinity> slangasek: Well, I didn't mean a full-blow advertisement, just an obviously-correct "uses XFCE".  But yeah, a link to the homepage would work too.
<phillw> infinity: may be a link to the wiki page for each would be better (less for you guys to maintain)
 * infinity shrugs.
 * infinity glares at queuebot.
<infinity> stgraber: That should be a binary, not a translation. ;)
<phillw> infinity: so, for example, lubuntu would be https://wiki.ubuntu.com/Lubuntu
<stgraber> infinity: https://launchpad.net/ubuntu/precise/+queue tells me the bot is right ;)
<infinity> stgraber: Note that it's "i386,raw_translations"
<infinity> stgraber: The i386 bit being slightly more important. :P
<infinity> (d-i would have the same problem)
<infinity> It would say (arch,raw-installer)
<infinity> Actually, probably (arch,raw-translations,raw-installer)
<infinity> stgraber: But any binary with stripped translations will come out that way, so it should probably DTRT. ;)
<stgraber> infinity: for releases.u.c, I guess we could go with Edubuntu (Educational flavour of Ubuntu) (http://www.edubuntu.org)
<stgraber> infinity: yeah, the trick is that it's showing up as a single entry...
<stgraber> infinity: should the bot announce binary + translations separately in that case?
<stgraber> infinity: (don't accept that binary, I want to keep it around to test the fix ;))
<infinity> stgraber: No, we don't care about the raw-* components from the bot.
<infinity> stgraber: Just the arch bit.
<infinity> stgraber: So, "linux [i386]" is fine.
<infinity> stgraber: Won't be accepting until all the arches roll in, you have many hours. ;)
<stgraber> infinity: so are there cases where the bot should show the "New translation" message then?
<infinity> stgraber: I suppose if an upload has a raw-* component and no arch component, that would be something special to handle, but I'm not even sure LP allows that, and I'm sure no package does it.
<infinity> stgraber: In practice, raw-* is always tacked onto an arch upload, and it's the arch upload we care about.
<stgraber> k, I'll try to update the bot to ignore raw-* then
<infinity> stgraber: So, no, there's no call for "new translation" or "new debian-installer bits" or "new ddebs" or "new other junk you can do with raw-"
<skaet> slangasek,  who does accepts on ubuntu-font-family?   spotted something that looks like its been fixed, but fallen through the cracks.
<phillw> skaet: what happened to the early night?
<skaet> phllw,  started on cleaning up milestoned bugs....
 * skaet must walk away from terminal...
<phillw> my body clock is that messed up, it thinks it is currently half past Tuesday!
<skaet> pitti,  I'll finish the review/moving of the beta 2 milestoned bugs tomorrow,  would like to do it.  Some interesting patterns in them.
<skaet> beta 2 milestone has be closed now.
<skaet> will work on the beta + 1 day checklist more tomorrow.
<skaet> good night all.
 * skaet --> dinner.
<phillw> skaet: enjoy, with a glass of richly deserved wine!
<knome> may the glass be overflowing... but not too much so none of the wine is spilled on the floor
<slangasek> skaet: not sure what you mean wrt accepts on ubuntu-font-family?
<micahg> can someone please look at skype (i386) in partner?
<micahg> in NEW I mean
<infinity> micahg: Done.
<micahg> infinity: thanks
<pitti> skaet: we have a script in ubuntu-archive-tools to mass-move them over, can do
<pitti> move-milestoned-bugs.py  ubuntu-12.04-beta-2 ubuntu-12.04
<pitti> running now
<pitti> cjwatson: do you have an opinion about bug 968121? I don't really see how we can not do it, but I'd appreciate a second pair of eyes
<ubot2> Launchpad bug 968121 in apport "[FFE] crashdb.conf needs a way to disable reporting of particular problem types" [High,New] https://launchpad.net/bugs/968121
<micahg> FYI, I asked for molybedenium to be switched to i386 to help with the rebuild (only needed for hardy)
<pitti> ah, appreciated, especially with rothera being out
<Laney> did something go wrong with the LO builds?
<pitti> yes, bug 930217
<ubot2> Launchpad bug 930217 in launchpad "Make proposed pocket useful for staging uploads" [Low,Fix committed] https://launchpad.net/bugs/930217
<pitti> the -proposed builds failed to upload
<Laney> ah, that's what it looks like if the release gets unfrozen in the interim?
<pitti> Laney: I asked Sweetshark to reupload to precise
<pitti> I didn't think that it would reject the binaries, just that it wouldn't allow uploads
<pitti> yes, apparently
<Laney> i see, good to know
<Laney> not that it should be happening in the future :-)
<pitti> infinity: FYI, http://people.canonical.com/~ubuntu-archive/pending-sru.html has precise again now
<cjwatson> pitti: I haven't gone through the code, but the need seems reasonable enough ...
<cjwatson> pitti: Binaries go through much the same upload path in some ways.
<pitti> I'm quite convinced about the implementation, I'm mostly wondering about the concept
<pitti> I discussed it in-depth with Evan, and that's what we came up with which makes both of us happy
<cjwatson> Your description seems sound enough
<pitti> the configuration change is future proof, and the implementation temporary until we support whoopsie in apport more properly
<cjwatson> I was a bit scared that you might be trying to land that proper implementation; a less intrusive hack seems more appropriate for the moment
<pitti> cjwatson: right, I targetted bug 957177 to Q for thaht
<ubot2> Launchpad bug 957177 in apport "support multiple crashdbs" [Medium,Triaged] https://launchpad.net/bugs/957177
<pitti> this patch is about as small as I can make it, and much of it is tests anyway
<pitti> the gut of the change is just 5 lines
<cjwatson> pitti: approved
<pitti> thanks for the review
 * cjwatson goes off to QA proposed-as-staging-pocket
<pitti> cjwatson: aside from LibO this has worked really wonderfully
<pitti> cjwatson: not a single second of archive breakage due to gnome 3.4 and unity, and we could use the builders during freeze
<pitti> how could we ever not have that! :-)
<cjwatson> mm, the compiz / gtk+3.0 thing did point out why it isn't a panacea; I wonder if it would be possible to improve things so that the builder could use packages from release if the ones in proposed are uninstallable
 * pitti just gets way too happy and verbose about improvements like that
<cjwatson> but in general, yeah, should be nice
<pitti> right, we encountered that problem in SRUs as well
<cjwatson> yep, same thing
<Daviey> cjwatson: I have NFI how whoopsie reporting is supposed to work on servers... but we are now installing it by default.  Are there doc's i'm missing?
<cjwatson> Daviey: ask Evan :)
<Daviey> ev: ^^
<ev> Daviey: it has an inotify watch on /var/crash. Apport drops crash files in there, you run apport-cli to process them and in doing so it touches /var/crash/$report_file.upload which tells whoopsie to upload the report to the crash database.
<Daviey> ev: So it's purely done by manual intervention ?
<pitti> admins can do http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51
<pitti> if they care
<ev> at the moment, yes
<micahg> pitti: can you delete the amd64 binaries of libreoffice in -proposed, they're broke
<micahg> pitti: precise-proposed
<pitti> micahg: I'll delete the whole source; it can't build in -proposed anyway ATM
<micahg> pitti: sure, as long as the binaries go with it :)
<Daviey> pitti: thanks
<pitti> micahg: all gone
<micahg> pitti: thanks :)
<didrocks> bdmurray: skaet: is the rls-p-tracking daemon is opening downstream bug task?
<ogasawara> when someone has a moment, can I get the 3.2.0-21.34 kernels approved in the new queue?
<pitti> ogasawara: looking
<pitti> ogasawara: don... ah, big brother beat me to it :)
<ogasawara> pitti: heh, thanks anyways
<pitti> ogasawara: I mean beat me to the announcement; I binNEWed them now
<cjwatson> is there a release meeting today?
<pitti> traditionally we skip it after a release
<pitti> and just send our reports
<pitti> but haven't heard something definitive
<ogasawara> I recall skaet mentioned yesterday that the meeting is canceled for today and she'd call an impromptu meeting on monday if needed
<cjwatson> good
<skaet> good morning
<stgraber> skaet: good morning
<skaet> pitti, cjwatson, ogasawara yes,  meeting is cancelled but email reports please,  and we can assess later if we need a meeting on monday.
<skaet> good morning stgaber, :)
<pitti> skaet: thanks for confirming
<pitti> skaet: and good morning!
<pitti> skaet: congrats for wrapping beta-2
<skaet> :)  thanks for all you help with getting those images out the door.
<Laney> stgraber: highvoltage: bug 935147 - any opinion either way?
<ubot2> Launchpad bug 935147 in liferea "FFe: Please merge liferea 1.8.3-0.1 (main) from Debian unstable (main)" [Unknown,Fix released] https://launchpad.net/bugs/935147
<stgraber> Laney: looking
<stgraber> Laney: would have preferred to hear about it earlier, but as we have to support it for 5 years, I think it'd be good to have a version upstream actually supports
<Laney> stgraber: OK, so I'll grant the FFe then. You can sponsor if you want, otherwise I'll leave it in the queue.
<stgraber> Laney: I'm not a user of liferea myself but the UI is very similar to what I remember so even if we have it in our install slideshow we won't need to update it and we haven't made the final screenshots for the website, so that part is fine
<Laney> there we go, all yours
<Laney> looks like he nuked the last Debian changelog entry for some reason, otherwise the diff seems reasonable on first glance
<stgraber> Laney: it actually looks like diff being pretty confused by the added entry having some identical lines with the latest debian entry
<Laney> oh yeah, I see it further down
<stgraber> right, diffs look reasonable and it's been built in his ppa so assuming it'll build in the archive too. uploaded
<Laney> nice
<highvoltage> Laney: not having looked at the bug report yet... I'm currently using 1.8.3 on Debian and it has a nasty regression with summarizing feeds in Unread
<Laney> stgraber already sponsored it :P
<highvoltage> good, maybe someone in ubuntu might end up fixing it too then :)
<ogasawara> pitti: could I also get linux-backports-modules-3.2.0 approved in the new queue please?
<pitti> ogasawara: ah, that's just for i386/amd64 anyway; accepted
<skaet> pitti,  cjwatson, slangasek (and release team members as well as others interested...),  have created blueprint to catch ideas and thoughts about how we'll use the new staging in -proposed capability
<skaet> https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed
<skaet> please add to the whiteboard ideas, concerns, etc. as they occur through this next month,  and we can then discuss at UDS.
<cjwatson> skaet: could we please reuse foundations-p-upload-intermediary instead?
<cjwatson> obviously it's fine to move it to other-q etc. but I feel we should keep that history
<pitti> in case someone wonders about the gccgo binary rejection, see #ubuntu-devel from 20 minutes ago
<skaet> cjwatson, agree on keeping history is important.   I'll move the history over to the q whiteboard, since there are likely to be q workitems come from this, and would need to set up one anyway for tracking then.    I'll paste any workitems postponed to the new workitem tracker as well.
<infinity> Why are we rejecting gccgo-4.7 binaries?
<cjwatson> infinity: 15:58 <pitti> doko: hm, should gccgo-4.7 really produce the gcc-4.7-base, fortran, and other packages as well?
<infinity> Ahh.
<infinity> I suppose if I'd looked in the queue, I would have noticed. ;)
<knome> can somebody look at bug 969252 ?
<ubot2> Launchpad bug 969252 in shimmer-themes "[UIFe] Bluebird rebased against Greybird for Gtk3.4" [Undecided,New] https://launchpad.net/bugs/969252
<infinity> knome: Rebasing seems sane to me.
<knome> is there something i need to do, or will somebody get it uploaded now?
<knome> err, i mean, what to do next; can i tell our uploader to upload or what :)
<infinity> Make sure it's well tested, but yeah, have him upload.  User Interface Freeze doesn't mean "your UI must remain broken". :P
<knome> okay, thanks. so when he does, i will see the package name appearing in this channel automagically, and somebody will take care of it after it's uploaded?
<infinity> That's the general theory.
<cjwatson> if we were frozen ...
<cjwatson> there was discussion of that but we don't appear to be
<knome> oh, right... :)
<infinity> Oh, there's also the not actually frozen part, yes.
<infinity> (Didn't we stay frozen between the last Beta and release last cycle?)
<skaet> yes
<skaet> I'll send a proposal around by email after lunch.
<knome> so uh,  i don't even need an exception? :D
<infinity> knome: Oh no, you still needed an exception.
<skaet> we're still frozen for features,
<knome> okay, can somebody throw an ACK to the bug
<infinity> knome: The archive not being frozen doesn't mean feature/UI freezes don't need to be respected socially.
 * skaet --> lunch biab
<infinity> knome: Bug updated with a request for more info, but I'm tentatively fine with the idea.  Broken themes need to be fixed and sane, freeze or no.
<knome> okay, thanks
<knome> i'll have a look at it :)
<micahg> do we have a problem with binaries in a tarball if they're not used?
<infinity> micahg: You mean from upstream tarballs?
<infinity> micahg: If the binaries are produced from the source in the tabrall, it's distasteful, but allowed.  If they're there without source or any meaningful way to create them, it's generally considered non-free, and should be repacked (or beg upstream to release it properly).
<infinity> micahg: In neither situation should the binary be used, of course (either for the build, or shipped).
<micahg> infinity: generated in this case :), I just noticed a bunch in the now 400MB chromium tarball
<infinity> micahg: It's my impression that chromium upstream aren't complete twits, maybe you could ping them to repack their source without the binaries?
<micahg> infinity: it's generated from the repo, no upstream source, I guess I'll just exclude them
<infinity> micahg: But yeah, if it's all a product of the source, it's not world-ending, just ugly.  And don't use them in the build or ship them in the final binary packages.
<infinity> Oh, if it's produced from elsewhere, yeah, repack a +dfsg tarball or something.
<infinity> (Well, don't bother renaming it if you don't want an ugly version number, but you know what I mean)
<knome> updated 969252 with diff :)
<infinity> knome: Looks good.
<knome> thanks, i'll let our uploader know
<knome> re: px/no px, i don't know... :)
<infinity> Yeah, was just odd.
<knome> mm-hmm, i noticed that too ;)
<skaet> infinity, slangasek, pitti, cjwatson, Riddell, Daviey - we had someone making inappropriate changes to our TechnicalOverview/Beta* pages.   They should now be locked down by IS to just be editable by members of the release team.
 * slangasek nods
<skaet> ScottK, Laney, tumbleweed, NCommander, ^  FYI.
<Riddell> thanks skaet
<phillw> hi guys, before I go prod Julien in the ribs about the modemmanager falling off the standard packages for lubuntu, would he need to request an exception, or are you guys okay with it being a bug-fix?
<slangasek> phillw: sounds unambiguously like a bugfix to me
<phillw> slangasek: thanks, I'll go poke him in the ribs. Heck, these things happen :)
<micahg> what do you think of pulling in the new librsvg from debian that restores the rsvg script for precise?
 * skaet figures slangasek or inifinty is better answering that one ^
<infinity> micahg: I may need you to elaborate on what that means. :P
<infinity> skaet: Inappropriate changes?
<micahg> infinity: there are are quite a few rebuild failures due to the rsvg script being removed upstream, Debian decided to add it back until the reverse dependencies are fixed
<skaet> infinity,  Ubuntu Kernel -> Linux Kernel a few places too many
<skaet> we don't want to get upstream irritated
<infinity> micahg: Ahh, yeah, that seems fair.
<infinity> micahg: If that's the only meaningful change, go nuts.
<micahg> infinity: unfortunately, they didn't multiarch it yet, so it's still a merge
<infinity> Good thing you're good at merges, right?
<micahg> heh
<micahg> I think I've done more syncs than merges this cycle
<infinity> skaet: I'm not sure reverting all of those Ubuntu->Linux things wholesale is really a great idea either. ;)
<infinity> skaet: Especially not with a commit message of "credit had been given to linux", as if that's somehow a bad thing.
<skaet> infinity, language on beta 2 was worked out with kernel team to keep from getting upstream mad at them.   Beta 1 revert was ammended to insert extra "linux" to be explicit to match Beta 2 wording.
<infinity> Hrm.  Kay.
 * skaet --> eow,  TGIF.  :)
 * infinity tosses out beer.
<skaet> :)
#ubuntu-release 2012-03-31
<ScottK> infinity: Would you please promote python3-docutils and python3-roman binaries to Main so python-sphinx can build?  It's binary promotion from existing Main source, so no MIR should be required.
<infinity> component-mismatches claims it wants python-support too... Was that fixed?
<ScottK> Weird.
<infinity> E: Package 'python-support' has no installation candidate
<infinity> Build log agrees.
 * ScottK looks.
<infinity> I think someone forgot to drop a build-dep when moving to dh_python2
<infinity> Also pygments and sqlalchemy, but those are both binary-only, so that's fine.
<infinity> But yeah, not re-promoting python-support, obviously. :P
<ScottK> Looks like a bad merge.
<infinity> Mmkay.
<infinity> Double-check all the other build-deps before fixing? ;)
<infinity> And I'll promote whatever actually needs promoting when you do.
 * infinity wonders why sphinx is a unique snowflake and disables translation stripping...
<ScottK> I don't remember, but there is a good reason for it.
<ScottK> It broke something.
<ScottK> ed gets pulled in as a build-dep
<ScottK> It seems really wrong to need an editor to compile something.
<ScottK> Need to get 78.5 MB/83.3 MB of archives. <-- It'll be a few minutes
<ScottK> Those were the only ones.
<ScottK> infinity: Fixed one uploaded.
<infinity> ScottK: python3-docutils python3-pygments python3-sqlalchemy promoted.
<infinity> Oh, oops, forgot roman.
<ScottK> infinity: Thanks.
#ubuntu-release 2012-04-01
<ScottK> FYI, all the KDE telepathy/ktp demotions in component mismatches are legit.
<infinity> ScottK: Really?  You're dropping all things tp-qt4?
<infinity> ScottK: Ahh, kopete/kde-tp flip-flopping, I see.  Kay.
<ScottK> infinity: Yes.  We concluded to stay with the legacy program (Kopete) for one more cycle.
<ScottK> Yes.
<infinity> Yeah, had to check the seeds for the rationale. ;)
<ScottK> It was worth a shot, but it's not mature enough yet.
 * infinity nods.
<infinity> I still use pidgin on GTK desktops, so I can relate.
<infinity> (Though empathy is certainly a lot less crap than it used to be... Some day, they'll win me over)
<infinity> Anyhow, I'll poke those demotions in a bit, thanks for the heads-up.
<infinity> cjwatson: Do you know off-hand why buildlive in production calls "ssh -t" instead of the "ssh -n" found in bzr?
<infinity> cjwatson: Given that "ssh -t" to any of the livefs builders spews "PTY allocation request failed on channel 0", I'm not entirely sure it's doing any good. :P
<infinity> cjwatson: (Production's been carrying that diff for ages, not sure if you're the one responsible, but I only just now checked to see what it did or didn't do)
<slangasek> infinity: that was me, I was attempting to get remote job control for killing runaway live builds
<slangasek> (it didn't work)
<infinity> Ahh.
<infinity> Fine with it being reverted, then?
<slangasek> I imagine so
<infinity> I just happen to need to touch that line, so I wanted to get production and bzr to agree first. :P
<infinity> Hahaha.
<micahg> wow
<infinity> I'm so tempted to just reject that without even reviewing it.
<micahg> infinity: did you check the date (unless you're on the west coast)
<infinity> Oh, fair point.
<micahg> infinity: he is on the west coast, so maybe reject for being too early :)
<knome> btw, for information to the release team as well: http://open.knome.fi/2012/04/01/xubuntu-rebasing-on-debian/
<infinity> And it already has serious comments.
 * infinity shakes his head.
<coolbhavi> hi release team I wanted your comments on  https://bugs.launchpad.net/ubuntu/+source/epiphany-extensions/+bug/970525 which seemed fine to me since its an update containing only translations from the previous version of the package in ubuntu
<ubot2> Launchpad bug 970525 in epiphany-extensions "Sync epiphany-extensions 3.4.0-1 (universe) from Debian experimental (main)" [Wishlist,New]
<coolbhavi> jbicha, hi I was taking a look at your sync request :-)
<jbicha> coolbhavi: hi
<phillw> infinity: lol @ http://open.knome.fi/2012/04/01/xubuntu-rebasing-on-debian/
#ubuntu-release 2013-03-25
<cjwatson> phillw1: You don't need to do anything as far as I know; one passes the full URL to zsync
<cjwatson> phillw1: but this is not a channel for help setting up mirrors
<phillw1> cjwatson: I know, but there is about zero info on setting up zsync,
<cjwatson> phillw1: That's because it requires no setup
<cjwatson> That's kind of the point
<phillw1> cjwatson: yeah, I guess it is :) The server 'knows' zsync, all I need to do is go ask it from my local machine to do an update?
<cjwatson> phillw1: The server doesn't know anything because it doesn't need to.  The point of zsync is that it involves only fetching over plain HTTP
<cjwatson> phillw1: See the zsync man page
<phillw1> cjwatson: I'll have a read of it, but as the server uses zsync to update via, i guess all I need to do is amend the zsync command from E.g. of zsync http://cdimage.ubuntu.com/lubuntu/daily/20130324/raring-alternate-amd64.iso.zsync
<phillw1>  to point to the local mirror?
<cjwatson> phillw1: Yes
<phillw-virtual> sorry, cjwatson net splits are a pain.
<phillw-virtual> thanks a bunch, as always. I'm just going to let my phillw log off and time out. It's not often I'm thankful that I am running VM tests with its own Freenode registered account :)
<slangasek> cjwatson: so the other wubi bug was https://bugs.launchpad.net/wubi/+bug/1134770
<ubot2> Launchpad bug 1134770 in wubi "Wubi fails to detect 12.04.2 and 13.04 AMD64 ISO" [Undecided,Confirmed]
<cjwatson> that's the one
<cjwatson> the vmlinuz vs. vmlinuz.efi thing
<cjwatson> that one at least is probably not hopelessly difficult for somebody to fix if they check with us
 * slangasek nods
<cjohnston> Do I need to file a bug to get https://code.launchpad.net/~chrisjohnston/ubuntu/raring/django-openid-auth/release-0-5/+merge/155330 into raring? It's an upstream release of a bunch of bug fixes.
<ScottK> cjohnston: You need so subscribe ubuntu-sponsors for review.
<cjohnston> ScottK: ok. ty. I wasn't sure if it needed a bug.
<ScottK> If it has new features it will need an FFe and that's in a bug.
<ScottK> No features, no bug needed.
<cjohnston> Unless you consider working a feature ;-)
<debfx> do I need a FFe for turning ruby-bundler into a transitional package to bundler?
<debfx> ruby-bundler is an outdated Ubuntu-only package
<ScottK> debfx: It needs to go through no.  Or if you do, I wave my magic wand over it.
<ScottK> Err, just imagine I said no.
<debfx> alright, thanks
#ubuntu-release 2013-03-26
<ogra_> argh ... amd64 and i386 dont use the same live builder ?
 * ogra_ curses 
<ogra_> cjwatson_, do you know if the livefs builders are multiarch enabled by default ?
 * ogra_ just noticed he needs an amd64 livefs builder but some i386 packages for the android builds ... 
<ogra_> ... and indeed i filed a wrong RT assuming the i386 and amd64 builders are the same
<cjwatson_> ogra_: No idea, but they typically do the actual live build in a chroot.  Which i386 packages do you need?
<ogra_> a whole bunch ... https://wiki.ubuntu.com/Touch/Porting#Set_up_your_development_environment
<ogra_> what i'm doing atm is just adding a script similar to livecd.sh to livecd-rootfs that does all the bits ... so i only need to adjust $COMMAND in BuildLiveCD
<ogra_> http://paste.ubuntu.com/5649288/
<cjwatson_> Urgh!  Please pretend livecd.sh doesn't exist
<cjwatson> So the right answer for that is for there to be a separate chroot for building Android images
<ogra_> i dont want to hack all this directly into BuildLiveCD
<cjwatson> Sure, just don't use livecd.sh as an example of anything
<ogra_> no, only the elif code in BuildLiveCD that switches $COMMAND
<ogra_> i didnt plan to revive it :)
<cjwatson> Yeah, that's probably inevitable
<ogra_> similar switch to UBUNTU_DEFAULTS_LOCALE ... but then using "COMMAND="/usr/sbin/ubuntu-touch-android.sh ${SUBARCH}"" ... which is the above paste
<ogra_> though assuming i'm in a chroot thats $current_dev_release multiarch should be fine ...
 * ogra_ should probably add a "dpkg --add-architecture i386" to the script though ... 
<vibhav> hmm
<vibhav> We have an outdated topic
<vibhav> cjwatson: Could you change Archive: Open to Archive: Closed?
<cjwatson> vibhav: it's not closed
* cjwatson changed the topic of #ubuntu-release to: Ubuntu 12.10 and 12.04.2 released | Archive: feature freeze | Raring Ringtail 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
<jodh> could someone take a look at my latest comments on ffe bug 1155205 as they may merit re-approval of that bug before upload.
<ubot2> Launchpad bug 1155205 in upstart (Ubuntu) "FFE Request for Upstart in raring" [Undecided,Triaged] https://launchpad.net/bugs/1155205
<vibhav> cjwatson: My fault, I was quite sleepy at the time
<vibhav> yes, freeze
<slangasek> bdmurray: what do you think about the last comment on bug #586462?
<ubot2> Launchpad bug 586462 in pam (Ubuntu Lucid) "/sbin/pam_tally2 not included in package" [Medium,Triaged] https://launchpad.net/bugs/586462
<bdmurray> slangasek: I'm fine with it being SRU'ed again I guess
<slangasek> bdmurray: do you feel like doing expedited processing if I reupload it?  Otherwise I probably won't bother
<bdmurray> slangasek: I could do that
<slangasek> ok
<stgraber> hey there, any archive admin around with a minute to bin-new upstart?
 * stgraber wants to close bug 1155205 (wasn't listed in changelog, so needs manual monitoring)
<ubot2> Launchpad bug 1155205 in upstart (Ubuntu) "FFE Request for Upstart in raring" [Undecided,Triaged] https://launchpad.net/bugs/1155205
<slangasek> jodh: ^^ please close bugs in the debian/changelog when uploading :)
<slangasek> stgraber: I'll have a look
<stgraber> slangasek: thanks
<slangasek> stgraber: done
<stgraber> slangasek: thanks, I'll wait for it to publish and close the FFe bug
<slangasek> stgraber: seems unnecessary to wait IMHO
<stgraber> slangasek: ok, closing now then (won't complain about having one less thing to monitor ;))
<jodh> slangasek: ack - noted for next time :)
<slangasek> bdmurray: pam reuploaded to lucid-proposed
<doko> xnox, hmm, how do I re-add the raring task for bzr in 1116079?
<infinity> You can't readd a task if someone deleted it.  LP bug.
<infinity> Not that it needs a raring task anyway, the parent task will be closed on an upload to raring.
<bdmurray> slangasek: qdiff doesn't seem very useful for reviewing it
<bdmurray> slangasek: a new version of apt was uploaded to P for bug 923876, is the same change necessary for Q?
<ubot2> Launchpad bug 923876 in aptitude (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [Undecided,Confirmed] https://launchpad.net/bugs/923876
<infinity> bdmurray: The Q one was superseded by a security update, I'll rebase and reupload (with the subsequent fix that was in P) this week.
<bdmurray> infinity: great, thanks
<slangasek> bdmurray: the same change is applicable to Q; I've been lax in getting it uploaded
<slangasek> bdmurray: qdiff> yeah, I imagine the diff just shows the changelog, which would be what we want?
<bdmurray> slangasek: well, yes it confirms you didn't make any other changes other than the one from the last SRU
#ubuntu-release 2013-03-27
<RAOF> doko: Re bug# 1088771 - I still see two python2.7 uploads in the precise-unapproved queue, not a single merged upload?
<xnox> doko: sorry, lp doesn't let one do that =( noticed the update.
<ScottK> doko and xnox: It's an open LP bug that you can't re-add a deleted task.
<popey> ScottK: what can we do to move bug 1126205 forward?
<ubot2> Launchpad bug 1126205 in libdbusmenu-qt (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205
<ScottK> popey: I'm not at all convinced it should move forward.
<popey> obviously we want to minimise the impact and not raise other issues..
<ScottK> Fundamentally, we moved feature freeze later in the cycle for feature work to get done before it.  We said up front we'd generally say no after that.
<ScottK> So far this one seems not entirely well thought out and I'm not sure the long term implications make it worth while.
<seb128> that's an user visible regression though
<seb128> qt apps stop having their menus integrated
<ScottK> That's a separate issue.
<seb128> you could argue it was a mistake to land qt5 with the regression and it's a bugfix
<ScottK> This is about having support extended to Qt5 where it's never existed.
<ScottK> No, it's a mistake not to have ported appmenu and libdbusmenu to Qt5 properly.
<seb128> qt5 est just a new version of qt
<ScottK> Re-adding the Qt4 design to Qt5 is a gross hack.
<seb128> well, there is no room to re-implement that before release
<knome> are we freezing tomorrow as planned?
<stgraber> knome: I was hoping for some more release team members to reply to my thread on ubuntu-release@lists.u.c but as it stands, based on current input (mine and ScottK), I'd go with being conservative and freeze tomorrow at 21:00 UTC
<Riddell> ScottK: yes mediacentre is separate application from active, but I'm thinking it would be useful to run on tablet type devices
<Riddell> it's not a complete desktop shell as far as I've seen it
<ScottK> I see.  OK then.
<knome> stgraber, ok, thanks
<ogra_> stgraber, i would have commented (since i think your proposal is sound) but i'm not in the release team
<JackYu> cjwatson: We have uploaded our changes on ubuntukylin-default-settings package. Would you please upload your change and rebuild an iso for testing?
<cjwatson> JackYu: livecd-rootfs uploaded, thanks - will rebuild a bit later
<JackYu> cjwatson: great, thank you:)
<ScottK> seb128 and popey: I approved it.
<seb128> ScottK, thanks!
 * popey hugs ScottK 
<ScottK> popey: Please note that there's a draft "S" schedule out there.  Feature freeze is tentatively August 22nd.  Please plan to land stuff well before then.
<popey> ScottK: noted
<Daviey> I am right in saying that a *.changes for an SRU that includes two deb versions, say a merge.. must be done with debuild -v, for the bug tasks to be handled appropriately ?
<ogra_> Daviey, right
<ogra_> (not sure about bug tasks specifically, but thats a general rule for merges)
<Daviey> That was my thinking, but someone reported tey saw some cleverness with bug numbers being handled from -proposed to -updates.
<xnox> Daviey: there is  some cleverness. But it's best to create correct .changes. I started to call $ debuild -v`oldver`, where oldver is this script http://paste.ubuntu.com/5652578/
<xnox> works very quickly, correctly queries target release for me & generates correct .changes for me =)
<cjwatson> Daviey: almost all the problems with not using -v are fixed
<cjwatson> pending-sru tracks them and the bugs *usually* get closed
<Daviey> xnox: yes, i do the same.  I referenced it on ubuntu-devel last year. :)
<cjwatson> the one case I'm aware of where it still doesn't work properly is when the package was not previously in -updates
<Daviey> cjwatson: So is debian/changelog parsed back to creation ?
<cjwatson> in that case LP won't properly close the bugs from intermediate versions on copy to -updates
<cjwatson> Daviey: back to either the last version in -updates if there is one, or failing that only the most recent entry
<Daviey> it parses back to <= lasyt published version?
<Daviey> ok, thanks
<cjwatson> so, IOW, you should use -v if the package was not previously in -updates as an LP bug workaround; otherwise you don't need to bother
<Daviey> cjwatson: Well, i was more wondering if it's required to reject SRU's not uploaed with -v
<cjwatson> Daviey: proper use of -v will never hurt, though
<ogra_> using -v also helps people that just read the -changes ML :)
<cjwatson> ogra_: I think that's also fixed except for the caveat above
<ogra_> ah, cool
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/1102870 is the remaining bug here
<ubot2> Launchpad bug 1102870 in launchpad "Copies use naÃ¯ve ancestry check to calculate previous version for notifications and bug closures" [High,Triaged]
<cjwatson> Daviey: I started trying to fix this type of bugs precisely because it really annoys me to have to reject SRUs for trivial things like that :)
<ogra_> whhee, with UTF-8 fun in the title
<Daviey> I wrote parsing for sru-accept based on using the uploaded *.changes.  It does break that :)
<cjwatson> I don't see that in lp:ubuntu-archive-tools ...
<Daviey> cjwatson: I just wrote it this morning, not yet committed
<Daviey> but i'll change the logic now.
<cjwatson> Daviey: then you should just iterate back over all the changes back to the last published version - there's an example of doing that somewhere else in u-a-t
<Daviey> cjwatson: I did that elsewhere, i have code for that
<cjwatson> sru-report does it.  I think sru-release may need it too
<cjwatson> Daviey: I would say, if the package is already in -updates you're definitely safe; if not, you're safe if all the bug numbers are only in the most recent version; otherwise I might do something like reject but regen the .changes locally with -v and reupload for them
<Daviey> cjwatson: Well, i was looking to put this functionally into queue, as 'sruaccept'
<cjwatson> otherwise it's just kind of an annoying round-trip
<cjwatson> Daviey: mm, I was wondering if it should be a separate tool to drive the whole review process - bdmurray has a work item for that somewhere ...
<cjwatson> it should at least be library functionality that could be used by such a tool, IMO
<Daviey> Oh he does?  I was mainly doing this because it sucks to parse for bug numbers by hand.
<cjwatson> well, queuediff does that for you :)
<cjwatson> but yeah, it's not entirely ideal
<cjwatson> Daviey: it's on https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-sru-queue-velocity
<cjwatson> if you wanted to write a review tool I suspect he wouldn't mind :)
<Daviey> bdmurray: Have you been able to touch this at all?
<bdmurray> Daviey: the review tool, no not yet
<Daviey> bdmurray: I might scratch an itch, if it helps you along - feel free to use it.. otherwise replace it. :)
<cjwatson> Daviey: I would say a good first step would be, rather than adding "queue sruaccept", change sru-accept to be able to accept the upload and snarf bug numbers out of it before it does the bug processing
<cjwatson> It makes a bit more sense that way round to me, as queue is kind of supposed to be a pretty thin wrapper around the LP queue operations
<cjwatson> And I think it's equivalent work, possibly even a bit easier
<Daviey> cjwatson: well, I was starting to through stuff into an sru-common.py, which does the lifting.. then it can be driven from sru-accept or queue - as preference.
<Daviey> throw*
<cjwatson> yeah, that probably makes sense
<cjwatson> I'm all for libraries
<xnox> cjwatson: is desktop respinning or still not fully fixed/ready to be respun?
<cjwatson> respinning
<xnox> ack.
<cjwatson> I'm doing all the ones that failed today, meetings permitting
<stgraber> cjwatson: so I think I'll add that rebuild field to the tracker DB in the next release (maybe for 13.04 still, most likely early 13.10). By default it'll be set to "0" (no rebuild needed), "1" will be rebuild-requested and "2" will be rebuild-in-progress. There will be an authenticated API call to retrieve the list of requested rebuilds and another call to update the status from "1" to "2".
<stgraber> cjwatson: from the UI point of view, we'll get two buttons, one to request a rebuild and one to cancel a rebuild request (only possible when state = "1" as if it's "2", it's too late to cancel)
<cjwatson> stgraber: sounds good, thanks
<cjwatson> for those who weren't on the mumble call in question: this is a plot to make it easier for us to mass-rebuild images by piggybacking on ISO tracker status, and to kill two birds with one stone by using this to implement a way for flavour admins to get a respin by pushing a button on the tracker and waiting for a frequent cron job
<cjwatson> blam.  publish-release now in Python.
<cjwatson> infinity: so I see you're on duty for publishing beta-2 next week; it might not be a terrible idea to make sure I'm around for the actual publish-release step, since this'll be the first real-world test of that new code and I may have to fix the odd thing up on the fly
<infinity> cjwatson: Fun, fun.  WCPGW?
<cjwatson> exactly
<cjwatson> I've unit-tested at least some cases
<cjwatson> ok, all the other images that failed earlier are respinning now
<cjwatson> (ubuntukylin, xubuntu, wubi, zh_CN)
<cjwatson> and I'm going out
 * slangasek waves
<stgraber> utlemming: finally found some time to look into that SSO issue with the QA tracker, hoping to get a fix or at least a clue as to what's going wrong this afternoon
<utlemming> stgraber: k, let me know, and I'll be happy to do tests
<stgraber> utlemming: current plan is to dump the xml of the whole openid authentication sequence and check whether it's the tracker not requesting the team membership info or if it's the SSO service sending a partial reply
<stgraber> utlemming: can I get you to try logging in again?
<utlemming> stgraber: interesting...I saw the team option
<stgraber> utlemming: it appears to work fine with my test account here (had to tweak a regexp, I'm suspecting it was eating part of the team name)
<utlemming> stgraber: and now I see the aministration tag
<stgraber> utlemming: ok, are you granted the matching rights? (do you see checkboxes next to images and an Administration link in the menu)
<stgraber> ok, cool
<stgraber> so looks like that's one problem solved
<utlemming> stgraber: yeah, this looks good
<utlemming> thanks :)
<stgraber> and I tested the API with up to 20 teams and it still works, so apparently SSO itself does the right thing
<stgraber> ok, so now I can setup access for the Kylin folks
<stgraber> utlemming: can you remove my test account from the cloud images release team?
<utlemming> stgraber: sure
<stgraber> gave myself a WI on foundations-r-future-release-infrastructure to add the required QATracker bits so we can do the whole nusakan<->tracker respin magic
<stgraber> (targeted to end of April)
<marrusl> Hi release folks... can I ask someone to look at approving alsa-utils in both the quantal and precise queues?  as crazy as it sounds, it's actually blocking some people.  :)
<marrusl> that, and it's really, really a nothing patch.  :)
<stgraber> marrusl: you want the SRU folks actually ;) (but same channel and definitely quite a bit of overlap between the two teams)
<marrusl> stgraber, ah!  good point.  hey, at least I got the right channel. ;-)
#ubuntu-release 2013-03-28
<micahg> FYI, whoever is driving Beta 2, I've got a few uploads that I won't be able to finish until after work tomorrow which will be a few hours past the freeze, it's either Xubuntu specific stuff (xubuntu-docs, gtk-theme-config) or catfish which Studio can pick up on a respin if it happens
<micahg> so, please don't bother kicking off Studio beta 2 images until I get that stuff in
<micahg> oops, I meant Xubuntu
<micahg> I'll see if someone else has time before the freeze
<doko> RAOF, ^^^ now merged as well
 * cjwatson builds kubuntu/precise/daily-live again after a cdimage fix
<cjwatson> cdimage is now entirely in Python (apart from some remaining horribleness in etc/config), so hopefully that's the end of the upheavals
<vibhav> cjwatson: What does " melior malum quod cognoscis" mean? :)
<ogra_> it means "use google translate"
<xnox> ogra_: that doesn't help though.
<stgraber> better the evil you know
<vibhav> ogra_: yeah, gogle translate doesn't work
<vibhav> stgraber: is it latin?
<stgraber> yeah
<vibhav> ah okay
<ogra_> "Better the evil you know"
<ogra_> thats what google translate gets me here
<vibhav> Google translate thought its italian, but anyway, thanks
<ogra_> you guys dont have latin as your first language set by default ?!?
 * ogra_ shakes head
<ogra_> where did the world go ...
<ogra_> *g*
<vibhav> heh
<ogra_> oh, wow, unpacking the chromium package source on my chromebook only took 25min ...
<stgraber> well, that specific sentence should be easy enough for any french speaker with vague latin knowledge to translate without needing google ;)
<stgraber> ogra_: are you planning on building it on there?
<ogra_> probably ...
<ogra_> for now i just wanted to look why it doesnt find stdio.h
<ogra_> and if v8 is probably easy to disable to at least get it building
<ogra_> some little easter project :)
<davmor2> stgraber: or any private schooled child in the uk who is still taught latin for some reason :)
<ogra_> not really planning on anything though ...
<ogra_> LOL !
<ogra_> libc6-dev-i386 [amd64],
<ogra_> so what could probably go wrong trying to build it on armhf here
<ogra_> (no, there is no other libv6-dev entry at all in the deps)
<cjwatson> "better the devil you know" is a more idiomatic English translation
 * ogra_ cant belive that nobody who looked at chromium hasnt catched that before 
<ogra_> i know several people spent hours trying to get it to build
<cjwatson> it's a comment on risk management: given a current known state with problems, and a possible future state with unknown problems, the current state may be better despite the problems
<cjwatson> ogra_: err, libc6-dev is build-essential
<ogra_> well
<ogra_> v8/src/../include/v8stdint.h:34:19: fatal error: stdio.h: No such file or directory
<ogra_> compilation terminated.
<ogra_> thats the build error
<cjwatson> sure, but the fix is not to add libc6-de
<cjwatson> v
<cjwatson> that looks more like a broken include path or something
<xnox> davmor2: or any average Finish school as per Linus' last g+ rant/blog post =)
<ogra_> #include <stddef.h>
<ogra_> #include <stdio.h>
<stgraber> davmor2: oh, they stopped teaching it in public school over there? I still had Latin and Ancient Greek as part of the standard classes in Switzerland (public school)
<cjwatson> we need to explicitly build-depend on libc6-dev-i386 since it isn't build-essential, but it is strictly wrong to explicitly build-dep on libc6-dev
<ogra_> not relly redefined ot something
<cjwatson> like I say, more likely a busted include path
<xnox> stgraber: it was gone a long time ago from typical curriculum.
<cjwatson> perhaps it's building for a different target there
<ogra_> ah, yeah, the build log shows it being installed
<cjwatson> in any case you can see at the top of the build log that libc6-dev is installed, along with libc6-dev-armel
<ogra_> yep
<cjwatson> it's already in the base chroot, it's just upgraded in the build log
<ogra_> gyp: /var/tmp/builddeb-get-source-nCb6ts/export/chromium-browser-6169/src/build/common.gypi not found (cwd: /build/buildd/chromium-browser-25.0.1364.160/src) while reading includes of build/all.gyp while trying to load build/all.gyp
<ogra_> make[1]: *** [Makefile] Error 1
<ogra_> aha
<stgraber> xnox: that's unfortunate. The combination of Latin and Ancien Greek is very useful when learning additional languages and to understand a few works of languages you've never seen before.
<xnox> stgraber: true. I never did latin nor greek =(
<cjwatson> I wasn't privately-schooled and Latin was still on our default curriculum
<cjwatson> I've found it very useful for understanding languages, as stgraber said.  Could do with having Ancient Greek too but ENOTIME
<stgraber> cdimage people, while working on the image based upgrades I've written a simple python tool that diffs squashfs images. I guess this may come up handy when we're wondering what changed between images.
<stgraber> Example output is: http://paste.ubuntu.com/5655298/
<stgraber> the tool simply takes a source and target squashfs, mounts them both and walks the whole tree doing a sha1sum of everything it sees, then gives the list of additions/changes/removals
<cjwatson> Yep, would be useful; MP against lp:ubuntu-cdimage? :)
<cjwatson> Although cdimage doesn't have root
<cjwatson> I don't suppose it can be done with the userspace tools?
<cjwatson> I guess not, there's no lssquashfs, you'd have to unsquashfs the whole thing
<stgraber> yeah and that'd be pretty bad performance-wise
<stgraber> so not something we can easily run on nusakan, but easy to use on our own machines
<FourDollars> bdmurray: Could you help me to review https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
<ubot2`> Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed]
<bdmurray> FourDollars: review as in upload or review as in approve from the SRU queue?
<FourDollars> bdmurray: I don't know what is the next step.
<bdmurray> FourDollars: it looks like upload and I can probably do both
<FourDollars> bdmurray: That will be great. :)
<ogra_> cjwatson, http://paste.ubuntu.com/5655397/ does that look ok to you ?
<ogra_> ^^^ or infinity
<cjwatson> looks mostly plausible
<cjwatson> the multiarch setup is wrong though
<cjwatson> use 'dpkg --print-foreign-architectures' rather than grepping /etc/dpkg/dpkg.cfg.d/multiarch
<ogra_> oh ?
<ogra_> ah, right, that fails on my precise test machine :)
<cjwatson> $ dpkg --print-foreign-architectures
<cjwatson> i386
<ogra_> had it for testing
<cjwatson> yeah, but dpkg --add-architecture would fail on precise too :)
<ogra_> yeah, exept that i have i386 indeed :)
<ogra_> in multiarch
<cjwatson> IOW you're mixing old and new styles there
<ogra_> yup
<cjwatson> you also need to edit debian/install
<ogra_> uh, oh, thanks !
<cjwatson> I think the rest is fine
<cjwatson> and of course you'll need an RT to update BuildLivecD
<cjwatson> with correct capitalisation
<FourDollars> bdmurray: Is there anything else I should do for https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/1160414 ?
<ubot2`> Launchpad bug 1160414 in ibus-chewing "Use shift keypress to switch to English mode." [Undecided,Confirmed]
<bdmurray> FourDollars: no, I'll handle the rest
<ogra_> cjwatson, that can wait until i have the firewalls open ... cant test before anyway
<FourDollars> bdmurray: Thanks a lot.
<ogra_> (in the real env)
<ogra_> cjwatson, http://paste.ubuntu.com/5655424/ updated
<cjwatson> yep, looks better
<cjwatson> feel free to ask if you want me to do the cdimage side
<ogra_> k, committing and merging
<cjwatson> since that's all rewritten from what you're likely familiar with
<ogra_> well, do you think its a quick job for you ?
<ogra_> else i'll try it myself and move the WI to next month
<cjwatson> should be pretty quick if I know what all the filenames are and what the expected output is
<ogra_> at some point i have to get familiar with the new code ... not sure thats the right moment though
<ogra_> cjwatson, the output files will be cm-10.1-${iso_date}-UNOFFICIAL-${subarch}.zip
<cjwatson> back in ~30mins, picking bike up from shop.  live filesystem downloading is in lib/cdimage/livefs.py, depending on what you're doing you may also need to adjust lib/cdimage/build.py, and publication is in lib/cdimage/tree.py; test code in lib/cdimage/tests/ and ./run-tests.  if you want to look in that half an hour then feel free, otherwise I'll look when I get back
<ogra_> i.e. cm-10.1-20130328-UNOFFICIAL-mako.zip
<ogra_> ok
<ogra_> plars, looking at https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds i assume your WI is for next month ? (just miving mine around, happy to do that for yours too)
<plars> ogra_: ah, it had the wrong lp id so I haven't even seen this one
<plars> ogra_: I've actually got that all covered in another BP
<ogra_> well, not sure who added it there :) should i rip it out ?
<plars> ogra_: I think so, it's already covered elsewhere for desktop, and I'm getting IS to fix the firewall rules at the moment
<plars> ogra_: probably it will happen next week. For touch I'd still like to sync up with sergiusens a bit on it, but he's going to be doing basically the same thing from a different jenkins for that image
<plars> ogra_: and I don't think the desktop stuff fits in a bp for android builds :)
<ogra_> next week is next month ;)
<ogra_> plars, we wont buuild on jenkins anymore once that BP is implemented
<ogra_> -u
<ogra_> (thats the whole point of it)
<plars> ogra_: yes, but the tests run out of jenkins
<plars> ogra_: and that's what will trigger the transition
<plars> ogra_: the ones I have are in https://blueprints.launchpad.net/ubuntu/+spec/qa-r-staging-iso-testing
<ogra_> i'm not so sure we can even test the android images in jenkins ...
<plars> ogra_: it will just cover a few images at first, and move on to more as we have smoke coverage for them
<ogra_> do you have any automated tests runing on the HW ?
<plars> ogra_: we have automated tests running on the ubuntu touch images right now if that's what you mean
<ogra_> for the android side ? or just for the ubuntu container content ?
<plars> ogra_: I don't think anything specifically targets the android specific bits - sergiusens might have something but we don't
<ogra_> right ... we should work something out for this ...
<plars> indeed
<ogra_> since i belive the android side is totally uncovered atm
<ogra_> dropped the desktop item from the WI list for now
<ogra_> fo android testing i think we need a separate spec for later (not right now though)
<cjwatson> ogra_: if we can automatically test them anywhere, we can test them in jenkins - since jenkins typically just farms out tests to slaves
<ogra_> cjwatson, yes, but it needs HW backing
<ogra_> and i doubt there is anything set  up
<ogra_> the specific WI above was clearly stating desktop isos thogh
<ogra_> which is why i removed it from that spec ... (and plars seems to cover it in his other spec already)
<cjwatson> well, uh
<cjwatson> the *original* WI was for touch
<ogra_> oh
<cjwatson> we embraced and extended it for desktop because that could be done first
<plars> cjwatson: it still includes a WI for the touch image, assigned to sergiusens
<ogra_> let me put it back then and rephrase a bit
<plars> [sergiusens] Update PS Jenkins to poll cdimage and trigger /pending update on Touch images once smoke tests pass: TODO
<ogra_> yep
<cjwatson> ah, yes, that way round.  the desktop WI is fine in the qa spec
<ogra_> oh, and its exactly the same text
<ogra_> with s/Touch/Desktop/
 * ogra_ leaves it as is then ... waiting for feedback from sergio to move his WI to month-6 too
<ogra_> sorry for all the mail spam ... i wish we could restrict that to WI owners and the approver or so
<cjwatson> ogra_: any luck with cdimage or would you like me to look?
<ogra_> cjwatson, had a little cat emergency here, didnt even get to look at it yet
<ogra_> so yes, if you dont mind ... else i'll make it my easter task (have nothing palanned there anyway)
<ogra_> *planned
<ogra_> we cant really test it in production yet ... until the IS bits are done, so if you have something more urgent to do, dont bother
<cjwatson> s'what the test suite is for :)
<cjwatson> in "cm-10.1-20130328-UNOFFICIAL-mako.zip", which bits are variable and based on what?
<cjwatson> also can you make there be symlinks so I don't have to guess the livefs-side build id?
<ogra_> makoi is the subarch ... (at least thats how i planned it)
<ogra_> *mako ...
<cjwatson> so there's one livefs build for each subarch?
<ogra_> yeah
<cjwatson> (mentally substitute something more appropriate for "livefs")
<ogra_> maguro mako grouper manta
<ogra_> thats the list of subarches we'll build for now
 * plars can't help but apply the linaro concept of hwpack here
<ogra_> plars, well, yeah, it kind of is a hwpack
<ogra_> theoretically they are "targets" ... not even arches ...
<ogra_> and practically they are armel+$subarch ... as android builds arent armhf
<ogra_> very chaotic ...
<ogra_> plars, hmm, not even "kind of" ... it *is* a hwpack
<cjwatson> it'll be much less painful to refer to them as subarches within cdimage
<plars> ogra_: yeah, but it's hard to make that shift given that hwpacks were something we did for the ubuntu images, not android
<ogra_> since the rootfs we use on top is totally HW independent
<plars> ogra_: but yeah
<ogra_> cjwatson, right, thats why i used that term :)
<cjwatson> since that already has the right arch+subarch representation
<ogra_> well ...
<ogra_> we dont really have armel
<ogra_> (anymore ... officially ... blah blah ... )
<cjwatson> cdimage doesn't care about that :)
<cjwatson> it's certainly a little exciting that this is armhf on top of armel+blah, but I'm sure we can cope
<ogra_> yup, i know ... but i know i'll have to answer silly questions about it :)
<ogra_> (already had)
<ogra_> the rootfs build will be intresting though ... i think its the first time we build armhf without any subarch
<ogra_> will show us all the corner cases in teh code where we assumed there will always be a subarch
<ogra_> (though i guess these are rather in debian-cd than in cdimage)
<infinity> ogra_: It's not the first amrhf without subarch, there's core.
<ogra_> oh !
<ogra_> totally forgot that one
<ogra_> and we should actually be able to re-use all its code for touch rootfses ... since they dont need any post processing for bootability
<davmor2> hey guys is the latest iso missing the secureboot stuff?
<cjwatson> davmor2: not that I know of, --verbose
<davmor2> cjwatson: I've just tried an install on my ideapad Y580.  I get the EFI boot menu from the cd, the install went fine on reboot it says "Ubuntu has been blocked by the current security policy."
<cjwatson> would need to see installation logs to see if it remembered to install the right things
<davmor2> cjwatson: can I get those from a live cd or not?
<cjwatson> sure, mount your installed system and look in /var/log/installer/ within it
<davmor2> cjwatson: that's fine then give me a few minutes
<davmor2> xnox: was the webcam page removed from the install process too out of interest?
<cjwatson> ogra_: is "cm-10.1" a constant string?  what does it mean?
<cjwatson> davmor2,xnox: yes, intentionally
<ogra_> cjwatson, cyanogenmod 10.1
<davmor2> cjwatson: ah that's fine
<cjwatson> ogra_: presumably that might change at some point in the future?
<cjwatson> should it be tied to Ubuntu series or something?
<ogra_> cjwatson, if we bump to a newer cyanogenmod, yeah
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/
<ogra_> thats how we call them in the end
<ogra_> quantal-preinstalled-armel+$subarch.zip
<cjwatson> Right.  I wonder if it would be smarter to create symlinks on the livecd-rootfs side then?
<ogra_> yeah ...
<cjwatson> Since we need symlinks to avoid cdimage needing to guess the build ID anyway
<ogra_> oh hmm, might be that i will have to extend livecd-rootfs later anyway ...
<ogra_> i currently dont take "boot", "system" and "recovery" into account
<davmor2> cjwatson: it's been a while /var/log/installer/syslog anything else you need
<ogra_> not that they are overly important atm
<cjwatson> davmor2: that'll do for starters.  (note I'm about to finish for Easter, it may not be a good idea to assume I'll be able to deal with it right now)
<cjwatson> ogra_: doesn't phablet-flash use them?
<davmor2> cjwatson: I'll be happy with a debug for now :)  I can use my non-uefi system without issue till it is fixed :)
<cjwatson> But yeah, it would be nice if livecd-rootfs could just create "quantal-preinstalled-armel+*.zip" symlinks
<cjwatson> or raring- of course
<ogra_> cjwatson, phablet-flash only uses quantal-preinstalled-armel+$subarch.zip and the rootfs zip
<ogra_> the others are for use with fastboot directly
<ogra_> if you tinker manually with the device ...
<ogra_> (phablet-flash works on the adb level, doesnt touch fastboot/bootloader mode)
<ogra_> i'll fix my script to provide them from livecd-rootfs but dont bother with them yet
<davmor2> cjwatson: http://ubuntuone.com/7AYGMhTAuDswfLCCn9y8W5
<ogra_> done ...
<cjwatson> davmor2: Well, it installed the right pieces, but looks as though there's something wrong with either the kernel or your firmware, perhaps?
<cjwatson> Mar 28 17:12:54 ubuntu kernel: [  716.795993] efivars: set_variable() failed: status=8000000000000009
<cjwatson> then a couple more of those and then
<cjwatson> Mar 28 17:12:57 ubuntu ubiquity: Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting
<cjwatson> So I think that probably confused the installer into not installing SB pieces
<cjwatson> It just installed the right *debs*
<cjwatson> I *think*.  It's a little hard to tell
<davmor2> cjwatson: I'm assuming a trip to #ubuntu-kernel is possibly in my near future then :)
<cjwatson> livecd-rootfs actually calls its symlinks livecd.ubuntu.squashfs and that kind of thing
<cjwatson> Or things like livecd.ubuntu.kernel-generic when it needs additional information
<cjwatson> It might not be a terrible idea to try to line up with it, although it's not required
<ogra_> cjwatson, well, i dont want to keep the 20G build tree around ...
<cjwatson> I don't see how the build tree is relevant ...
<ogra_> i need to copy them out there
<ogra_> before wiping it
<cjwatson> I meant symlinks to cm-10.1-20130328-UNOFFICIAL-mako.zip
<cjwatson> Naturally you need to copy out to that
<cjwatson> However, please do make sure that at least your output directories and log files line up with how livecd-rootfs does things
<ogra_> right
<ogra_> livecd.ubuntu-touch-$timestamp-armel.$image-$subarch then ...
<ogra_> (for system, recovery and boot)
<ogra_> i'm not really sure how to call the actual zip though ...
<ogra_> just .zip ?
<cjwatson> Putting $subarch at the end wouldn't be uniform
<cjwatson> Well, sort of, I suppose
<cjwatson> Have a look at e.g. how cadejo is laid out
<ogra_> well, thats what i see on the other armhf builds
<ogra_> looking at nexus7 output atm
<cjwatson> They have livecd.ubuntu-$subarch.$image[-$kernel_flavour]
<cjwatson> Generally
<ogra_> oh, crap ... nexus7 is special ... the flavour name has the subarch in it
<cjwatson> The weird bit is that livefs subarch builds get the subarch tacked onto the project name; that's really for being able to build multiple subarches independently
<cjwatson> Which you want here as well
<cjwatson> So the full path would be something like /~buildd/LiveCD/raring/ubuntu-touch-mako/livecd.ubuntu-touch-mako.zip ?
<ogra_> yep
<cjwatson> The naming is a bit mad; it depends where you think it's better to put the extra complexity due to differences, really
<cjwatson> for system etc., I suppose you get to make something up
<cjwatson> Wouldn't be too unreasonable for it to be .system.zip or -system.zip
<cjwatson> Er, except it's .img, YKWIM
<ogra_> yeah, i had looked at n7 and made it -system.img-$subarch ...  i'll flip that around so it ends in system.img
<ogra_> livecd.ubuntu-touch-$codename.$image.img
<ogra_> thats what i have now
<ogra_> and livecd.ubuntu-touch-$codename.zip for the zip#
<ogra_> -#
<cjwatson> Yeah, I don't think this is really analogous to a kernel flavour, so best not at the end
<cjwatson> OK, sounds good
 * ogra_ commits and uploads new livecd-rootfs
<ogra_> i didnt make them links btw ... just changed the cp commands
<ogra_> or is there any reason to artificially have links for them ?
<ogra_> ah, BuildLiveCD creates them anyway, for the timestamps
<cjwatson> It might be useful to know the underlying cm-10.1- naming, but your choice
<ogra_> if its needed i can just add a link with the original name easily later
<cjwatson> Sure
<ogra_> i doubt there is any need for it ever though
<ogra_> and uploaded
<cyphermox> ScottK: re bug 1126205 ; just about done reviewing and getting everything to build and rebuild
<ubot2`> Launchpad bug 1126205 in indicator-appmenu (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205
<cyphermox> I'll upload qtbase-opensource-src in a minute, and then I'll start the builds for appmenu-qt and libdbusmenu-qt in didrocks' daily release jenkisn jobs... I'm just not sure how long that's goingto take exactly to build
<cyphermox> hopefully not long
<cyphermox> FYI, I'm waiting after jenkins / cu2d/ builds in the ubuntu-unity/daily-build PPA to complete to auto-release appmenu-qt and libdbusmenu-qt (to go with the bug above), those might be a little bit late
<infinity> (And before anyone suggests scoring them up, I already said I wouldn't do that, because security builds trump random attempts to beat arbitrary freeze deadlines, but I'm fine with those PPA copies coming a bit late)
<seb128> infinity, you could score them between ordinary builds and security
<seb128> infinity, or you could just stop doing IRC during your days off ;-)
<infinity> They'll be fine.
<xnox> cyphermox: which qtbase-opensourse-src are you uploading? as staged in the lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src ?
<xnox> hmm... that looks released already.
<xnox> cyphermox: https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.1+dfsg-0ubuntu4 it's building already with appmenu support.....
<xnox> bah, that is your upload. and me fail to look at the clock =)
<cyphermox> yeah, that's my upload, and yes it comes from that branch precisely
<cyphermox> it was already in the branch and checked by didrocks, tested by sil as well
<xnox> and tested by me =) Yeah for GtkStyle fixes, to make qt5 apps non-ugly ;-)
<marrusl> me again... hat in hand....  would any SRU folks mind looking at the unapproved alsa-utils uploads in the precise and quantal queues for me?  They're really trivial changes, I know, but it's blocking for some people.
<infinity> marrusl: Sec.
<infinity> marrusl: Why the different CaSe sEnSiTivItY between precise and quantal?
<infinity> marrusl: Fairly sure that dpkg-gencontrol fixes that on the fly to be correct, but not positive.  Would be better to have it correct in the packaging.
<marrusl> infinity, weird and good catch.  I was always trying to be consistent before.  apparently not.  I don't mind resubmitting.
<infinity> marrusl: I'll commit the fix to bzr, forcefully mangle the tag, and reupload for you.
<marrusl> infinity, dpkg-gencontrol is something I would run manually?
<infinity> marrusl: No, dpkg-gencontrol being the thing run by dh_gencontrol that turns debian/control into package/DEBIAN/control in the binary packages.
<marrusl> infinity, ah.  thanks.  i see now.  still, no reason to have inconsistent source packages.
<infinity> Yup, already fixed.
<infinity> http://bazaar.launchpad.net/~ubuntu-audio-dev/alsa-utils/ubuntu.precise/revision/122
<infinity> And uploaded.  And will accept shortly.
#ubuntu-release 2013-03-29
<infinity> cjwatson: I vaguely recall it being discussed a week or two back, but did we decide if we were going to hard freeze with queue reviews, or just do some sort of massive britney block?
<infinity> cjwatson: (I actually prefer the hard freeze, honestly, the reviews are helpful, and a britney block could just lead to a ton of crap in proposed that we need to dump at release...)
<micahg> can someone please help chromium-browser ubuntu2 to the release pocket?
<vibhav> Sorry for cross posting, but the topic needs to be updates here too :)
<vibhav> (feature freeze->final beta freeze)
* infinity changed the topic of #ubuntu-release to: Ubuntu 12.10 and 12.04.2 released | Archive: Final Beta Freeze | Raring Ringtail 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
<ogra_> cjwatson, hmm, something is wrong with the cdimage publisher code ... the nexus7 desktop image /current link is stuck on an image from the 15th
<ogra_> cjwatson, hmm, seems to be even worse ... http://cdimage.ubuntu.com/daily-preinstalled/ has subdirs for the 15th, 26th and 27th but only the 15th is populated
<ogra_> the others are empoty dirs
<ogra_> weird, in the log i see it downloading the ext4 file ... but it doesnt seem to find it (and in fact its not in the preinstalled subdir on nusakan)
<ogra_> cjwatson, aha, seems the preinstalled filesystems end up in /srv/cdimage.ubuntu.com/scratch/ubuntu/raring/daily-preinstalled/live/ instead of /srv/cdimage.ubuntu.com/scratch/ubuntu/raring/daily-preinstalled/preinstalled/
<ogra_> ah, line 509 in livefs.py
<ogra_> (or rather 510 since it is wrapped)
<cjwatson> infinity: there was a thread on -release about that, I think - I haven't really been following
<cjwatson> ogra_: ok, give me a minute to have a look
<cjwatson> (holiday today so may get interrupted)
<ogra_> cjwatson, ah, i didnt even expect to see you around ... was just starting to quickly hack a "default_dir" var in to switch it for preinstalled :)
<cjwatson> I'd rather you didn't
<ogra_> yeah, quick hack ...
<cjwatson> There's really no reason to have a different path there
<cjwatson> I was deliberately trying to consolidate live and preinstalled, since the bulk of the differences there were entirely artificial
<ogra_> ah, so you fix it on the publisher side ... k
<ogra_> thats the part i hadn't looked at yet
<cjwatson> I hadn't realised that debian-cd cared
<cjwatson> It's like a single giant layering violation
<cjwatson> The reason it's safe to have it be .../live/ is that the image_type is always different
<cjwatson> So I'm just going to s/PREINSTALLEDIMAGES/LIVEIMAGES/g, basically
<ogra_> yeah
<cjwatson> Sorry for not noticing the failures
<ogra_> well, it was me not noticing it
<ogra_> and i still wouldnt have ... if there wasnt a user in #ubuntu-touch complaining about the n7 desktop images
<cjwatson> Just trying a fresh build now
<ogra_> well, essentially complaining about compiz still crashing in ubiquity-dm :)
<cjwatson> Urgh, what
 * cjwatson has broken something else, hang on a minute
<cjwatson> all hail pdb
<cjwatson> And it's broken really early which is why we haven't even been getting failure logs
<ogra_> the livefs builds look all fine, i dont think you need to re-do them ... unless you want to test buildlive
 * ogra_ sees proper rootfs.tar.gz for all of them
<cjwatson> No, I hadn't been planning to
<cjwatson> Ah, missing test
<ogra_> oh, the path was even hardcoded in CONF.sh
<cjwatson> Right, cdimage.config fixed (and test cases added); cron.daily-preinstalled running now
<cjwatson> I'm not likely to be around much more for several hours - if anyone wants to start builds of other things affected by the same problem (which won't have been everything - it was any project/image_type combination for which there was an open-ended series range in etc/default-arches), feel free, otherwise I guess cron will sort it out
<ogra_> yeah, lets leave it to cron
 * ogra_ didnt plan to work during his vacation either ... i would have added a hack to be ripped out on tuesday 
<cjwatson> ogra_: that seems to have worked
<ogra_> yep, and i see a /pending dir too now :)
 * ogra_ would dance ... but its good friday and i cant break the law :P (dance prohibition in germany) 
<ogra_> (its that one law that makes germans feel like americans :) )
 * skaet figures that as long as germans can drink beer on good friday, they can survive without the dancing ;)
<ogra_> skaet, haha, yeah ...
<skaet> :)
<ogra_> (some here call it footloose friday here :) )
<ogra_> -here
<ogra_> clubs make a lot of money though ... people tend to gather at 11 and the music starts at 12
<skaet> dancing starting at midnight hmm... in the US the equivalent is probably holiday shopping starting on the Friday after Thanksgiving.
<Trevinho> Hello, do we really need a FFe for this: https://bugs.launchpad.net/unity/+bug/1152477 ?
<ubot2`> Launchpad bug 1152477 in unity "[FFe] Window list in right click context menu should indicate the focused window" [Medium,In progress]
<Trevinho> it's a really minor change, involving no API change or string change
<ogra_> its a new feature ...
<ogra_> and the doc team will need to take it into accound in screenshots for example ...
<didrocks> ogra_: we do agree :)
<ogra_> its definitely a "just nod it off" FFe
<ogra_> buut nonthelsee an FFe
<didrocks> yep
<ogra_> *nontheless
<xnox> Trevinho: doesn't it now need a UserInterfaceFreezeException as well now?!
<Trevinho> xnox: it does not affect any screenshot or big ui change.
<ogra_> how do you know the docteam didnt make a screenshot of the right click menu ?
<Trevinho> ogra_: the right-click menu could not been affected in all the cases by this change
<Trevinho> ogra_: you need that the doc team has two-windows of the same app opened and one of them focused to notice a change
<ogra_> well, the process is to get the FFe nodded off and i think xnox is right that you also need the docteam to agree
<ogra_> its not like thats hard or anything
<Trevinho> ogra_: and the change would be trival anyway (not seeing a * in an item is really a small thing)
<ogra_> sure, still we're past freezes and there is a process for this ...  if the change is trivial it will go very fast ...
<Trevinho> ogra_: ok...
<ogra_> (the time you spent discussing it here might have been sufficient to mail the docteam ;) )
<Trevinho> ogra_: I only was asking this because in the past we never neded it for such trivial changes.
<infinity> cjwatson: Ahh, indeed, it was on the list.  I've followed up.  Thanks for having a slightly less swiss-cheesy brain.
<ogra_> infinity, so you got some sleep ?
<infinity> ogra_: I did!
<infinity> ogra_: It does happen once in a while.  Just not every night. :P
<ogra_> yay !
<infinity> (But last night, I actually slept, uhm... 5 hours?)
<infinity> Which, for me, isn't a bad stretch.
<ogra_> athst something at least
<ogra_> *that's
<Mirv> FYI I'm not sure what's the story behind qtpim upload at https://launchpad.net/ubuntu/raring/+queue?queue_state=0&queue_text= , but from my point of view it shouldn't have been uploaded (packaging is not complete, the organizer doesn't work at all without some patches I and a community member have submitted upstream etc)
<pgraner> infinity, can you trigger a rebuild for https://bugs.launchpad.net/ubuntu/+bug/1129949
<ubot2`> Launchpad bug 1129949 in ubuntu "corrupt package libgrail5_3.0.6-0ubuntu0.12.04.01_i386.deb on archive.ubuntu.com" [Undecided,New]
<ScottK> Mirv: Rejected.
<infinity> pgraner: Erm, wait.  What?
<pgraner> infinity, tiaz pinged me and asked that I do it, but I don't have the voodoo to make it happen
<infinity> pgraner: If the actual file is corrupt, we should just fix it.
<Mirv> ScottK: thanks
<infinity> (And if it is, that's worrying, to say the least)
<ScottK> Easy decision since there's no FFe.
<pgraner> infinity, I asked tiaz to join so you can talk to him :)
<infinity> tiaz: Yo.
<infinity> Why are we rebuilding packages to fix filesystem corruption?
<infinity> (And why do we have corruption at all?)
<tiaz> infinity: sorry, it occurred to me that I hadn't checked that we're still serving the bad package. I did confirm the one provided was bad
<tiaz> looking for it now, just a sec
<infinity> So, the one on pepo matches the librarian.
<infinity> Is it broken on syncproxy, or the archive frontends?
<tiaz> infinity: I think it was broken on the frontends and is no longer. the one I just fetched from a.u.c is correct, but I don't know which mirror I got it from. I'm going to pull it from all of them to make sure, but this may be a noop
<infinity> If you just make sure all the archive frontends (and syncproxy) match pepo, and artificially touch the package to futz the timestamp, it should cascase and fix all the mirrors.
<infinity> The timestamp/touch thing is essential, since most people don't rsync with sums (cause, ow, painful on a 0.5TB mirror), so if the file name/length/time don't change, they won't fix the file locally.
<infinity> I'll touch it on pepo now, so it doesn't revert on mirror pushes.
<infinity> All I can assume here is that one archive frontend broke, and it happened to be a parent to some other ccTLD mirror.
<infinity> Would be nice if we knew which frontend that was, since it could point at something much worse.
<tiaz> infinity: all the current mirrors are correct. I've touched them just in case, I'm now looking at if we had a different set when this was opened, just in case
<infinity> Oh, I didn't notice the bug was a month old.
<infinity> That makes it a bit harder to trace.
<infinity> Bother.
<infinity> tiaz: I assume you double-checked syncproxy too?
<tiaz> infinity: yeah
<infinity> Kay.  Well, no one should be rsyncing (or, in fact, allowed to rsync) from anything that isn't a child of one of the archive frontends.  So, if they're all happy, it should resolve itself.
<infinity> And, like I said, I futzed the timestamp on pepo, and that should bubble out to the world and force every mirror to re-sync the package for no reason. :P
<infinity> But that's still better than a whole new SRU for nothing.
<infinity> I do wish the original reporter had been a bit more verbose.
<tiaz> it would be really nice if they'd specified what mirror they got it from, yeah.
<cjwatson> For all we know it was from an apt proxy of some kind.
<cjwatson> And they only think it was corrupt on a mirror.
<infinity> Yep.
<infinity> But this quick touch faff isn't harming anyone.
<infinity> So, whatever.
<infinity> Belt and bracers.
<infinity> And such.
<cjwatson> Some versions of apt-cacher-ng, say, are REALLY good at corrupting packages
<cjwatson> Like the one in precise
<infinity> My apt-cacher-ng behaves quite well.  I must be lucky.
<cjwatson> (Yes, there's an SRU in train for this, I believe)
<infinity> Oh, or I've never run the precise version. :P
<cjwatson> The one in precise occasionally thinks headers are data.
<cjwatson> Comedy results.
<infinity> I still need to sit down with a large stick and beat the notion of combined mirrors into its tiny brain.
<tiaz> infinity: I was going to close it as we checked and it's not a problem, but I see adconrad just commented. should I leave it?
<cjwatson> tiaz: /whois
<infinity> You can sort of fool it into putting archive.u.c and ports.u.c into the same cache (so you don't have to download _all.deb twice), which is shiny and all, but then the cron job explodes when it tries to verify things.
<cjwatson> :)
<infinity> Silly.
<infinity> tiaz: ... srsly?
<infinity> tiaz: How long have we worked together, dude? :)
<ScottK> Not long enough apparently.
<infinity> Or too long.  I've been known to drive people insane.
<tiaz> infinity: ha! I'm terrible with names and tend to remember irc nicks :)
<xnox> infinity: who can accept stuff if you freeze the archive. Release team + archive admins?
<ScottK> xnox: Technically yes, but by policy the release team.
<xnox> ScottK:  infinity: will there still be britney block for everything on CDs?
<ScottK> We've yet to actually write the britney block that would manage that.
<ScottK> Although we got close.
 * ScottK doesn't see much point.
<infinity> I see no point in a britney block if we freeze the queue.
<xnox> Ok. Also archive rebuild in progress....
<xnox> infinity: AAs can't twiddle archive block as easily?
<xnox> s/archive/britney/
<ScottK> The ones that aren't also on the release team should know better.
<xnox> ScottK: I'm confused about bug 1077624.
<ubot2`> Launchpad bug 1077624 in simgear (Ubuntu) "Raring: Update Flightgear to version 2.10.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1077624
<xnox> it doesn't look like FFe has been granted yet, but it shows up in the sponsorship queue.
<ScottK> xnox: OK.  It does now.
<xnox> ScottK: about bug 1159832, am I ok to sync the new bitcoin from experimental?
<ubot2`> Launchpad bug 1159832 in bitcoin (Ubuntu) "[FFE] bitcoin: Mandatory upgrade on May 15" [High,New] https://launchpad.net/bugs/1159832
<ScottK> xnox: Yes.
<xnox> ScottK: thanks.
 * xnox testing.
<ScottK> No problem.
<ScottK> Thanks for checking.
<phillw1> cjwatson: if you're still about, I have a failure on a mini-iso who should be informed?
<phillw1> cjwatson: for your, and others information https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1161898
<ubot2`> Launchpad bug 1161898 in debian-installer "Raring 1386 mini.iso complains about mismatched kernel" [Undecided,New]
<cjwatson> phillw1: It's invalid.  I'll reply on the bug.
<cjwatson> stgraber: ^- You might want to look at that, though, to see if there's some reason the tracker hadn't been updated.  I don't know whether that's usually automatic or manual.
<cjwatson> stgraber: The tracker said 20101020ubuntu225 for all the netboot images, despite the last d-i update being a day or two ago.
<cjwatson> (20101020ubuntu226)
<phillw1> cjwatson: thanks, it's one of the lubuntu testers trying to get some pre-testing in for the mini iso's that we do use as 'worst case' smallest installs :D
<cjwatson> stgraber: I don't know whether this is related to the upgrade testcases not being updated, as mentioned on ubuntu-release@; I don't know whether that's normally automatic or manual
#ubuntu-release 2013-03-30
<stgraber> cjwatson: it should be automatic, I'll have to check the cronjob see if something happened
<infinity> cjwatson: FYI, I've refreshed the raring buildd chroots (to help the rebuild test go faster, and just cause it was about time), and disabled the bootstrap sources.list snippet at the same time.  Will re-enable for S when we open it.
<infinity> stgraber: I don't like the looks of that hung upstart build on ross.  Is the dbus-using-testsuites-that-don't-exit disease spreading?
<infinity> Aaand, the archive is frozen.
<cjwatson> infinity: ta
<doko> there are too many builds hanging ... considering to call IS. aatxe, ross, allspice, aleya(?)
<Laney> are we planning to unfreeze after the beta?
<xnox> infinity: i had some funny hanging upstart build reports from fedora people =/
<ScottK> Laney: I think not.
<infinity> Laney: I'm with ScottK on the probably not, unless someone gives me a compelling argument otherwise.
<iulian> /win 1
<iulian> Something went wrong here.
<Laney> infinity: ScottK: Yeah, I am too. Just wanted to check.
#ubuntu-release 2013-03-31
<len-1304> ubuntustudio-default-settings fixes Bug #1162231
<ubot2`> Launchpad bug 1162231 in ubuntustudio-default-settings (Ubuntu) "default terminal and file manager are not set for first use" [Undecided,Fix committed] https://launchpad.net/bugs/1162231
<len-1304> Please accept the above package.
<ScottK> len-1304: Done
<ScottK> infinity: ~150 packages on armhf got chrootwait in the rebuild.  Every one I checked was attempted on nasl, so I manualled it.
<len-1304> ScottK, Thank you
<infinity> ScottK: Fun.
<infinity> ScottK: And you gave 'em all back already, I guess?
<ScottK> infinity: No.
<ScottK> Looks like someone else did.
#ubuntu-release 2014-03-24
<elfy> good morning channel - can anyone tell me when the iso tracker will get updated so I can let people know the url for beta final ? thanks
<infinity> elfy: Sometime tomorrow (well, tomorrow for me)...
<elfy> I hope you're west of me then :p
<infinity> elfy: Western Canadia.  I suppose it's technically "later today", but it's all tomorrow until I've slept. :P
<elfy> infinity: indeed :)
<elfy> thanks
<doko> Mirv, is it intended that that "CI Train PPA Service Team" PPA's build on powerpc?
<Mirv> doko: unless something has changed, yes. didrocks ^
<Mirv> so that there is no builds needed after copying to archives
<didrocks> doko: it does, right
<doko> hmm, ok
<doko> pitti, jibel: please overwrite the ubuntuone-client autopkg test, blocks the zope.interface migration
<pitti> doko: I can't, that needs to be done by ~ubuntu-release
<pitti> Laney: ^ mind adding a nudge?
<doko> pitti: is there a tag for failing autopkg tests?
<pitti> doko: there's some ~u-r bzr branch which has these hints
<doko> pitti: no just wanted to add a tag for a bug report I just filed
<pitti> doko: ah; I'm using http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autopkgtest;users=autopkgtest-devel@lists.alioth.debian.org for Debian
<pitti> doko: for ubuntu, "qa-daily-testing" and "autopkgtest" will do
<Laney> pitti: ok, can you file a bug about it?
<pitti> Laney: ack
<doko> Laney, pitti: lp: #1296656
<ubot2> Launchpad bug 1296656 in ubuntuone-client (Ubuntu Trusty) "ubuntuone-client autopkg tests fail in trusty" [High,Confirmed] https://launchpad.net/bugs/1296656
<Laney> nice, ty
<pitti> ah, thanks; /me cancels the report he is filng
<doko> and now reference this issue in update_excuses.html ...
<doko> pitti, cjwatson: are update-excuses currently not updated?
<pitti> indeed, apparently it's stuck
<cjwatson> It's just very very very slow
<cjwatson> The x264 update is blowing its mind
<cjwatson> I could kill it, but I think it might be better to let it carry on and get the output
<cjwatson> Since most of what the last run complained about seems to be fixed
<pitti> cjwatson: ah, thanks for the heads-up
<cjwatson> And then fix things as fast as we can so that we get past this transition
<apw> cjwatson, by my "eye" measurement she is on the last couple of AYEEIs
<cjwatson> I'll take your word for it :)
<cjwatson> There've been more this time than last, though, so hard to say
<apw> well she finished them for x264 sadly she now is unhappy about vlc
<cjwatson> Good grief, it's still going
<doko> all the "binNMUs" for x264 did succeed, at least all the ones I uploaded
<cjwatson> Ah, it's into the copies now
<cjwatson> Still lots of uninstallables here, let's see what excuses looks like when it finishes
<Riddell> beta freeze happening today?
<Riddell> infinity: â
<elfy> Riddell: sometime later today he said earlier to me
<Riddell> okay dokay
<cjwatson> Ah, libav was waiting for autopkgtests
<cjwatson> Hm, still is, wrongly
<cjwatson> I'm going to kill this run and go through all the issues
<cjwatson> At least libav is a valid candidate now, so that should help
<cjwatson> phew, that managed to migrate x264
<cjwatson> I've stopped p-m for a while so that it doesn't do anything else until the next publisher run has happened, otherwise the next run will take ages (probably much longer than the publisher)
<doko> why did it take that much time to calculate the x264 update? these just about 10-15 binNMU's ...
<cjwatson> doko: lots and lots of uninstallables when not everything was migrated together
<cjwatson> that sort of thing hits pathological cases
<cjwatson> I don't know the internals of britney well enough to be able to do much about it
<cjwatson> there's some deep magic there
<cjwatson> p-m should be back to normal now
<jamespage> release team question: how does feature freeze cover seed changes? if I want to add something to the server-ship seed do I need a release team ack?
<doko> Laney, stgraber, please overwrite the pytables autopkg test, blocking python3-defaults. filed lp: #1296798
<ubot2> Launchpad bug 1296798 in pytables (Ubuntu Trusty) "pytables autopkg tests failing (never did succeed in trusty)" [High,Confirmed] https://launchpad.net/bugs/1296798
<jibel> doko, done
<Laney> oh sorry, I saw this and then forgot
<infinity> Hrm, is the mysql-5.5 autopkgtest really still running, or is britney confused?
<infinity> jibel / pitti: ^
<Laney> Jenkins thinks it's still running, AFAICS
<pitti> infinity: it's still running
<Laney> It shows that if you click "private"
<infinity> Kay.  Long test.
<jibel> last time I checked it was still running
<infinity> Laney: Yeah, I never bothered to get the right bits set up to see the private instance.
<pitti> 7:30 hours ago *sigh*
<infinity> Mostly as a protest vote against HAVING private infra that impacts community process.
<pitti> it looks like it's  hanging
<infinity> Also, lazy.
<jibel> infinity, still running, Ill kill it
<pitti> and also it seems it disabled autopkgtests's timeout
<infinity> pitti: Hung on both amd64 and i386, or just one?
<pitti> infinity: aside from that, the flood got drained surprisingly well (with a few retries)
<Laney> Yah. It's the only way to retry tests though, so I keep it set up.
<pitti> infinity: on both
<pitti> and it hung on the same test apparently on both arches
<infinity> pitti: Kay.  Can't really be a product of my glibc upload, then, so I'll just XFAIL it in britney.
 * pitti doesn't follow that conclusion, but we'll just retry it and see if it looks any different then
<pitti> back then the machines were still clogged
<infinity> pitti: My upload didn't change anything for the amd64 build.  I'd be suspicious if it was hanging only on i386.
<pitti> ah
<stgraber> queuebot was moved to another box and from precise to trusty so let me know if it's acting up in any usual way
<stgraber> (I had to fight with the LP credentials quite a bit, not entirely sure those actually work, we'll see when the next package hits the queue)
<jdstrand> unless someone is looking at oxide-qt right now, I will do it
<utlemming> stgraber: it looks like the SRU for walinuxagent went into the wrong proposed pocket...any chance you could move it?
<utlemming> stgraber: it got dropped to precise-proposed/univerise instead of precise-proposed
<utlemming> stgraber: and it didn't get built
* infinity changed the topic of #ubuntu-release to: Released: Trusty Beta 1 | Archive: Beta Freeze | Trusty Tahr 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
<jtaylor> hi, can pytables be forced into trusty? the adt tests never succeeded and seem to be specific to the adt environment, the tests work fine on my machine
#ubuntu-release 2014-03-25
<infinity> stgraber: If you haven't already, can you work the tracker magic to give me a milestone?
<infinity> jtaylor: Lemme look.
<stgraber> infinity: sure
<infinity> jtaylor: The pytables that was promoted to -release 7 hours ago?
<stgraber> infinity: I'm assuming all flavours are participating this time around?
<infinity> stgraber: They pretty much have to, following our old rules of "no beta, no release".
<stgraber> infinity: ok, done, any build done from that point on will show up in the Beta 2 milestone
<infinity> stgraber: Kay.  We should probably add and drop some products too...
<infinity> stgraber: core, netboot, and server ppc64el probably need to exist.  And unless I go and fix it in a real hurry, server omap* are both a lost cause.
 * infinity goes to disable both of those right now so we stop trying and failing to build them.  If I find the time to fix them (and if anyone cares), we can put them back later.
<infinity> Oh, Laney did that on the 17th. :)
<stgraber> infinity: the current manifest is http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/42/manifest
<stgraber> let me know what we're missing and I'll check if we have it in stock already and it just needs adding or if I need to create a new product entry
<infinity> stgraber: As above.  Need ppc64el netboot, server, core.
<infinity> stgraber: And need to drop server armhf+omap and server armhf+omap4
<stgraber> ok, dropped the two omaps, ppc64el will need some more work as I need to create product entries for those
<infinity> Alright, omap server images purged from the mirrors and crontab on manual.
<infinity> Erm, cron slightly too manual...
 * infinity reenables self-rebuilds.
<infinity> stgraber: Do we still want system-image imports running?
 * infinity guesses so.
<stgraber> yeah, don't touch system-image
<infinity> Wait...
<infinity> Is the trusty NEW queue really empty because we caught up, or did stgraber's bot go crazy and accept everything?
<knome> what's wrong with accepting everything once in a while during a full freeze and a LTS release?
<infinity> Heh.
<infinity> And, no, we must have actually caught up, the bot's not even running yet.
<infinity> Sweet.
 * infinity turns on the bot.
<knome> don't worry, we'll provide you something to work on shortly ;)
<infinity> Err...
 * infinity turns on the bot AFTER changing the default series.
<knome> s/hardy/trusty/
<stgraber> infinity: core, netboot and server ppc64el added to the tracker and manifest
<infinity> stgraber: Lovely, thanks.
<stgraber> infinity: so if nobody messed up the cdimage code, they should magically auto-publish
<infinity> stgraber: That auto-accept bot would be a lot less dangerous, if it acted on the current devel series instead of having SERIES hardcoded. ;)
 * knome bows for all the hard work the release team does
<knome> and for a bit more :)
<stgraber> well, netboot is triggered from a cron on my server which I'll manually trigger now
 * infinity was --><-- this close to auto-accepting the saucy queue.
<stgraber> infinity: isn't it limited to the release pocket?
<infinity> stgraber: No, proposed...
<stgraber> oh yeah, that could be dangerous :)
<infinity> stgraber: So, it would happily accept all the pending SRUs for a series. ;)
<infinity> knome: Meh, this time of year, the hard work is all up to people like you.
<knome> huhu, don't tell me
<infinity> knome: I just have to write emails and herd cats (neither of which I enjoy), but you have to test, test, test.
<knome> i still have to squeeze out the last drips of non-commercial creativity juice to the xubuntu wallpaper
<knome> and the paperwork related to that ;)
<stgraber> infinity: I think I remember why I had to do that...
<stgraber> >>> list(lp.distributions['ubuntu'].getDevelopmentSeries())
<stgraber> []
<infinity> Oh look, and there's the bot earning its keep already.  \o/
<infinity> Yay for it not bitrotting.
<stgraber> something to do with a frozen series not being considered as development or something
<infinity> stgraber: I believe there's a different call that works for frozen too.
<infinity>     # We care about the development series by defaults.
<infinity>     if hasattr(options, 'suite'):
<infinity>         ubuntu = options.launchpad.distributions['ubuntu']
<infinity>         options.suite = ubuntu.current_series.name + '-proposed'
<infinity> ^-- From some other random script...
<infinity> >>> print lp.distributions['ubuntu'].current_series.name
<infinity> trusty
<infinity> stgraber: ^
<stgraber> ah, that's good. Feel free to just commit the fix then :)
<Thedemon007> Hello, i send a debdiff for this bug  https://bugs.launchpad.net/bugs/1251849 may apply for a SRU?
<ubot2> Launchpad bug 1251849 in xserver-xorg-video-openchrome (Ubuntu) "[VX820] Regression: driver does not work on Samsung NC20" [High,Confirmed]
<infinity> No more than a few hours after I freeze the archive, I upload d-i, wait an hour, and wonder why it's not been built.
<infinity> I'm SMRT today.
<stgraber> ah I guess you want that one for beta 2?
<infinity> stgraber: Yeah, the latest kernel had d-i specific changes to it, I'd like it in the builds.
<infinity> Figured I'd let lightdm in for free, since it'll happen in parallel.
<stgraber> yeah, that's fine, nobody tried to spin candidate images anyway yet
<infinity> No, I had planned to spin them after d-i built. :P
<ScottK> So, if I can get Qscintalla2 for Qt5 building, would it be reasonable to let it in for trusty assuming I'm careful to make sure the existing Qt4 stuff isn't affected?
<stgraber> infinity: ah, you're actually doing an initial mass build for everyone? last time around I just told them "we're ready, press the button when you are" and didn't do anything myself :)
<ScottK> infinity is full service.
<infinity> ScottK: Like, a new library/soname for qt5, but still also build the qt4 libs?
<ScottK> Yes.
<infinity> ScottK: That would seem entirely reasonable.  It's not really a new "feature", per se, if the existing stuff is untouched.
<infinity> (Much like new source packages aren't a new feature, until someone wants to depend on them or seed them)
<ScottK> The tricky part here is upstream used the same name for the Qt4 and Qt5 libs, but did leave at least some plumbing in place for renaming and didn't suggest I not do it when I asked.
<infinity> stgraber: In retrospect, that would have been smarter, but my email did claim I'd do the first spin for everyone.  I should probably stick by that.
<ScottK> So I don't know if it'll be done or not.
<infinity> ScottK: So, it would be nice if you schooled upstream about them needing to be a new SONAME if built against a different Qt.
<infinity> ScottK: Unless they mask that very, very well in their ABI and the Qt4 and Qt5 builds really are compatible...
<ScottK> We discussed it.
<ScottK> No, they aren't and they know it.
<infinity> (If that's the case, then I'd go for a temp SONAME for now for playtime, and then if you move wholesale later, do some clever renames and replaces)
<infinity> Ahh, kay.  Yeah, if they're incompatible, get them to fix their shit. :P
<infinity> But for now, you could just tack a modifier on the end or something.
<infinity> When they sort out how to do it right, you can always rename and rebuild rdeps if there are any.
<ScottK> There is allegedly some qmake magic I can do that will make it all wonderful.
<ScottK> As I say, this may not make it.
<infinity> Heh.
<infinity> Well, if you get around to it, you have my approval to make it happen.
<infinity> And regardless, upstream needs to get their SONAME story sorted before more people try building against Qt5 and have a sad.
<ScottK> Yeah.  Not holding my breath.
<infinity> stgraber: So, hrm.  Instead of me driving this at nusakan's commandline, or clicking in a web UI, do you have a way to just blat our "rebuild 'em all" to the tracker DB?
<infinity> s/our/out/
<stgraber> infinity: annoyingly, nothing terribly easy... I just checked and I don't export the rebuild method over the API, so I can easily query the manifest and get all the products but I can't actually queue the rebuild over the API (I should probably fix that next cycle).
<stgraber> so your best bet is to get the manifest, then head to the daily milestone, tick all the things that are on the manifest and click rebuild
<stgraber> I think that's the most efficient way of doing it. The alternative is to just run all the things in cron but that'd waste quite a bit of livefs buildd time for stuff that don't matter for beta2 (though not as much as selecting everything on the daily page, which apparently has more things than the crontab...).
<infinity> stgraber: Except that they're not all on the daily.
<infinity> Meh, I'll just respin the way I usually do when I get home from my late night outing.
<ogra_> hey, did anyone diable touch builds in the crontab by accident (seems there was no 3am build)
<ogra_> yeah ... re-enabling
<infinity> ogra_: I had it in my build pipeline so it would happen eventually.
<infinity> ogra_: I guess you'll get two now. :P
<ogra_> infinity, heh, k
<ogra_> there was just a manual build that finished 20min ago
<infinity> stgraber: Hrm, I don't see server/ppc64el up there.
<jibel> python3-apparmor is now in main. Could you build a set of Ubuntu Desktop images?
<infinity> jibel: There are a bunch of builds in the pipe still.
<infinity> jibel: Either way, indicator-sound pull all of that stuff in needs to be fixed.
<infinity> s/pull/pulling/
<Laney> didrocks: I'll reject that one then
<didrocks> Laney: oh, you can?
<didrocks> oh right
<didrocks> I'm stupid, nice :)
<didrocks> Laney: soâ¦ let me redo with the real version name
<Laney> The queue is saving your ass here :P
<didrocks> (there is a new one coming with 24.is.20
<didrocks> which we can reject as well
<Laney> right
<didrocks> rejecting that one then ^
<Laney> done
<didrocks> Laney: I was wondering why I didn't see it :p
<didrocks> the other one should be there soon (uploaded)
<infinity> I've lost track.  Is 12.10.2+14.04.20140324.is.12.10.2+14.04.20140320-0ubuntu1 the one I want? :P
<didrocks> infinity: yeah :)
<Laney> Should be
<Laney> diff it against that version to double check
<infinity> Too late.  I'm trusting the Frenchman.
<didrocks> infinity: hehe, once I type the correct version and don't s/24/20/, all is fine :)
<didrocks> http://launchpadlibrarian.net/170656407/indicator-sound_12.10.2%2B14.04.20140324-0ubuntu2_12.10.2%2B14.04.20140324.is.12.10.2%2B14.04.20140320-0ubuntu1.diff.gz FYI
<directhex> cjwatson, thanks for letting that dbus# ABI revert bullshit through. banshee upstream are very... agitated... about that particular issue
<hyperair> agitated is an understatement
 * hyperair very nearly put him on /ignore
<cjwatson> directhex: which dbus# thing?
<cjwatson> no memory of this
<directhex> Subject:	[ubuntu/trusty] dbus-sharp-legacy 0.7.0-5ubuntu1 (Accepted)
<directhex> Date:	Sun, 23 Mar 2014 18:53:51 -0000
<cjwatson> glad you're happy but wasn't me :)
<cjwatson> I guess somebody was cleaning the NEW queue over the weekend
<infinity> Yeah, no idea who the NEW hero was, but it was empty when I got to work on Monday, which made me both happy and suspicious.
<directhex> well, perhaps you could gain some credit anyway: can someone bump it into main, for banshee to be able to build against it? review really shouldn't be needed, it's an old version of an already-in-main package
<directhex> (also the matching dbus-sharp-glib-legacy)
<infinity> directhex: Yeah, can do.  Does banshee already build-dep on it?
<hyperair> not yet
<infinity> Right, so fix that.
<hyperair> oh so i upload a new banshee first?
<infinity> And then component-mismatches will prompt us to DTRT.
<hyperair> aha
<hyperair> okay, that's interesting
<hyperair> i thought it'd just ftbfs
<directhex> ok. thanks guys.
<directhex> hyperair, it'll ftbfs, but with a *reason*!
<hyperair> ...
<infinity> hyperair: It will FTBFS, yes.  Which is fine.  Then we get told by our tools exactly which bits need promoting, and we do our monkey work, and subsequent build retries will work.
<hyperair> cool
<infinity> hyperair: Do I have a new banshee yet?  *poke, poke*
<hyperair> infinity: hang on, test building...
<hyperair> dpkg -O -i'ing...
<hyperair> i have my own suspicions that this won't work because libnotify has been ported to new dbus..
<infinity> hyperair: Oh, not working would be less than ideal.
<hyperair> infinity: that's the point when i give the finger to upstream
 * hyperair sighs
<hyperair> oh amazing, it works!
<infinity> hyperair: I hope upstream likes free fingers.
<hyperair> let's upload
<hyperair> i dunno, maybe upstream eats ladies' fingers
<hyperair> okay uploaded
<hyperair> imma go disappear from office now
<infinity> directhex: Err, wait, why did you think we'd need to promote anything?
<infinity> directhex: banshee is in universe.
<directhex> it is?
<infinity> Sure is.
<infinity> Has been more or less forever, except that one cycle where it was the default player, whenever that was.
<infinity> oneiric?
<directhex> publishing history says natty, oneiric, precise
<infinity> Well, natty oneiric, then.
<infinity> precise it dropped back to universe before release.
<infinity> utlemming: Despite promises, you never did seed joyent-mdata-client.  Please find a home for it, or it's going to universe. :P
<infinity> utlemming: (server-supported, something cloudy, whatever)
 * infinity heads off to have a nap.
<stgraber> infinity: looking into ppc64el images now
<stgraber> No iso.qa.ubuntu.com product found for ubuntu-server/daily/trusty-server-ppc64el; skipping.
<stgraber> looks like the cdimage branch needs some fixing
<stgraber> infinity: next time you had new builds on nusakan, don't forget etc/qa-products :)
<stgraber> updating now
 * stgraber does a respin of core and server ppc64el to confirm they now publish fine
<stgraber> infinity: took two tries to get ubuntu-core ppc64el building but that's done now.
<seb128> could somebody review the ffe on https://bugs.launchpad.net/indicator-power/+bug/880881 ?
<ubot2> Launchpad bug 880881 in indicator-power (Ubuntu) "[ffe] Power indicator does not combine multiple battery status" [Medium,In progress]
<Laney> stgraber: want to review activity-log-manager to slip it into the beta as we're respinning anyway?
<stgraber> Laney: accepted (diffs of diffs are always so readable...)
<Laney> :-)
<Laney> that project is bad
<Laney> it's sort of owned by us but not really managed well
<Laney> like the upstream bzr branch has debian/patches in it that don't apply
<Laney> anyway, cheers
<Laney> Riddell: there's a kubuntu thingy in the unapproved queue
<balloons> is there a reason we don't have ubuntu images as part of the final beta milestone
<Laney> that was a quick review
<seb128> Laney, it likely got autoaccepted by the bot since it's on none of the images
<Laney> it is on a few of them, but maybe someone started reviewing before the bot noticed it ...
<jibel> when are expected ubuntu desktop images?
<Laney> jibel: infinity said he would spin some when he emerges
<stgraber> Laney: there are a few exceptions in the bot, maybe that's one of them
<Laney> I see
<stgraber> PACKAGE_WHITELIST = ["upstart-app-launch", "click", "click-apparmor",
<stgraber>                      "apparmor-easyprof-ubuntu", "ubuntuone-credentials"]
<stgraber> those are from last cycle, they may need adapting if no longer relevant
<jamespage> if have a seed change I'd like to get into the server-ship seed for beta-2 - would one of the release team be able to ack my change please?
<pete-woods> hi, I have a CI train merge for HUD with some crash bugfixes
<pete-woods> I misunderstood the wiki and thought the final freeze was on Thursday
<pete-woods> what should I do to get them landed? / is it simply too late now?
<infinity> jamespage: Which change?
<jamespage> infinity, https://code.launchpad.net/~james-page/ubuntu-seeds/ubuntu.trusty-hv-kvp/+merge/212686
<infinity> pete-woods: It's not too late for final, might be too late for the beta.
<jamespage> infinity, bug 1294856
<ubot2> Launchpad bug 1294856 in hv-kvp-daemon-init (Ubuntu Trusty) "Add hv-kvp-daemon-init to the server seed" [High,Triaged] https://launchpad.net/bugs/1294856
<infinity> jamespage: Guessing you haven't kept in touch with apw, who is pulling that init script into linux-cloud-tools, and we're dropping hv-kvp-daemon-init except as a transitional package)
<jamespage> infinity, evidently not
 * jamespage sighs
<infinity> Though, for now, this seed change it probably correct anyway.
<jamespage> utlemming, ^^ you need to be aware of that
<infinity> And if people use the server CD pool for upgrades, it would still be correct for 12.04->14.04 upgrades.
<infinity> So, sure, let's commit this.
<jamespage> infinity, ack - I'll push now
<infinity> jamespage: Ta.
<infinity> I'm literally minutes away from a mass respin, so...
<infinity> Timing++
<pete-woods> infinity: okay, does that mean I need to ask to be added to the general phone FFE? (https://bugs.launchpad.net/ubuntu/+bug/1282590)
<ubot2> Launchpad bug 1282590 in Ubuntu "[FFe] standing freeze exception in trusty for Ubuntu Touch-specific packages" [Undecided,Confirmed]
<ogra_> infinity, exclude touch this time :P
<jamespage> infinity,done - thanks!
<Laney> pete-woods: no, and bug fixes don't need FFe
<infinity> balloons: There were some build/seed issues, respinning nowish.
<infinity> ogra_: Yes dear.
<ogra_> :)
<pete-woods> Laney: okay, thanks, is it just a matter of waiting on the archive being un-frozen then?
<pete-woods> i.e. for final release
<infinity> pete-woods: It's not going to be unfrozen, upload at will.  We'll accept what we accept.
<Laney> You can upload and they will get stuck in the queue for release team review
<pete-woods> I don't have rights to upload or anything like that, I just have a message in the CI train that I'm in the UNAPPROVED queue
<pete-woods> if that means it's already uploaded, and waiting for you guys' approval, then great
<seb128> that might it got uploaded/published already I think
<seb128> pete-woods, https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=
<seb128> yeah, it's in there
<pete-woods> seb128: cool, thanks for the magic URL :)
<Laney> yup
<Laney> oh, I forgot about syncs-in-queue. grr
<infinity> Okay, world respin in progress now.
<infinity> Won't touch flavours after this one.
<seb128> you might want to click the merge&clean button with ignore_not_in_dist
<seb128> the freeze is not going to play nice with the limited number of silos/ppas otherwise
<pete-woods> seb128: okay, thanks, will get my manager to do that
<seb128> e.g if the silos get locked down until things reach trusty release pocket
<seb128> thanks
 * pete-woods has no rights of his own
<infinity> Erk.  Wait.  Is seeded-in-ubuntu just behind the times, or is click *still* being pulled in on xubuntu and kylin desktops? :/
<stgraber> click is listed in http://cdimage.ubuntu.com/ubuntukylin/daily-live/20140325/trusty-desktop-i386.manifest
<Laney> It parses the manifests AFAIK, so it'll show it as long as it's in the latest image
<stgraber> and in http://cdimage.ubuntu.com/xubuntu/daily-live/20140325/trusty-desktop-amd64.manifest
<infinity> Oh.  I assumed it worked on germinate output.
<infinity> Parsing manifests is stale data.
<infinity> Kay.
<stgraber> so click sure was on both images last time we built them anyway
<infinity> stgraber: Yeah, I know why it *was*, and we fixed that, so I was annoyed that it still was, according to the tool that likes to use old data. :P
<infinity> The name is misleading. :P
<stgraber> the tool really ought to be called on-ubuntu-image or something like that
<infinity> Should be "was-in-an-ubuntu-iso-recently"
<stgraber> :)
<infinity> I'd much prefer if it actually did what the name implies, told you what would be on an image based on germinate output.
<infinity> But oh well.
<Laney> SMOP :P
<infinity> Laney: Send me obfuscated patches?
<Laney> oresome
<stgraber> seb128: I think you mentioned the silos earlier. One thing to be careful about is that until a sync is accepted, the files only reside in the PPA.
<stgraber> seb128: so if you clear a silo before we accept it into proposed, the copy will fail when we finally do
<seb128> stgraber, urg, I overlooked that
 * ogra_ guesses thats something the whole landing team needs teaching about 
<seb128> can anyone accept the hud upload before it gets deleted? ;-)
<pete-woods-afk> plzkthx
<seb128> stgraber, ogra_: can you communicate that to #ubuntu-ci-eng, I see that being a frequent gotcha this week, we can't keep the silos locked down until after beta or we are going to run out of silos
<ogra_> seb128, i'll try to remember to bring it up in tomorrows meeting
<seb128> thanks
<seb128> why do we need the freeze at all?
<seb128> can't we just britney block things in proposed nowadays?
<stgraber> the release team usually wants to review all changes to main from that point on, to make sure people don't sneak in features and to make sure nothing terrible happens to the archive
<stgraber> unseeded packages get auto-accepted and so do those that are only in touch images, so a fair amount of the CI-Train stuff should go through fine
<seb128> not so "fair amount"
<seb128> we have a stack of desktop stuff going through that
<seb128> including all indicators, compiz, unity, hud, unity-control-center, unity-settings-daemon
<seb128> we are struggling with the silos being all allocated daily atm, and that was before the beta freeze
<stgraber> so we could add a massive britney block on top of the freeze so we can let those into -proposed without letting them into the release pocket
<seb128> that would be nice
<stgraber> though I think it'd be easier for the CI folks to just not assign silos to those projects until post-beta
<stgraber> since things won't be landing anyway
<seb128> shrug
<seb128> I'm getting really annoyed at how people want to block others to work nowadays
<seb128> having silos makes my job much easier
<infinity> jibel / balloons: According to queuebot, you haz images.  Sorry for the delay.
<balloons> :-)
<utlemming> anyone around to move an SRU candidate to the right pocket? walinuxagent was put in precise-proposed/universe when it should have gone in precise-proposed.
<infinity> utlemming: Can fix.
<utlemming> infinity: thank you kindly
<infinity> We really need to fix that bug.
<infinity> utlemming: Fixed.
<infinity> (The override, not the bug)
<utlemming> infinity: awesomes, thansk
<infinity> utlemming: Did you see my joyent ping?
<utlemming> infinity: er, where?
<infinity> Here, last night.
<infinity> 04:55 < infinity> utlemming: Despite promises, you never did seed joyent-mdata-client.  Please find a home for it, or it's going to universe. :P
<utlemming> infinity: OH!
<utlemming> infintiy: I thought I didn't find it a home :/
<infinity> s/didn't/did/?
<utlemming> yes
<utlemming> infinity: I thought I did, but apparently I didn't
<infinity> utlemming: Anyhow, when I NEWed it to main in November, you promised you'd seed it.   You're a bit late. ;)
<utlemming> infintiy: indeed...I deserve the scolding
<infinity> utlemming: I'm assuming server-ship or supported, but didn't really want to make the call for you.
<utlemming> infinity: supported is the right place
<utlemming> infintity: that is where hv-kvp-daemon-init lived for so long
<infinity> utlemming: Want me to JFDI that for you, then?
<utlemming> infintiy: yeah, that would be really, really appreciated
<infinity> utlemming: iz done.
<infinity> stgraber: Speaking of component-mismatches, I guess you stopped using zram-config?
<infinity> (at least, I think it was you pulling it into main before...)
<infinity> Yeah, ltsp-client used to pull it in.
<stgraber> infinity: ah yeah, the recommends was dropped from Debian in the last merge. (yeah, I know it doesn't exist in Debian but we have a rather weird shared packaging :))
<infinity> stgraber: Well, my master plan to pull zram-config magic into initramfs-tools is obviously not happening this cycle, so if you still want it, you might want to bring back the dep.
<infinity> (Otherwise, happy to demote... *shrug*)
<stgraber> infinity: apparently some of the biggest ltsp user think nbd-swap is better for ltsp's usecase, so I'm fine having it demoted to universe
<stgraber> (I still run it on all my machines but I don't really care whether it's in main or universe :))
<infinity> Swapping over a network?  WCPGW?
<infinity> I could see an argument for both in tandem.
<stgraber> well, when your X session and your rootfs already come from the network, you're already dead without network...
<infinity> zram to get you the most use of your local RAM, and nbd-swap for when things go to hell.
<infinity> stgraber: I wasn't thinking of "if the network goes away", just the speed of swapping pages over ethernet.
<infinity> Though, I suppose, on an uncongested GigE network backed by a very fast server disk array, that may well be faster than swapping to local disk.
<infinity> (That's a fair few ifs, though)
<stgraber> yeah, I agree that both would be ideal, with proper priorities set, though I didn't manage to convince someone in ltsp upstream to get that stuff done.
<zequence> Any chance of getting a couple of things uploaded? I need to ask for a rebuild afterwards. Two packages - lp:ubuntustudio-live and lp:ubuntustudio-meta. ubuntustudio-meta has a fix for a critical bug 1297219 ..
<ubot2> Launchpad bug 1297219 in ubuntustudio-live (Ubuntu) "package selection plugin crashes when deselecting a transtional meta package" [Critical,Fix committed] https://launchpad.net/bugs/1297219
<infinity> zequence: I can have a look in a bit if no one beats me to it.
<zequence> and, also, ubuntustudio-live has a plugin that allows us to select packages from our metas individuall, but the metas aren't yet updated
<infinity> zequence: If you're doing the ISO testing, I don't much care if you cause yourself respins. ;)
<zequence> infinity: That would be great :)
<infinity> zequence: So, I'm around now.
<infinity> zequence: Checking out your two branches.  But what did you mean by "but the metas aren't yet updated"?
<jibel> infinity, thanks, syncing now...
<infinity> jibel: Sorry about the mess.  Between the "hey, look, click on all the desktop CDs" thing and pitti's noticing that all the langpacks were broken, it's been a rocky start. :P
 * jibel was wondering what to do tonight, now he knows :)
<infinity> balloons: I haven't been paying attention to community testing so far.  Do you have any indication that all our flavours are on the ball?
<elfy> this flavour is :)
<elfy> this one being xubuntu
<balloons> infinity, yes, lubuntu and xubuntu are out and about
<infinity> elfy: \o/
<elfy> infinity: you can probably tell that given I was hassling you for the url ;)
<balloons> no idea on kubuntu or ubuntu gnome.. although I saw ubuntu gnome announce
<infinity> balloons: Right, but literally everyone should be participating this time.  myth, studio, kylin, gnome, X, K, and L.  I think that's everyone...
<infinity> balloons: If you have the right contacts for everyone, can you send a gentle prod out? :P
<balloons> myth and studio, yea.. not heard anything from them
<infinity> Well, studio is zequence above, we know he's doing things. :)
<balloons> ahh indeed
<elfy> balloons: we've still got that nasty keyboard issue - no-one really has any idea what to about it
<infinity> myth's primary contact is... Mario?  Maybe?
<balloons> infinity, yea
<balloons> superm1,
<superm1> yeah we're in a little bit of a mess right now still
<stgraber> infinity: everyone keeps forgetting Edubuntu ;) but yeah, we'll have a beta2
<infinity> superm1: Well, validating to the point of "it doesn't blow up computers" is better than nothing.  Something more thorough would be nice by final release, of course. :)
<balloons> i'll ping the kylin guys
<superm1> well it installs, but only if you install in "install only" mode
<infinity> stgraber: I don't count you, since you're an Ubuntu desktop, and you basically just roll with the punches and get your testing done quietly. :P
<superm1> which i guess means not blowing stuff up
<superm1> tgm and I going to try to sort out a few things that are broke, but $life has been in the way lately
<zequence> infinity: I've made some changes in seeds that haven't been updated in ubuntustudio-meta
<zequence> the source is updated
<infinity> zequence: Right, kay.  So, if I review and sponsor these two, want me to refresh meta at the same time and jam it all in?
<zequence> but not the uploaded package
<zequence> infinity: If you refresh the meta, without uploading the source, if you like, remove two files..
<zequence> I mean, without uploading from lp:ubuntustudio-meta directly
<infinity> zequence: Oh, I see, you've refreshed it in bzr.
 * infinity has never seen a meta in bzr, that's a bit meta in itself.
<infinity> zequence: That's a whole lot of new audio-recommends... Are those installed by default?
<zequence> infinity: Yes, but with our new plugin, you can deselect stuff
<zequence> infinity: Besides refreshing, I've removed two files, rtprio.py
<zequence> and  ubuntustudio-audio-rtprio.conf
<infinity> Kay.  Your call, your flavour.  Just want to make sure you're fully aware of the crazy of blowing out the base install size. ;)
<zequence> in the root folder
<zequence> infinity: It's a DVD :)
<zequence> most of it is pretty small
<infinity> zequence: Sure, "it's a DVD" is an argument to ship more packages in pool/, but not necessarily to install them. :)
<infinity> Also, ARGH.
<infinity> git diff ; svn diff ; bzr diff.
<infinity> This.  This is my workflow.
<infinity> Stupid fingers.
<cjwatson> infinity: maybe http://www.greenend.org.uk/rjk/vcs/ is your kind of thing
<infinity> cjwatson: Does that magically make everything one command?
<cjwatson> I believe that's roughly the idea.  Though I expect if you're doing anything non-trivial with git then it doesn't wrap that
<infinity> I suspect that would just be more confusing.
<infinity> At least when I screw up an innocent "diff" or "log", I then end up in the right mindset for future scary things.
<cjwatson> Maybe you need an sl equivalent.
<infinity> Like the fantastic semantic difference between "git add" and "anything-else add".
<cjwatson> Type svn and a mallet unfolds from the back of your monitor to whack you.
<stgraber> I'm not sure I want to hear what cvs and rcs would do then :)
<cjwatson> Water pistols, directed so they hit both you and your keyboard.
<elmo> cjwatson: oh wow, that's awesome
<cjwatson> p4 produces a comedy gun with a flower sticking out the end.
<cjwatson> elmo: It doesn't really fit my brain, but I can definitely imagine it being helpful for some
<cjwatson> And Richard has clue
<slangasek> cjwatson: "svn update" "Ok, installing git"
<cjwatson> sccs should just say "Sorry for your loss" and then halt.
<cjwatson> (As in HCF.)
<infinity> zequence: Alright, finally getting to your stuff here in parallel with some other things...
<infinity> zequence: (Why do you have all the .old files checked in to bzr?)
<infinity> I'll clean that up if I have commit rights. :P
<infinity> Which I probably do.
<infinity> zequence: For future reference, after a ./update, you should run "fakeroot debian/rules clean".
<infinity> zequence: Alright, live and meta sponsored.  When it all migrates to release, feel free to respin yourself.
<infinity> zequence: Unless that's a bit of a timezone fail for you, I can respin when I get back from dinner later.
<knome> he's UTC+1, so soon midnight for him
<infinity> zequence: I had to re-rebuild some other bits due to an outage in our DC, so I'm tacking your images on to the list.  Cheers.
#ubuntu-release 2014-03-26
<zequence> Thanks. Yes, it was nighty nighty time for me yesterday :)
<dbarth> hiya
<dbarth> sil2100: and i have a problem with some packages stuck in a silo not flowing in the archive because of the recent freeze i guess
<dbarth> namely: unity-webapps, webbrowser-app, libunity-webapps
<sil2100> Hi release team! Yes, it's
<sil2100> I mean...
<sil2100> Yes, it's something that is required for touch development, and we would be grateful if those could be pushed forward :)
<Laney> They're being held becuse they are on other seeds than just touch, and there's a beta being prepared currently.
<seb128> hey
<seb128> what's the right place to start a discussion about "blocking things in unapproved vs blocking things in proposed"
<dbarth> ah ok
<seb128> the unapproved queue is creating issues for CI train (basically it means no silo/ppa can be cleaned, given back)
<dbarth> is there a way i can just free the silo for now, while the freeze is in effect?
<sil2100> dbarth: not right now sadly... not without hacking around the whole process
<dbarth> how long are we talking for the freeze?
<dbarth> depending on the timeframe
<dbarth> maybe i should continue with the same silo but add more stuff
<Laney> Beta is on Thursday
<dbarth> Laney: ok
<dbarth> so unfreeze friday or so
<seb128> shrug
<dbarth> then i think i'll try to keep that silo open and work in there
<seb128> that ridiculous
<dbarth> sil2100: works?
<Laney> There's no unfreeze, but stuff ought not to be held
<seb128> Laney, why can't those uploads just go to proposed if they are blocke there?
<Laney> They aren't blocked there
<seb128> ok, it just happens that people only review/let beta fixes through?
<Laney> I think the idea is to have release team eyeballs on stuff before it enters the archive
<Laney> This is what we did last cycle too, IIRC
<sil2100> dbarth: we can do something else, let's move it to another channel
<dbarth> sil2100: ah ok :)
<seb128> Laney, right, that worked fine when we did have silos, now every unapproved upload coming from CI train locks a silo and we have only a limited number
<jibel> cjwatson, there are 2 critical bugs in ubiquity bug 1297312 and bug 1296697
<ubot2> Launchpad bug 1297312 in ubiquity (Ubuntu Trusty) "ubiquity-dm fails with: FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/x86_64-linux-gnu/indicator-application-service'" [Critical,Triaged] https://launchpad.net/bugs/1297312
<ubot2> Launchpad bug 1296697 in ubiquity (Ubuntu Trusty) "Trusty Desktop installer crashed with "Encrypted Home" set" [Critical,Confirmed] https://launchpad.net/bugs/1296697
<jibel> fix for 1297312 is obvious and someone proposed a patch
<jibel> I am not sure about 1296697 because there is no swap after installation but there was none before the change to ecryptfs-utils either
<davmor2> jibel: hey dude I've just run my update iso script and i386 and amd64 both had updates but mac version didn't is that correct?
<jibel> davmor2, it is incorrect. latest images are 20140325.1, and there are imags for amd64+mac in http://cdimage.ubuntu.com/daily-live/current/
<davmor2> jibel: right I'll check the checksums maybe I hit it yesterday and only the mac image had finished updating.
<davmor2> jibel: nevermind just me I must of updated it yesterday and the other 2 not get pulled in phew :)
<jibel> davmor2, you should really consider using dl-ubuntu-test-iso from ubunqu-qa-tools, it does all this already
<davmor2> hi ho, hi ho, hi ho, hi ho, it's iso testing we go.....
<jibel> davmor2, can you test uefi+sb to make sure it's covered? I don't have hw to do this.
<davmor2> jibel: I'm just gonna hit everything so it'll confirm everything works :)   but yeah my plan was to do all the amd64 tests against my uefi+sb laptop as well as a standard box
<davmor2> jibel: oh I can do a side by side with windows too. now I'm assuming I can get macos back on this mac to so could potentially test side by side there too I guess but I'll save that till last :)
<davmor2> jibel: Huston we have a problem.  On my non-uefi laptop and the mac I'm greeted by a black screen rather than the ubiquity session screen this didn't happen on the image before 25.1
<davmor2> jibel: that is i386 and amd64+mac just firing up amd64 see if it is the same
<davmor2> jibel: and it is
<jibel> davmor2, possibly bug 1297312
<ubot2> Launchpad bug 1297312 in ubiquity (Ubuntu Trusty) "ubiquity-dm fails with: FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/x86_64-linux-gnu/indicator-application-service'" [Critical,Triaged] https://launchpad.net/bugs/1297312
<jibel> davmor2, does it happen if you press shift on the boot screen and select "try ubuntu"
<jibel> ?
<davmor2> jibel: I shall try
<davmor2> jibel: okay so live desktop is good so it is most likely that issue.
<davmor2> jibel: although it's happening on i386 too so not just /usr/lib/x86_64 I guess
<jibel> davmor2, on i386 the path would be .../i386-linux-gnu/.. but it's the same problem
<davmor2> jibel: confirmed the lack of ubiquity across the board
<cjwatson> jibel: right, looking
 * davmor2 goes back to testing phone in the meantime.
<cjwatson> infinity: we're going to need a respin for ubiquity anyway; do you think I could have my dee and geoclue uploads let through the queue at the same time?  they're fairly trivial multiarch fixes, not beta-critical or anything, but I have a really deep stack there in order to get to the point of being able to do "apt-get install ubuntu-sdk-libs-dev:armhf" in "click chroot" and it would help to be able to make progress
<jibel> davmor2, it would be nice if you could verify uefi+sb instead, so we do not discover it is broken after next respin. just skip ubiquity-dm and boot directly to a live session.
<davmor2> jibel: and just do an install from the live session you mean?
<jibel> davmor2, yes
<davmor2> jibel: no worries I'll set that up now
<davmor2> ah nice bug
<davmor2> jibel: on the new lock screen hit system indicator and then hit restart and watch it restart the computer even though your user is still logged in :)
<seb128> davmor2, that has always been the case on e.g the greeter
<davmor2> seb128: yes on the greeter when no one is logged in.  This is the lock screen though, it used to warn that a user was locked in
<seb128> ?
<davmor2> logged in even
<seb128> on the greeter even when people are logged in
<seb128> use precise or saucy, do switch user, your session is still open and you are on the greeter, shutdown
<seb128> the box shutdowns with your user session open
<davmor2> seb128: oh okay
<davmor2> seb128: just not used to it happening from the lock screen, you had to login to get to the option before I guess
<seb128> right
<seb128> or to go the greeter
<seb128> by clicking on the button that was on the lockscreen
<seb128> bug #1281058 btw
<ubot2> Launchpad bug 1281058 in unity-greeter (Ubuntu) "The system shutdowns when multiple accounts are open" [Medium,Triaged] https://launchpad.net/bugs/1281058
<davmor2> seb128: nice thanks
<seb128> yw
<davmor2> jibel: so the uefi menu works, live session seems to work, install about to be triggered so far so good :)
<zyga> hey, I'd like to ask for a few things to land before the beta is out: https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297665 and the two merge requests to ubuntu source branchs (both tiny though), this should hopefully fix https://bugs.launchpad.net/ubuntu/+source/checkbox-ng/+bug/1297118
<ubot2> Launchpad bug 1297665 in checkbox-ng (Ubuntu) "Sync checkbox-ng 0.2.2-1 (main) from Debian unstable (main)" [Wishlist,New]
<ubot2> Launchpad bug 1297118 in checkbox-ng (Ubuntu) "checkbox crashed with TypeError in emit_signal(): Don't know which D-Bus type to use to encode type "NoneType"" [High,Confirmed]
<infinity> cjwatson: If ubiquity has to happen anyway, yeah, go ahead with other safe-looking accepts.
 * infinity grumbles about being awake.
<cjwatson> infinity: Just waiting for a test now ...
<cjwatson> (hopefully)
<zul> can an archive admin have a look at python-oslotest, its a new dependency of python-oslo.messaging which is needed by a newer cinder
<dbarth> sil2100: just a quick update: we're adjusting branches in a stack (merging some conflicts in the process) for the oxide silo
<dbarth> sil2100: should be ready soon now
<seb128> Laney, zyga: ^
<Laney> ty
<Laney> looking in a sec
<zyga> looking
<zyga> Laney: nice, I'll do a test run to check if those work now
<Laney> zyga: You guys should include a NEWS file or similar ;-)
<zyga> Laney: we will, good idea
<zyga> Laney: we have a changelog for plainbox that's pretty detailed
<zyga> Laney: but not for the rest of the components yet
<Laney> *nod*
<zyga> Laney: http://plainbox.readthedocs.org/en/latest/changelog.html <- not old fashioned NEWS but we're working on making stuff more discoverable
<Laney> zyga: OK, it all looks alright to me - the only thing I can see is that there might not be anything preventing people installing the new providers with old checkbox-ng; I assume that wouldn't work
<zyga> Laney: it would mostly work but one use case would break
<Laney> OK, if you think that's acceptable then it's fine by me
<Laney> Ready to go after you let me know your testing works out
<zyga> Laney: from what I understand, nobody will install the broken set anymore, as those packages will now be in 14.04 at the right version
<zyga> Laney: right?
<zyga> Laney: I'm just looking but I cannot see them in -proposed yet
<Laney> New people won't be able to, but you could just update one or the other
<Laney> zyga: They need to be accepted from the queue
<Laney> I thought you said you were doing a test run so was going to wait for that
<zyga> Laney: update one? I mean the final image *should* be correct, those are now packages so nobody could get those earlier
<cjwatson> infinity: well, I uploaded dee and geoclue so I probably shouldn't accept them, technically :)
<zyga> Laney: yeah give me a moment then
 * cjwatson uploads ubiquity
<zyga> Laney: I'm not seeing checkbox-ng in -proposed yet either, is that still pending?
<Laney> Yup
<Laney> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<zyga> ok
<zyga> I'll just build all locally
<stgraber> cjwatson: I take it we want this ubiquiti in ASAP? (sorry, still catching up with backlogs from various channels)
<stgraber> *ubiquity
<cjwatson> stgraber: two critical bugs, so yeah
<stgraber> ok, accepting then
<cjwatson> stgraber: I asked infinity if we could have dee and geoclue in the same run, and he was OK with that
<infinity> Sorry, yeah, I'm multitasking very poorly right now.
<cjwatson> I'm kind of failing to multitask.  Maybe a chairnap would help ...
<stgraber> ok, geoclue is just a multiarch change apparently, accepted
<stgraber> dee is a sync from a silo so I'll need to track it down...
<infinity> https://launchpadlibrarian.net/170578019/dee_1.2.7%2B13.10.20130924.1-0ubuntu2_1.2.7%2B14.04.20140324-0ubuntu1.diff.gz
<infinity> Looks fine to me.
<stgraber> yep
<infinity> Does all this new checkbox-related stuff need to be on images?
<cjwatson> Thanks.  I'll check whether ubuntu-sdk-libs-dev:armhf works in an hour or so then ...
<zyga> infinity: not really (IMHO) but ask ara please
<infinity> Oh, also, indicator-china-weather was intended to land on kylin beta, accepting that.
<zyga> ara: ^^
<ara> infinity, not really
<infinity> Kay, cool.
<infinity> Hrm, how did sssd not get auto-accepted?
<stgraber> because it's seeded by edubuntu
<infinity> edubuntu dvd.  I see that, yeah.
<infinity> Shame the queue doesn't.
<stgraber> but since edubuntu-server won't be shipping on media, I'm now dropping it from our seeds and updating edubuntu-meta real quick
<infinity> stgraber: Good thing we're not doing a beta release tomorrow or anything.
<stgraber> infinity: well, since we'll be respinning anyway, I figured I may as well save us a few dozen MBs :)
<infinity> :)
<infinity> stgraber: Be quick, so I can kick off $world (cause, yay, ubiquity).
<infinity> I think we need to come up with an OS that doesn't have an installer.
<infinity> That would be novel.
<stgraber> :)
<cjwatson> the front panel and a load of toggles are all you need
<stgraber> infinity: we could replace our installer by a long wiki page and call that Ubuntoo?
<zyga> Laney: I think it's safe to sync
<Laney> zyga: okely dokely
<zyga> Laney: we found a bug but it's not clear if that's our testing environment or something else
<zyga> Laney: and it's not related to this at all
<zyga> Laney: looks like an existing upstream bug
<infinity> cjwatson: Have you been drinking Kool-Aid with a large blue 3-letter logo on the bottle?
<zyga> Laney: and this upload will fix a log of known bugs so let's do it
<Laney> zyga: ok, good luck fixing then
<cjwatson> infinity: No :-)
<infinity> cjwatson: Was just having flashbacks to me, Anton, and pinky trying to decipher http://www-01.ibm.com/support/docview.wss?uid=isg3T1010983 yesterday.
<cjwatson> *shiver*
<infinity> When the primary interface to your hardware appears to be a first-gen GameBoy, you're probably going to end up with more questions than you started with.
<infinity> That was our conclusion.
<smoser> can someone nak my simplestreams upload ? its not been ack'd yet, and i found a bug to fix.
<smoser> unless its preferred for me to upload a new version, thats possible too
<Laney> sure can
<Laney> voilÃ 
<smoser> gracias.
<stgraber> infinity: ^ (turned out not to contain what I thought but probably still worth getting in anyway)
<infinity> ScottK / Riddell: Whoever triggered that kubuntu rebuild missed the ubiquity update.
<Riddell> infinity: oh didn't know there was one, was looking at our own stuff
<Riddell> infinity: we want ubiquity 2.17.10?
<cjwatson> I think the encrypted-home bug should affect you?
<Riddell> sounds likely
<Riddell> infinity: so you'll rebuild all desktopy images?
<infinity> Riddell: That was my plan.
<Riddell> I'll be holding my breath for that :)
<infinity> Heh.
<infinity> Riddell: Alright, resping of $world triggering now.
<infinity> respin, too...
<infinity> Riddell: Rearranged to throw you at the front of the list.  Cheers.
<Riddell> aww thanks :)
<infinity> Riddell: ^ There you go.
<Riddell> yay!
<boiko> hi guys, so I had some stuff in the CI train, and one of the packages (account-plugins) was marked there as UNAPPROVED because of the freeze
<boiko> I just want to know what exactly should I do once we are past the freeze to get those changes landed
<zequence> infinity: Are you 'bout to rebuild ours too?
<zequence> infinity: I just found I had not fully fixed the bug in our installer. Fixed now. We need to get that uploaded and a rebuild again :P
<Laney> boiko: It'll get reviewed at some point, no need to worry
<Laney> boiko: Maybe not before the beta tomorrow, mind
<infinity> zequence: Whee.  Yours is in my current build pipe.  Maybe if we land your thing in a hurry, it'll make it. :P
<infinity> zequence: Point me at what you need reviewed/sponsored.
<boiko> Laney: that's fine, thanks
<zequence> infinity: lp:ubuntustudio-live
<zequence> bug 1297219
<ubot2> Launchpad bug 1297219 in ubuntustudio-live (Ubuntu) "package selection plugin crashes when deselecting a meta without recommends" [Critical,Fix committed] https://launchpad.net/bugs/1297219
<infinity> Handy, I still have that checked out.
<infinity> zequence: Done.  Let's see if it beats the clock.
<infinity> zequence: If not, we can respin your respin. :P
<zequence> infinity: unapproved?
<infinity> zequence: queuebot was just catching up with reality.
<zequence> infinity: Thanks :)
<infinity> zequence: Looks like that made it into the release pocket before your ISO rebuild slot came up, so we win.
<infinity> zequence: (You're right after ubuntu-server, which is in progress right now)
<zequence> infinity: ooh!!
<jibel> davmor2, something's wrong with latest image. During a live session, I'm connected to the network through a wired connection and I can wget content on the outside, but ubiquity thinks there is no network. Do you see this behavior too? this is with 20140326
<davmor2> jibel: well mac got no connection due to 3rd party driver needed I think so I just finished burning an amd 64 so let me restart my laptop and I'll let you know from there
<jibel> davmor2, hm, it's working now.
<stgraber> edubuntu-artwork is incoming, fixing our currently missing wallpaper (used to be a symlink to a file from ubuntu-wallpapers which got removed between beta1 and beta2...)
<stgraber> there it is ^
<stgraber> least useful diff ever as it can't diff the actual extra file being added and doesn't list symlinks changing :)
<infinity> stgraber: Checking.
<infinity> stgraber: Want to review kio-enslave as pennance?
<infinity> Err, whatever it is.
<infinity> zerconf-ioslave.  That.
<stgraber> so you are trading a 5s unapproved review for a new source package? why do I feel like I'm on the loosing end of that deal? :)
<infinity> stgraber: Because you are. :)
<Laney> Unfortunately I already did it. :P
<infinity> That was quick.  I was still downloading.
<infinity> Since the diff is useless.
<Laney> Yeah, I have quite a good connection to the DC
<infinity> I normally do.  My ISP hates me today.
<infinity> My usual 10MB/s from github has been 50kB/s today.
<infinity> Not happy.
<Laney> EXTREMELY ANGRY
<stgraber> infinity: what's the general opinion about new sources coming with a length debian/changelog for things that probably only ever existed in a PPA? I tend to be of the opinion that this is confusing and should be reduced to a single entry for the initial upload (unless it ever existed in Ubuntu or Debian or was renamed)
<infinity> stgraber: I have no issues with it.  "Initial packaging" or "First upload" are the most uninformative things ever.
<infinity> stgraber: Some history on how the packaging got the way it is never hurts.
<stgraber> well, this time around it's 10 "New upstream bugfix release" which isn't a whole lot more useful :)
<infinity> Heh.  Fair enough, but also not a bug.
#ubuntu-release 2014-03-27
<Riddell> infinity: kubuntu images good (if not perfect) release page at https://wiki.ubuntu.com/TrustyTahr/Beta2/Kubuntu
<infinity> Riddell: Want to email that to me so I don't lose it in backscroll?
<stgraber> marked Edubuntu as ready, did two test installs for each image, I guess that'll have to do. highvoltage will take care of the paperwork in the morning.
<JackYu> hi release team, who could take a look at FFE bug #1293299?
<ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFE]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
<JackYu> thanks so much:)
<infinity> JackYu: When we're in the middle of the beta, that's probably not the best time.
<infinity> JackYu: Unless you're implying that you want that in, and in your images, and a respin and test before I wake up...
<JackYu> infinity, yes, we can:). It's 3pm here.
<infinity> JackYu: (Honestly, I'm not sure that's a realistic goal)
<JackYu> infinity, but there needs time to upload it...
<infinity> JackYu: Yeah.  I think we'll be happy to review it after the beta freeze, pretty sure that's not a sane goal to accomplish in the next ~8h, which is when I expect all the image testing to be done.
<JackYu> infinity, yep. We can upload it after this beta.
<JackYu> infinity, sure, thanks:)
<infinity> JackYu: Out of interest, why a whole new software-centre, instead of figuring out a clever way to add your apps to ubuntu-software-centre and maybe score them higher in searches?
<infinity> JackYu: That would seem like the better integrated approach.
<infinity> JackYu: USC already has the ability to read multiple databases.
<infinity> JackYu: (See app-install-data and app-install-data-partner)
<infinity> JackYu: An app-install-data-chinese or something would make sense, I'd think.
<JackYu> infinity, en, you are right. We have discussed with the USC team. Since more and more customized features would be included into UKSC, they suggest to create a new one.
<JackYu> infinity, and the UI of UKSC would be more easy for Chinese users:)
<infinity> A fork is probably going to end up being a lot more work than you want it to be, though. :/
<infinity> Anyhow, bring it up in the channel after beta release, when one of us can dedicate some more time to the matter.
<infinity> I should stop arguing with nodejs on powerpc and sleep at some point, so I can do the release tomorrow.
<JackYu> infinity, yep, we tried. But USC is a big project:(.
<JackYu> infinity, OK, thanks. Good night!
<infinity> JackYu: If you can articulate exactly what you need, and why it needs to be different, we may be able to reopen the conversation with the USC folks.  I'd really prefer it be integrated instead of forked, if we can make that happen for you.
<infinity> JackYu: (Perhaps in the bug, so it doesn't get lost in IRC backscroll)
<JackYu> infinity, sure. I will add some information on the bug.
<infinity> JackYu: Thanks.
<infinity> JackYu: To be clear, I assume you're open to the idea of integration, if USC upstream can be talked into it, right?
<JackYu> infinity,  To be honest, I prefer to create a UKSC, instead of integration.
<JackYu> infinity, we talked to USC team, but they are much busy...
<JackYu> infinity, at the beginning Trusty, we have some conf call with USC team. They were busy with Ubuntu Store.
<infinity> jibel: If you run into anything that you think absolutely must be release noted for the beta, can you add it to the wiki, or poke me about it while I sleep?
<infinity> jibel: Not sure how much timezone overlap we'll have.
<jibel> infinity, okay, major issue ATM is wrong keyboard during live session and after installation for some flavors. I'm trying to understand if that's 1 or 2 issues and will upadte the release notes.
<infinity> jibel: Ta.
<elfy> jibel: just so you are aware this issue pitched up shortly after the ibus update to 1.5.5 but we have had no luck trying to go back to a previous version
<infinity> elfy: As in, you've ho luck talking people into reverting, or trying to revert hasn't made the bug go away?
<elfy> infinity: as in the people trying to go back to previous version weren't able to
<elfy> ended up with dependency issues I think - it was knome doing it
<elfy> infinity: purging ibus fixes the issue
<infinity> elfy: Fun.
<elfy> loads ...
<elfy> anecdotally it's affected other keyboard layouts
<elfy> but I've not seen that in bugs
<infinity> We'll definitely need to make sure someone prioritized that one post-beta.
<elfy> that will be good - up to now this bug hasn't really had much traction outside of xubuntu
<infinity> Right, well.  If it *is* due to our ibus changes, Canonical engineers shouldn't be breaking flavours gratuitously, so if you have well-documented bugs with clear reproducers, I'll make sure someone stares at it grumpily for a bit.
<elfy> thanks :)
<infinity> Probably William Hua, he seems to understand ibus.
<infinity> At least, more then people like me, who don't understand it at all. :P
 * elfy too 
<jibel> infinity, elfy bug targeted to trusty and assigned to the desktop team
<elfy> jibel: thanks :)
<jibel> seb128, salut, bug 1284635 is for your team I guess
<ubot2> Launchpad bug 1284635 in ibus (Ubuntu Trusty) "Keyboard layout changes after login" [High,Confirmed] https://launchpad.net/bugs/1284635
<seb128> jibel, salut, I saw it, do you have an install in that state by any chance?
<seb128> jibel, what is in /etc/default/keyboard?
<jibel> seb128, no, I couldn't reproduce on Ubuntu, I'll try on Xubuntu but I've another high/critical issue to confirm before that
<seb128> ok, thanks
<seb128> jibel, if it doesn't happen on Ubuntu I'm unsure it's for our team...
<infinity> seb128: It's for your team if an upload by your team broke other flavours, IMO.
<infinity> seb128: But we can argue that when I'm not supposed to be asleep. :P
<jibel> seb128, it's a bug introduced by ibus 1.5.5
<seb128> infinity, right, but I don't think we changed anything, that's coming from upstream/debian
<seb128> the xfce/ibus integration might be buggy
<seb128> anyway, I've no clue about ibus
<seb128> I'm going to ask happyaron to have a look though
<jibel> thanks
<seb128> but I don't think that's going to happen this week
<seb128> he's busy dealing with ubuntukyling work afaik
<infinity> Well, it's too late for beta (obviously), just want someone to give it a good stare before release.
<elfy> seb128: it's not just xfce - it's lxde as well
<seb128> elfy, but it's not happening in Unity?
<elfy> I didn't see it there
<seb128> well, anyway, assigned to happyaron, let's see when he finds a slot for it, as said he's quite busy
<elfy> seb128: and in an install that has the issue /etc/default/keyboard looks right for a UK keyboard
<infinity> If the bug is reasonably well documented and we're (fairly) sure it's ibus, a bisection might not be too tough.
<infinity> It can't have changed THAT much in the last couple of upstream microreleases.
<seb128> infinity, ibus doesn't work that way
<seb128> their "microreleases" include rewrite of part of codes and features
<seb128> they are just new versions
<infinity> seb128: That's not comforting. :P
<seb128> I know :/
<seb128> well, happyaron and others are going to tell that we should use fcitx, they keep pushing for that
<infinity> A little late for trusty, methinks.
<seb128> we just never managed to get anyone wanting to look to IMs on our side
<seb128> right
<seb128> well, UbuntuKylin is using fcitx
<infinity> Yeah, but they also only have one (two, I guess) languages they care about.
<seb128> right
<infinity> Validating it for every current ibus consumer is probably a bit tougher.
<seb128> but they are the only people who are doing IM work for us
<seb128> or having knowledge on the topic
<infinity> Aaaaanyhow.  Really going to bed now.  Tomorrow morning is going to come way too early and suck way too hard.
<seb128> I don't even know how to input stuff with ibus
<seb128> infinity, night!
<elfy> infinity: good night :)
<infinity> seb128: Yeah.  I used to care when I ran my desktop in Japanese, but I never cared enough to learn how it all worked.  I was just simultaneously amazed that it worked at all and frustrated that it didn't work as well as Windows, and stopped doing it.
<infinity> That was almost a decade ago, though.  I really hope it sucks less today.
<jibel> confirmed bug 1298251 on kubuntu only
<ubot2> Launchpad bug 1298251 in ubiquity (Ubuntu Trusty) "[kubuntu] Ubiquity crash when starting LiveCD with a chosen language" [High,Confirmed] https://launchpad.net/bugs/1298251
<cjwatson> hmm, I don't like the look of process-cpp/unity-scopes-api/unity-mir being accepted without dbus-cpp - wonder what's going on there
<cjwatson> ah, it's in the ubuntu-desktop packageset but not images
<cjwatson> reviewing manually then
<cjwatson> no-change rebuild, ok :)
<doko_> stgraber, liburcu ftbfs on armhf
<jibel> apw, there are 2 kernel bugs in the release notes, bug 1054732 and bug 1066883 , they are almost inactive since saucy, should they still be mentioned in the release notes for Trusty?
<ubot2> Launchpad bug 1054732 in linux (Ubuntu) "[LENOVO 4298R86] suspend/resume failure" [High,Incomplete] https://launchpad.net/bugs/1054732
<ubot2> Launchpad bug 1066883 in linux (Ubuntu Saucy) "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<jibel> apw, also any new issue that should be added to the release notes?
<jibel> jamespage, there is no result for MaaS on the tracker, has it been tested?
<rtg> jibel, apw is out until tomorrow. as for bug #1066883, I have a Mac mini that appears to be working fine. I'll reconfirm using today's daily.
<ubot2> Launchpad bug 1066883 in linux (Ubuntu Saucy) "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
<jibel> rtg, thanks. Anyone from the kernel team could review the release notes of Beta2? Leann is out too apparently.
<rtg> jibel, URL ?
<jibel> rtg, https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes
<jibel> looks like we have the perfect kernel :)
<rtg> right :)
<jamespage> jibel, matsubara was going todo that - I'll ping him
<jibel> jamespage, thanks
<rtg> jibel, the Kernel release note about suspend/resume issues is likely still accurate. There are about a zillion suspend/resume bugs against Trusty right now, so I'd just leave it in the notes.
<rtg> jibel, I'm getting ppisati to review the OMAP4 installation note.
<jibel> rtg, Ta. also add any major kernel issue that you think is worth mentioning.
<rtg> jibel, well, like you said, we have the perfect kernel :)
<jibel> rtg, I know, we do the same in QA, don't test so there is no bug ;)
<rtg> jibel, oh, there are plenty of bugs. the suspend/resume issues are the only problems that I know of that are systemic.
<stgraber> doko_: I'll look into it, thanks
<stgraber> doko_: upstream is on it
<stgraber> doko_: so apparently the problem is gcc 4.8.x on arm producing some invalid code (http://git.lttng.org/?p=userspace-rcu.git;a=commit;h=b52a3dc23521f7a21fb5ab3d2b53dad89c586ee4). I'm trying to get the details of what exactly the bug is, whether they reported it upstream and whether it's been fixed there...
<stgraber> the obvious problem is that our current liburcu which was rebuilt a few days ago when xnox did some packaging changes is likely currently affected by this...
<doko_> # ifdef __ARMEL__
<doko_> then why on hard float?
<doko_> stgraber, and if it really is a GCC bug ;p ...
<stgraber> doko_: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 is apparently the bug in question
<ubot2> gcc.gnu.org bug 58854 in target "[4.8 regression] "sub sp, fp, #40" hoisted above frame accesses" [Normal,Resolved: fixed]
<doko_> stgraber, fixed in trusty
<stgraber> doko_: cool, is that because it made it to a stable release or did we cherry-pick?
<doko_> stgraber, gcc patches are updated to the current branches
<doko_> will ask for an 4.8.3 sru for 14.04.1 ...
<stgraber> doko_: good, I'll patch out that chunk of code and re-upload then. Thanks for checking.
<jibel> FYI not the final report but close to: https://wiki.ubuntu.com/QATeam/ReleaseReports/TrustyBeta2TestingReport
<doko> stgraber: please could you force gnat into trusty?  the dependency packages don't yet exist
<infinity> doko: Why would we need to force it in when the only change is to those deps?
<infinity> doko: Raising the uninst count for nothing doesn't make sense.
<doko> infinity, it's not raised. it's the same before and after the change
<infinity> doko: Okay, changing the uninst profile, then?  Still doesn't make sense.  If the packages are going to exist, it'll migrate when they do.
<infinity> "Migration at any cost" shouldn't be the goal.
<infinity> zequence: There don't seem to be any results for studio/amd64.  Has anyone smoketested it at all?
 * lamont has a question about postgresql SRU -- when do we expect that to come from -proposed into -updates, assuing all goes well?
<infinity> lamont: Monday.
<infinity> lamont: Though, we could release it today.
<zequence> infinity: Just about to
<infinity> zequence: Ta.
<lamont> infinity: if it's going to be "by monday", today would make my life simipler
<lamont> but "make lamont's life simpler" is not a valid release reason
<infinity> lamont: Sure.  I've pinged pitti to get his take on it.  If he thinks it's well-tested, I'm fine with releasing it a day early.
<lamont> ta
<stgraber> highvoltage: is the paperwork for Edubuntu 14.04 beta 2 ready?
<highvoltage> stgraber: no :( (I was just dreading when you'll ask me but I'll check it in a minute)
<rtg> jibel, ppisati says the Installation release not regarding ARM OMAP4 is no longer relevant. That bullet item can be removed.
<rtg> note*
<rtg> jibel, the release note "On a mac with an external display" can also be removed. I've installed with Trusty desktop daily on a mac-mini with no issues.
<highvoltage> stgraber: what will the urls be for the iso images? http://cdimage.ubuntu.com/edubuntu/releases/trusty/beta-2 ?
<stgraber> highvoltage: yep
<jibel> rtg, thanks for the confirmation
<highvoltage> stgraber: any noteworthy bugs found during testing? I see none are mentioned on the tracker and the previous bugs that were listed during alpha 2 were resolved
<jibel> infinity, I added the most important issues found during testing to the release notes
<stgraber> highvoltage: nope, just the usual list of bugs from Ubuntu
<infinity> jibel: Thanks, you're a champion.
<stgraber> highvoltage: I'm not aware of any Edubuntu-specific bug at this tage (besides us sucking at putting new stuff into that release :))
<highvoltage> stgraber: *nod*
<highvoltage> stgraber: ok seems in order, will probably make some small edits still after proof-reading again
<highvoltage> (kubuntu's release notes are really nice I'm going to steal some ideas there next time)
<stgraber> highvoltage: cool, are we doing wiki-only like the past few milestones or are you also doing the whole blogpost thing?
<stgraber> highvoltage: in either case, you'll want to give the URL to infinity for inclusion in the announcement
<zequence> infinity: Link to our release announcement http://ubuntustudio.org/2014/03/beta-2-is-out/
<highvoltage> stgraber: wiki only, but I think we should do some form of blog post soon anyway as a status update (doesn't have to be directly coupled to the releast though)
<highvoltage> *release
 * infinity wishes we hadn't gotten into this linking to separate announcements in the release announce habit, it's a monumental pain to collect them all.
<stgraber> infinity: you can also do it the lazy way as I've been doing for the past few milestones, copy/paste the previous announcement to etherpad, post link on IRC, let everyone edit
<stgraber> at release time, copy/paste in mail client + send, done :)
<zequence> I'm stuck with burning a DVD (which so often ends up with failure, at least for me), since my computer at times doesn't like my usb sticks. While I wait for it to finish, I'm going to the store. If the gods approve, I'll finish testing our amd64 image within an hour
<infinity> zequence: Yeah, that's fine.  I need to clean up paperwork and such, we're not releasing in the next half hour. :P
<jibel> infinity, I'll sent the testing report and I think Beta 2 is as good as it can get.
<jibel> *send
<infinity> jibel: Many thanks.
<Riddell> infinity: ETA for release?
<infinity> Riddell: I think I said mid-to-late-afternoon before.  Let's say ~4h.
<Riddell> groovy
<cjwatson> infinity: Can we start flushing out unapproved?  I know the CI folks would love to get some silos back
<infinity> cjwatson: Yeah, I think we're mostly green, and anyone who's late to the party isn't getting a respin now, they're getting a not ship.
<cjwatson> That's what I figured
<cjwatson> Somebody who isn't about to EOD might want to look at the FFe associated with the webapps landing currently in unapproved, and see if it can be approved
<cjwatson> I'd rather not accept it before that's done
<cjwatson> I think I've run out of steam for today, somebody else can look at the rest of the queue :)
<Laney> I'll do some tomorrow
<Laney> FFe queue needs some attention too
<Laney> Cheers for the reviews thus far
<zequence> infinity: Done
<Saviq> hi, can we please have unity8 pushed through from proposed?
<infinity> Saviq: We'll get there.
<Saviq> infinity, ok thanks, I know you're swamped
<infinity> Sonofa...
<infinity> stgraber: How did we completely miss adding mythbuntu to the manifest?
<infinity> superm1: And how did you miss telling us? :P
<stgraber> infinity: that's a good question, my best guess is that since they are LTS-only and didn't participate in any of the trusty milestones, we just never had them in the list to begin with.
<stgraber> whereas all the others did either participate in the saucy release or did a milestone release for trusty already
<infinity> stgraber: Yeah.  And I'm thinking the LTS-only thing is also why THEY didn't notice, since they haven't done a milestone in 2 years, and fell out of the habit. :/
<infinity> Anyhow, if they step up tomorrow and say "whoa, wait, halp, we want to do our release, honest", I don't think I'll disqualify them for missing the beta.
<infinity> Since it seems like no one remembered them on either side. :P
<superm1> infinity: we didn't notice because i've been really busy with other stuff :(
<infinity> superm1: Well, as pointed out, it seems NO ONE noticed.  So, I'm waiving the usual "if you don't do beta, you don't get to do release" stipulation.
<superm1> phew :)
<infinity> superm1: But, it might be in your best interest to get testing dailies ASAP, so you know what you'll need to fix for final.
<superm1> yeah i know we have some problems right now
<superm1> i'm going to try this weekend to help sort them out
 * infinity lunches while he waits on mirror propagation.
<infinity> zequence: Your studio announce is a 404, is that going to be not true soon?
<utlemming> infinity: whats the eta for release?
<utlemming> infinity: wondering if I should disappear for a hour or so
<infinity> utlemming: It's basically all ready, except for a website hiccup.  We'll see how long that takes to get resolved and, if it doesn't, I'll just use a different URL in the announce mail.
<infinity> utlemming: But I'm in no massive rush.  I'll wait another couple of hours before pressing the button, probably.
<utlemming> infinity: ack...okay, can you ping me via email and I'll make the cloud images public then
<zequence> infinity: Published now, thanks
<infinity> zequence: I beg to differ.  Or you gave me to wrong URL. :P
<infinity> zequence: Good thing I didn't send yet.
 * infinity fixes his reference.
<jdstrand> infinity: hey, I have not assigned ubuntu-release yet, but can you look over bug #1298611 and comment?
<ubot2> Launchpad bug 1298611 in linux (Ubuntu) "[FFe] apparmor signal and ptrace mediation" [Undecided,New] https://launchpad.net/bugs/1298611
<jdstrand> infinity: note, we've already discussed with the kernel team and they said they would perform the pull on monday once we were satisfied with our testing
<infinity> jdstrand: In a bit.
<zequence> infinity: Ah, the url was changed after I edited the post. Thought it wouldn't, sorry
<jdstrand> infinity: thanks. I don't need the full review now-- just want to alert you to it and hear your feedback
<jdstrand> (preliminary feedback)
<infinity> utlemming: Is 'http://cloud-images.ubuntu.com/releases/14.04/beta-2/' expected to exist at that location soon?
<utlemming> infinity: how about now?
<utlemming> infinity: the sync is running now, so images will appear in a few minutes
<infinity> utlemming: Cool, was just link validating my emails and such.  Didn't mean to make you do it Right Now.
<infinity> (Not that it hurts to have it up now)
<utlemming> infinity: meh, I was doing it anyway actually :)
<infinity> jdstrand: Pointers to the kernel and userspace diffs, with a bit more explanation than "yo, this is a feature" might be nice. ;)
<infinity> jdstrand: The promise of backward compat from both sides is good, but it would be nice to see how isolated or invasive this looks.
<jdstrand> infinity: right, that is why I didn't subscribe the release team yet
<jdstrand> I more wanted a 'conceptually, this is ok to proceed' kind of thing
<jdstrand> infinity: I can say for the kernel, it should be isolated to the apparmor LSM, but I'll let jjohansen comment
<infinity> jdstrand: Also, do be very aware that while you don't have to get the feature correct on the first upload, you have to make damn sure it doesn't break anything else, cause this next kernel upload is likely to be the last, barring some massive bug we need to rewind for.
<jdstrand> infinity: for the userspace, we need parser updates and a few other things, including policy updates
<infinity> (Well, you should try to get it correct on the first go, but you know what I mean, pay special attention to regressions, even moreso than testing the feature itself... Broken new feature fine, broken old feature bad)
<jdstrand> infinity: yes, we are keenly aware of that point
<jdstrand> infinity: the packages that ship policy that need to be adjusted need to still be enumerated. for sure libvirt and lxc. others tyhicks will be investigating. those debdiffs will but a few lines (at most) of apparmor policy
<infinity> jdstrand: If it's any consolation we're still making changes to the ppc64el kernel too.  This "last upload" will be a lot more changeful than it should be. :/
<jdstrand> jjohansen: can you give infinity the location of the pull request you expect to have ready soon?
<infinity> jjohansen: Just toss it in the bug.
<jdstrand> infinity: this should be quite self-contained aiui, but I'll direct you to jjohansen for specifics
<jdstrand> (the kernel bit)
<jdstrand> infinity: fyi, we did the recent 2.8.95 userspace upload recently to make this FFe easier to manage for you guys
<jdstrand> tyhicks is working on a bug fix upload for that now. next week we'll have the debdiff for signals/ptrace on top of that
<infinity> Argh.
<jdstrand> oh?
 * jdstrand is talking about the userspace, not kernel
<infinity> jdstrand: Sorry, that argh wasn't for you, it was for pycxx being accepted.
<jdstrand> (and as mentioned in the bug, they can be done at different times)
<jdstrand> ah
<jdstrand> :)
<infinity> (Who accepted pycxx?)
 * jdstrand did not
<jdstrand> :)
<infinity> Was a human, not a bot.
<infinity> If only we had queue auditing.
<jdstrand> infinity: so, I think that is the big picture. jjohansen will git you the kernel git tree for review and he can answer questions re that
<infinity> jdstrand: Is git a verb now? :)
<jdstrand> we might tinker a little before I ask you to look at the FFe more officially (and before the kt pull request)
<jdstrand> haha
<jdstrand> that was a funny typo
<jdstrand> and I/we'll add the MPs/debdiffs for the userspace changes when we are ready for review
<jdstrand> infinity: thanks for the pre-review :)
<infinity> jdstrand: Alrighty.  Here's hoping it all goes smoothly.
<jdstrand> yes :)
<infinity> jdstrand: Conceptually, I'm fine with it, the reality could be scary.
<jdstrand> right, that is why we'll prove it is good in testing
<infinity> jdstrand: *nod*
<infinity> jdstrand: Just be prepared for the let-down of a possible rejection and demand for a month of testing before landing it into the 14.04.1 kernel.
<infinity> jdstrand: (But let's hope we can do better)
<infinity> jdstrand: Well-documented testing will go a long way.
<jdstrand> that wouldn't be the worst thing
<jdstrand> but yeah, we'll get that to you
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final Beta | Archive: Gated Review | Trusty Tahr 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
<Riddell> infinity: awooga!
<infinity> Riddell: Thanks for being on the ball with nice release notes and upgrade pages.  You were one of the few. :)
#ubuntu-release 2014-03-28
<cjwatson> Saviq: I dealt with unity8
<Saviq> cjwatson, awesome, thanks
<knome> infinity, hey! :)
<infinity> stgraber: So, how do I mark a milestone released in the tracker, so I can turn dailies on again and not overwrite all the entries?
<knome> infinity, we need to upload a new xubuntu wallpaper relatively soon... would you approve a UIFe bug if we filed it quickly, even if we didn't have all the things prepared quite yet (naturally described though)
<infinity> knome: If you're just swapping around images, a new wallpaper isn't a feature, IMO.  Just a UIF thing, and since you handle all your own docs, the only people you're hurting is yourselves if you have to take new screenshots.
<infinity> knome: (Unless you're drastically changing the structure of the package or something?)
<knome> infinity, that's why i said UIFe, and no, we're not doing weird changes. just to get it socially accepted
<infinity> knome: Oh, you really did say UIFe.  I've had a long day.
<knome> no problem :)
<infinity> knome: If you want me to tell you your wallpaper's pretty, I can do that. :)
<knome> of course!
<knome> ;)
<infinity> knome: But yeah, from a docs perspective, I imagine the only person whose approval you need is your own.
<knome> yeah. we're fine docs-wise, we're not shipping screenshots
<infinity> knome: And I think I trust you enough not to ship a wallpaper that's a 20x20 grid of naked breasts.
<knome> hmm...
<infinity> Okay, I *did* trust you.
<knome> that opens a whole new possibilities
<knome> hah :)
<knome> i'll get the butt... i mean bug filed
 * knome whistles
<ScottK> infinity: Nudity is traditional for Ubuntu anyway.
 * knome makes a mental note to start working on the wallpaper earlier next cycle
<knome> fourth time in a row when we go over the UIF deadline...
<infinity> knome: Also, no screenshots?  Do you not have a ubiquity slideshow, or do you just cop out and use the Ubuntu one?
<knome> we have ubiquity slideshow, but our screenshots do not have the wallpaper pictured :)
<infinity> Ahh.  Handy.
<knome> and the slideshow background itself is just an arbitrary blue background ;)
<knome> nobody will ever notice the difference anyway...
<knome> infinity, bug 1298711
<ubot2> Launchpad bug 1298711 in xubuntu-artwork (Ubuntu) "[UIFe] New Xubuntu wallpaper" [Undecided,New] https://launchpad.net/bugs/1298711
<knome> infinity, and since i want you to say the wallpaper is pretty: http://temp.knome.fi/.w/xubuntu-trusty.png ;)
<knome> the changes are in the branch as well.
<infinity> knome: Too much yellow, rejected.
<knome> oh shoo ;)
 * infinity checks the branch for sanity.
<knome> yeppers.
<infinity> knome: Looks good.
<knome> as you happened to say "yellow", i have to show you this another variant we considered... http://temp.knome.fi/.w/trusty-yellow.png
<infinity> apw: I'm guessing that's not the "final upload", since there are apparmor things on the table and such still, right?
 * infinity isn't even remotely in the mood to review that libreoffice upload...
<stgraber> infinity: admin => milestones => edit => mark as released
<stgraber> done that for you now
<infinity> stgraber: Oh, I keep forgetting there's an admin thing.
<infinity> stgraber: Thanks.  I shall go re-cron the world shortly.
<infinity> stgraber: Can we ditch /home/ogra/sync-phablet-images entirely?
<infinity> (world re-cronned)
<stgraber> infinity: I have no idea what that script does, but hopefully it can die, yes :)
<infinity> stgraber: I'll poke Oli about it sometime.  It's been commented out for ages, so I assume it's dead code.
<infinity> stgraber: Figured you might know, since you're more involved in the phone image stuff.
<stgraber> I maintain system-image, as far as s-i is concerned, you could give it ubuntu core images or tarballs of lolcats, it really doesn't care ;)
 * infinity feeds system-image tarballs of locales for the next week.
<Mirv> note qtlocation FFe bug #1298208 lacking from the changelog
<ubot2> Launchpad bug 1298208 in qtlocation-opensource-src (Ubuntu) "[FFe] Qt Location sync packaging with Debian (new binary package)" [Wishlist,Triaged] https://launchpad.net/bugs/1298208
<seb128> can somebody approve the libffi revert in unapproved?
<seb128> update-manager, apport (and probably others) segfault on start with the libffi update from this night
<seb128> that's going to bite beta upgrader if they can't run update-manager again
<seb128> to get the fixed version
<infinity> Lemme diff it against 3.0.13-12 and accept it.
<seb128> doko_, btw, how come that new libffi was uploaded with a ffe?
<seb128> it seems weird that upload was accepted in the first place :/
<seb128> infinity, thanks
<infinity> Yes, I'm still curious WHO accepted it.
<infinity> And hoping the answer isn't "doko".
<infinity> Though, a syncpackage as an AA might skip the queue, I can never remember.
<Laney> 27/03 17:26:17 -queuebot:#ubuntu-release- Unapproved: libffi (trusty-proposed/main) [3.0.13-12 => 3.1~rc1-2] (core) (sync)
<Laney> 27/03 18:16:42 -queuebot:#ubuntu-release- Unapproved: accepted libffi [sync] (trusty-proposed) [3.1~rc1-2]
<infinity> Okay, that definitely looks like a human was involved.
<infinity> And I'd like to think no one on the release team thought "hey, a new RC version of a core system library, that sounds safe". :/
<infinity> Now, here's hoping nothing was rebuilt against the new libffi that now needs to be re-rebuilt.
<infinity> (Can someone more awake than I am try to sort that out?)
<seb128> infinity, let me try to have a look
<Laney> infinity: were you looking at apparmor?
 * Laney la la la
<didrocks> infinity: if it's binary only through sync, it skips the queue, no?
<didrocks> that's what I see for daily-release/CI Train
<didrocks> (hence the NEW review at the publication beforehand)
<infinity> didrocks: Hrm?
<infinity> didrocks: Yes, binary NEW skips the queue on copies.  Has nothing to do with the libffi thing, which was in unapproved, and manually accepted by $someone.
<Laney> he's asking if copies with NEW binaries skip the NEW queue
<Laney> for qtlocation
<didrocks> Laney: no no, I was talking about libffi based on infinity's remark
<Laney> oh I see!
<didrocks> infinity: yeah, there is the UNAPPROVED queue anyway, so humanâ¦
<infinity> \o/ for Qt5 syncing with Debian.
<infinity> Well, bits of it.
<Laney> Daviey: There's curtin and simplestreams in unapproved, you interested?
<Laney> They might or might not relate to bug #1281760 and bug #1281767 which never got replied to
<ubot2> Launchpad bug 1281760 in curtin (Ubuntu) "FFE: curtin enhancements for 14.04" [Undecided,New] https://launchpad.net/bugs/1281760
<ubot2> Launchpad bug 1281767 in simplestreams (Ubuntu) "FFE: simplestreams by-hash storage" [Medium,New] https://launchpad.net/bugs/1281767
<Laney> smoser: ^^^ are those still relevant?
<cjwatson> infinity: syncpackage as an AA doesn't skip the queue - I was very careful to make that a separate flag, not purely which team you're in
<infinity> cjwatson: Right, --auto-approve.
<infinity> cjwatson: I was just hoping for an excuse for that libffi accept that didn't look like malice or incompetence. :P
<infinity> cjwatson: But the 1h window between it hitting the queue and leaving again make it clear a human was involved, either the uploader, or a reviewer who really didn't review.
<ogra_> infinity, /home/ogra/sync-phablet-images can completely go from crontab
 * ogra_ was meaning to clean that up a while ago but never got to it
<infinity> ogra_: Kay, thanks.
<knome> infinity, hey, ##StartTrustyReleaseBugs and ##End... were used to include the common infra bugs to flavor release notes, added them back as you had removed them from the wiki page either accidentally or on purpose; on the latter case, what's the new desired way?
<infinity> knome: I probably just removed them when doing copy and waste to make the new release notes.
<knome> ok, that's good
<infinity> knome: Though, honestly, I don't see the value in per-flavour release notes at all.  I thought we'd settled last release on a single shared page.  People keep rethinking this every two months. :P
<knome> that's fine to me
<knome> we should just do the change then
<knome> i can make xubuntu appear in the main release notes, if that's the goal..
<infinity> knome: I'll bring it up on the -release list when I'm not (still) awake at 5am, and we'll sort it one way or another before final and make sure everyone's doing the same thing.
<knome> great.
<didrocks> seb128: autopkgtest for glib2.0 2.40.0-1: FAIL (Jenkins: public, private)
<didrocks> on libiffi
<didrocks> in case you didn't look
<Laney> fixed
<Laney> well, it worked on a retry ...
<Laney> racy tests ...
<seb128> didrocks, thanks
<didrocks> yw, was browsering proposed-migration for powerd :)
<Daviey> Laney: Yeah, i'll take a look shortly
<Daviey> How are we currently handling seeded packages that aren't Beta blocking?
<Laney> Daviey: Beta's done, can you be more specific?
<Daviey> Laney: Oh, I missed Final Beta.
<Daviey> See the mail now. thanks
 * Laney nods
<smoser> Laney, by hash storage not. (1281767)
<smoser> Laney, the upload in queue for curtin fixes 1281760 (all but LVM/raid).
<Laney> smoser: ok, looks like Daviey accepted those
<Laney> please mangle the bugs as appropriate
<Laney> doh, missed arm64 in gtkpod
<stgraber> could someone please look at bug 1297363?
<ubot2> Launchpad bug 1297363 in systemd (Ubuntu) "[FFe] Add cgmanager support" [Undecided,New] https://launchpad.net/bugs/1297363
<stgraber> if whoever ends up reviewing the LXC upload wants an upstream changelog to check against, we have https://linuxcontainers.org/news
<stgraber> I'll also be applying for an MRE for LXC 1.0.x in 14.04 as it's way easier for us to fix bugs upstream then do a point release than maintain and document dozens of cherry-pick (as we've been doing until 1.0)
<zul> can someone accept cinder as well (LP: #1299010) please
<ubot2> Launchpad bug 1299010 in cinder (Ubuntu) "FFE for cinder 2014.1.rc1" [Undecided,New] https://launchpad.net/bugs/1299010
<stgraber> zul: I'm going through the queue now (for those which aren't my own uploads that is)
<zul> stgraber: thanks
<Laney> Pasting a git shortlog into a bug as its only content isn't the most useful FFe ever
<stgraber> it's also not terribly good practice to upload to the queue before the FFe has been reviewed by the release team...
<doko> what is the oif package set?
<stgraber> rejected from the queue for now and commented in the bug with a comment similar to Laney's
<seb128> doko, open input framework (the Ubuntu/Unity touch stack), why?
<doko> seb128, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html ftbfs everywhere
<zul> stgraber:  hey we are starting to get openstack rc1 out the door today and on monday....if its ok i was going to create a single bug for all of the openstack components and get the release team to ack it
<stgraber> zul: single bug with per-package tasks should be fine, so long as you to a bit more work on describing what's new than you did with cinder
<zul> stgraber:  sure
<seb128> doko, well, I guess somebody is going to have to debug it, it didn't get any work for cycle and chase left Canonical a while ago
<rbasak> How does the release team feel about me pushing an MRE for mysql-5.5 at this point in the cycle? Or should I just wait for release?
<rbasak> It's on my todo, and AIUI doing the supported releases is blocked by doing trusty first. I've not had to deal with this before.
<JackYu> infinity: hi, I have added some comments on bug #1293299 :)
<ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFE]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
<seb128> ^ I've pushed that ido update, please ping me if you have questions about it
<seb128> it includes https://code.launchpad.net/~larsu/ido/basic-menu-item/+merge/213037
<seb128> which is a bit of code changes (new widget basically)
<seb128> I consider it as a bugfix and not a feature (it's basically support for non-squared icons to use in indicator-power/desktop only)
<seb128> I'm open to discuss it if people think it's border line, but please ping me before eod if you want to discuss it ;-)
<ahasenack> I guys, I uploaded a fix for https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1293990 to trusty-proposed, wondering what the next step is. Should I subscribe the release team to the bug?
<ubot2> Launchpad bug 1293990 in landscape-client (Ubuntu Trusty) "error: config file /etc/landscape/client.conf can't be read" [High,In progress]
<seb128> ahasenack, it has already been accepted, you should have received email?
<seb128> ahasenack, or subscribe to trusty-changes
<ahasenack> seb128: I got an email about it being accepted into trusty-proposed
<ahasenack> is that it?
<seb128> right
<seb128> yes, same as usual
<ahasenack> ah, cool
<ahasenack> thanks
<ahasenack> ah, ok, I got two
<seb128> it's going to migrate to trusty once it has built/if it's installable and doesn't fail tests
<seb128> well, we are frozen
<ahasenack> first one was waiting for approval, the other one was accepted
<ahasenack> ok
<seb128> so it goes to "unapproved" first
<seb128> then it gets accepted to proposed
<seb128> which is basically what you directly get with upload in nonfreeze times
<ahasenack> seb128: thanks for the explanation
<seb128> yw!
<ahasenack> and I see a bot here make sure such things are announced ;)
<zul> stgraber:  https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1299055
<ubot2> Launchpad bug 1299055 in openstack-trove (Ubuntu Trusty) "Icehouse tracker for rc1" [Undecided,New]
<seb128> do you guys consider https://bugs.launchpad.net/indicator-power/+bug/880881 as a feature/needing a ffe?
<ubot2> Launchpad bug 880881 in indicator-power "[ffe] Power indicator does not combine multiple battery status" [Medium,In progress]
<seb128> or a bugfix?
<stgraber> sounds like a bug to me
<Laney> I guess it's debatable, but it's fine to get in imho
<seb128> stgraber, Laney: thanks, I'm getting it in a silo then
<seb128> thanks to whoever is reviewing/approving those ;-)
<doko> stgraber, infinity: could you point ubuntustudio and lubuntu maintainers to the ftbfs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html ?
<stgraber> I've done a few of those but I suspect Laney is also doing some of those
<Laney> Nein
<stgraber> zequence: ^
<Laney> Someone else can have the credit for the recent ones
<cjwatson> seb128: trying to keep on top of things, although I infer it isn't just me
<stgraber> ah, so that was cjwatson then :)
<cjwatson> yep
<stgraber> cjwatson: yeah, I've noticed we collided at least a couple of times ;)
<cjwatson> I noticed lxc's changelog referenced a bug without an lxc task on it
<cjwatson> you still have time to fix that if you want to ...
<seb128> cjwatson, stgraber: thanks ;-)
<cjwatson> queue clear for now
<stgraber> cjwatson: task added
<cjwatson> thanks
<zul> sorry can a release team member ack: https://bugs.launchpad.net/bugs/1299055
<ubot2> Launchpad bug 1299055 in openstack-trove (Ubuntu Trusty) "Icehouse tracker for rc1" [Undecided,New]
<jdstrand> that ^ is for oxide landing
<stgraber> jdstrand: things that are only on the touch image get auto-approved
<jdstrand> yeah, I forgot
<jdstrand> thanks
<slangasek> jibel: hi, so doko is telling me that the libffi that made it into the trusty release pocket overnight had broken revdep autopkgtest runs, but migrated anyway
<slangasek> jibel: this seems like a significant bug, do you think this is something we should dig into today before the trail gets too cold?
<seb128> slangasek, from earlier on #ubuntu-desktop
<seb128> <jibel> pitti, seb128 I found at least 2 problems: libffi has been copied before britney received all the results of packages depending on it 2. Some results are marked as PASS while the result file contains a FAIL.
<seb128> slangasek, you might still want to hear from jibel for specifics/bug reports ;-)
 * slangasek nods
<seb128> slangasek, btw how did that libffi landed during a freeze without a ffe?
<slangasek> seb128: because according to doko, it was a bugfix-only release
<seb128> hum, k ... the ChangeLog seemed a bit non-bugfix-only to me, but I guess it's at the appreciate of whoever reviewed it in unapproved
<slangasek> seb128: right, AIUI the features were already in distro patches
<seb128> k
 * slangasek wonders why that discussion was on-topic for #ubuntu-desktop, two QA team members discussing a package that the foundations team maintains ;p
<stgraber> slangasek: any chance I can get you to look at bug 1297363? seems like everyone else is scared of it or something :)
<ubot2> Launchpad bug 1297363 in systemd (Ubuntu) "[FFe] Add cgmanager support" [Undecided,New] https://launchpad.net/bugs/1297363
<slangasek> jibel: would be interested to know if you've found anything out about these britney bugs - or do you need us (e.g. cjwatson) to pick that up?
<slangasek> stgraber: ohh.... ok
<seb128> slangasek, it's started by a "why is update-manager not starting" question from me to pitti
<slangasek> :)
<seb128> but yeah, we should have changed channel then (though the issue was already discussed/handled by pitti before I started my day, it was mostly me catching up then)
<doko> seb128, it has the new ports integrated, include aarch64 and ppc64
<seb128> doko, well, that's fine, I was just surprised to see no bug reference/ffe ... and to see update-manager not starting anymore (= no way for normal users to get the bugfix version)
<seb128> on that note, time for some exercice, bbl
<slangasek> stgraber: systemd ffe approved; I also have a change to push for bug #1295521, can I rely on you to pick it up from lp:ubuntu/systemd when you upload?
<ubot2> Launchpad bug 1295521 in systemd (Ubuntu) "Installing i386 and amd64 PAM stacks causes shutdown/logout/etc. to break" [Undecided,Incomplete] https://launchpad.net/bugs/1295521
<stgraber> slangasek: yep
<slangasek> stgraber: ok, pushed my changes there
<bdmurray> slangasek: I think arges is ready to join the ubuntu-sru team.
<slangasek> infinity, cjwatson: ^^ do we want to give him a final exam before adding him? :)
<cjwatson> slangasek: I'm happy to go with Brian's judgement
<zequence> doko: Thanks. I'll look into it (I'm the Ubuntu Studio project lead)
<slangasek> infinity: cjwatson and I are both happy with adding him on, so if you want to put him through the wringer you'll have to do it live ;)
<arges> slangasek: i'm not in any hurry so i'm happy to answer questions whenever its convenient for everybody or even via email
<slangasek> arges: too late, welcome to the SRU team!  Can we give you a day in the rotation? :)
<arges> slangasek:  : ) Sure thing!
<slangasek> let's see, which of us is doing the worst job of keeping up with their SRU day
<slangasek> it might be me
<slangasek> cjwatson: how are Wednesdays going, SRU-wise?
<seb128> nice to see some new SRU manpower, LTS coming, which means piles of SRUs to handle ;-)
<slangasek> quite
<seb128> I'm still wanting to help if you guys are still interested btw (sorry, I said I would "candidate" some months ago but holidays have been in between and I dropped the ball on that)
<arges> slangasek: so i'm cool with any day to help out. Let me know what day works best.
<slangasek> ack
<zul> cjohnston:  ping https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1299055
<ubot2> Launchpad bug 1299055 in openstack-trove (Ubuntu Trusty) "Icehouse tracker for rc1" [Undecided,New]
<cjohnston> zul: I'm guessing you mean cjwatson
<zul> yes sorry
<zul> cjwatson: ping https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1299055
<ubot2> Launchpad bug 1299055 in openstack-trove (Ubuntu Trusty) "Icehouse tracker for rc1" [Undecided,New]
<infinity> slangasek: Fine by me, I trust he was thoroughly trained and abused.
<slangasek> ack
<mlankhorst> choo choo
<cjwatson> zul: I'm EOW now, sorry
<cjwatson> slangasek: *cough* not been happening a whole lot, just now and again :-/
<slangasek> cjwatson: oh no, this is horrible!  That means I have competition for the title of "least responsible SRU team member", and I can't just give arges my day!
<cjwatson> I was assuming you'd just exercise your management privileges and instruct me to pull my finger out
<slangasek> o right
<slangasek> cjwatson: plz stop slacking
<cjwatson> yers marster
<cjwatson> the verification queues are pleasingly non-terrible at the moment
<cjwatson> good work by people clawing those down
<cjwatson> anyone want to confirm that they don't think anything in http://www.openssh.com/txt/release-6.6 really looks like it needs an FFe?
<cjwatson> (er, yes, I actually am kind of EOW, this is really Debian work)
 * cjwatson goes off to supervise children's bathtime
<infinity> cjwatson: It looks fine, though I'm having a hard time parsing what the second bullet point in the feature/changes section actually means.
<zul> slangasek:  ping https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1299055
<ubot2> Launchpad bug 1299055 in openstack-trove (Ubuntu Trusty) "Icehouse tracker for rc1" [Undecided,New]
<slangasek> zul: what's the question?
<zul> slangasek: can i get an ack for the icehouse rc1 from the release team?
<slangasek> ok, so this is an FFe request?
<zul> yes
<slangasek> zul: your bug description is far too high-level to be useful input to an FFe review.  Do you have pointers to debdiffs, or can you please include information about the features inline in the bug description?
<slangasek> zul: also, what kind of analysis have you done so far of the risks of updating?
<zul> slangasek: no I dont have debdiffs since some of them are still blocked, we have done the testing in the openstack-ci as usual we are ok with the updates
<slangasek> blocked on what?
<zul> slangasek:  blocked on a database fix getting upstream which will be fixed in the rc1 when its out
<slangasek> and if some things are blocked, does that mean they also aren't tested yet?
<zul> slangasek:  we do per-commit testing in the openstack-ci lab like we did in saucy
<zul> gaughen: ^^^
 * gaughen reads
<slangasek> zul: ok, so I suppose I could give a standing FFe for icehouse, provided that the packages continue to be tested via openstack-ci before upload
<slangasek> but it certainly doesn't make sense for me to FFe approve rc1 by itself, before it's out
<zul> slangasek:  cool thanks
<zul> they always have been
<slangasek> infinity: fyi, upgrading to trusty claims that trusty is still in alpha.  Something missed from the checklist?
<infinity> slangasek: What claims that?
<slangasek> infinity: the release notes displayed in update-manager
<slangasek> bdmurray: you probably know where to change this, right?  Somehow I don't see it listed on https://wiki.ubuntu.com/BetaProcess
<infinity> Yeah, this might be some special IS-mirrors static copy of the release notes...
<infinity> I thought alphas and betas were meant to just grab the wiki version directly.
<infinity> (Or, rather, the static copy isn't meant to exist, but to just be a redirect)
<slangasek> infinity: I think it's a static HTML file that we push in the archive tree, or onto changelogs.ubuntu.com
<infinity> Oh, http://archive.ubuntu.com/ubuntu/dists/trusty/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html
<slangasek> http://changelogs.ubuntu.com/meta-release-development -> yah that
<infinity> So, I guess that needs a dist-upgrader upload to fix.
 * infinity could have sworn there was something somewhere that reads the REAL release notes, not just the stub.
<infinity> Maybe that's ubiquity that does that.
<slangasek> yes
<infinity> slangasek: http://paste.ubuntu.com/7171001/
<infinity> slangasek: Seem reasonable?
<infinity> It might make more sense to just rewrite that to be a generic "this is a development release" warning, so it doesn't need to be changed ever again, actually.
<knome> highly approve that direction :)
<infinity> Something like this http://paste.ubuntu.com/7171009/
<infinity> slangasek: ^
<infinity> Feels verbally redundant.  s/release/product/ maybe.
<infinity> WHY AM I PUTTING THIS MUCH THOUGHT INTO THIS?
<infinity> Someone give me an opinion that isn't my own, and I'll upload. :P
<slangasek> why can't I just give you your own opinion?
<slangasek> that sounds easier
<slangasek> also, why can't you just cargo-cult from whatever was there last cycle? :)
<slangasek> oh, because you're eliminating alphabeta
<slangasek> infinity: s/pre-release //
<infinity> slangasek: Y'think?  I didn't like the implication that we stop development after release (which we don't).
<infinity> slangasek: Which is proof that I'm overthinking this string modification.
<slangasek> post-release isn't development, it's perfection
<slangasek> or something
 * infinity snorts.
<infinity> slangasek: Upload in the queue.
 * infinity goes to commit to bzr to see if he just stomped over staged changes.
<infinity> La la la.
<slangasek> at least you got to it before I had to check ;)
<infinity> Looks like I win.
<bdmurray> all sorted then?
<slangasek> aside from the queue not giving me a debdiff and making me review manually, yeah
<bdmurray> I never thought I'd be excited for the kids to drive themselves but this is getting out of hand.
<slangasek> bdmurray: they've got four feet between them
<bdmurray> slangasek: I guess I walked back in the day, and I know they have experiencing walking / hiking.
<bdmurray> Could somebody have a look at kerneloops for me?
<slangasek> will do
<bdmurray> thanks
<slangasek> accepted
<slangasek> bdmurray: is that going to suffice to get the data up somewhere we can get at it? Nothing's going to be marking bugs as dupes of the existing ones before the users have a chance to submit the data, is it?
<bdmurray> slangasek: the retracer is marking them as duplicates after they are submitted to LP so we should be good.
<slangasek> ok
#ubuntu-release 2014-03-29
<jibel> slangasek, I found a problem when several packages are uploaded at the same time and trigger a test of the same package (eg. gobject-introspection depends on glib2.0 and libffi) only the first dep on the list is considered and others are ignored
<jibel> slangasek, I'll add new tests and provide a fix
<infinity> jibel: Eek.
<infinity> rsalveti: Why is that i386 touch subarch "generic_x86" instead of just "generic", aligning with the kernel flavour?
<ogra_> infinity, thats the android device name ... generic is the armhf device name
<ogra_> (yay for consistency)
<infinity> ogra_: Err.  Lolwut?
<ogra_> it was renamed from goldfish to generic
<infinity> ogra_: Kay.  I assumed it related to kernel names, since it does for the armhf ones (flo, manta, etc).
<infinity> ogra_: Oh.  Okay, so shouldn't it be goldfish from our POV?
<ogra_> yeah, i'm curious how ricardo will solve that :)
<ogra_> it was goldfish until android 4.2.2 ... with kitkat it was renamed to generic
<ogra_> we use 4.4 ... so we use the device names it uses
<infinity> Well, but it's still "golfish" as far as our kernels.
<infinity> Since in our world, generic means something entirely different.
<ogra_> yeah
<infinity> But okay, if this livecdrootfs stuff is about Android platform names, and has nothing to do with kernel flavours, I guess the patch is "right".
<infinity> Just confusing as all hell.
<ogra_> thats why i say i', curious how rsalveti will solve it ... patching the name in the android tree would be quite a patch i think
<ogra_> (to rename it back to goldfish)
<ogra_> yeah, touch is full of confusion ...
<ogra_> the ubuntu rootfs lives in a system.img ... in which you have an android system.img ...
<ogra_> (and now explain to a porter that he has to replace his system.img :P )
<ogra_> naming things isnt our strenght in touch
<infinity> ogra_: I've been mostly ignorant of all of this for a long time, I can't decide if I should learn how it's all put together (thus perhaps leading to anger and/or sadness), or just keep ignoring it.
<ogra_> well, i expect the image design to take over on the desktop too over the next releases
<infinity> ogra_: Yeah, so, there's going to be a long and angry conversation about that.
<ogra_> (probably less insane ... with proper readonly partitions etc)
<infinity> With the current state of affairs, the response to "we should use system images in the distro" would be "over my dead body", so we'll need to do a lot of discussion to see if it's viable and, if so, how.
<ogra_> i dont think it is wrong to have a fixed core ... but getting dpkg into play here will be a hell lot of work
<infinity> ogra_: Conceptually, a readonly core is fine but, yes, making dpkg happy with that is not an easy problem to solve.
<infinity> And "everything that's not core can be click!" is not an answer, as click was intentionally designed to be limited in scope and just plain can't do some of the things we want in more complex packages.
<ogra_> well
<ogra_> everything thats UI should be click is my opinion
<ogra_> at least over the years
<infinity> Define "UI".
<infinity> You mean "apps"?
<infinity> Or you mean kubuntu should distribute KDE as click packages? :P
<ogra_> also libreoffice
<ogra_> or chromium
<ogra_> no
<ogra_> i mean that desktop and touch apps should be click ... everything that you can install on a desktop ... click integration needs to be seamless enough that kubuntu *can* use it if they like
<infinity> I don't think we should stand in the way of people who want to make things clicky.  But we also shouldn't fetishize it and fork Debian packages into click packages Just Cause.
<ogra_> well, i think we should encourage click to UI app people
<infinity> And if we come up with a solution that makes dpkg happy on a readonly system-image, we don't NEED to make those decisions, or needlessly fork.
<infinity> Cause people with root and no need for containment can then run debs on phones, and people can run clicks on desktops, and everyone wins.
<ogra_> you wont have dpkg on a (converged) phone
<infinity> ogra_: See, no, that's wrong.  Flat-out wrong.
<ogra_> i think even in desktop mode you want the phone to oly run converged apps
<infinity> Convergence implies that the phone and desktop will become one platform.
<ogra_> simply for security reasons
<infinity> If my desktop can't install debs, it's useless.
<infinity> Period.
<infinity> Note that I did say "if you have root".  I expect the average phone user to never exercise ring0.
<ogra_> i'm not sure i agree here, you would ship quite a giatn security hole unless you strictly cage both systems ...
<infinity> But the facility should be there for it to act just like my development desktop.
<infinity> ogra_: You're implying that my entire laptop is a gaping security hole. :P
<ogra_> oh, sure, there should be a developer mode
<ogra_> in which you can probably drop the gurads ...
<infinity> ogra_: Right, but "developet mode" can't just be "make it read-write and disable system images", or the previous 100 lines of conversation was meaningless.
<ogra_> we do that today (apart from the odd hardlink issues dpkg has)
<infinity> (Which is what developer mode is currently)
<ogra_> but in a deffault phone even with converged desktop mode, i wouldnt expect debs
<infinity> ogra_: Well, in a converged product aimed at appliance consumers, I don't expect anyone to ever need root, no.
<ogra_> and the majority of users wont need the dev mode (hopefully)
<infinity> ogra_: But this system also needs to be usable by me.
<ogra_> indeed
<infinity> ogra_: And by all the people who run Ubuntu as a useful dev platform, not an appliance.
<ogra_> but people like you and me hopefully only make up a really really minor portion of users
<infinity> One of the most exciting things about this, really, is that if we do it right, the phone is self-hosting.
<infinity> Which no other Mobile OS platform has been.
<infinity> (Maemo should have been, but lolscratchbox)
<ogra_> if we are more than 0.001 per mille we have failed in the phone business :)
<ogra_> (we developers)
<infinity> Sure, we should be a minority.  I still want to do it right for everyone. :P
<ogra_> indeed
<infinity> And a self-hosting platform is also a big step in "doing it right", for me.
<ogra_> as long as ubuntu gets developed on ubuntu i expect such modes to exist
<ogra_> scratching our own itches still ...
<infinity> I was amazingly disappointed when I did Maemo stuff for Nokia to discover that a platform that was essentially Debian couldn't actually build its own binaries.
 * ogra_ glares at his desktop
<ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ ps ax|grep qemu
<ogra_> 11106 ?        Ssl    0:00 /usr/bin/qemu-arm-static /usr/sbin/rsyslogd
<ogra_> 11181 ?        Ss     0:08 /usr/bin/qemu-arm-static /usr/sbin/cron
<ogra_> now how got this there
<ogra_> they both even respawn
<infinity> Lack of policy-rc.d in that chroot?
<ogra_> yeah, could be
<infinity> cat trusty-amd64/usr/sbin/policy-rc.d
<infinity> #!/bin/sh
<infinity> while true; do
<infinity>     case "$1" in
<infinity>       -*) shift ;;
<infinity>       makedev) exit 0;;
<infinity>       x11-common) exit 0;;
<infinity>       *) exit 101;;
<infinity>     esac
<infinity> done
<infinity> Enjoy.
<ogra_> right, that implies i dont forget about ti next time i roll a chroot in a hurry :)
<ogra_> debootstrap should have a switch to put that in place
<ogra_> lol
<infinity> ogra_: debootstrap --include=policyrcd-script-zg2 might give you what you want.
<ogra_> so when issuing "sudo reboot" in the terminal app on the phone the keyboard autocorrection prints my password (in the terminal) when typing
<infinity> Except that's in universe, so you also need to add universe. :/
<infinity> Oh, wait.  No.  It's in main now.
<infinity> \o/
<ogra_> :)
<infinity> Not sure why it's in main...
<infinity> Can't find it seeded, nor any rdeps.
<ogra_> interesting
<infinity> Oh, it's in platform, I was looking at Ubuntu.
<infinity> ... and it's been seeded since 2009, I might live slightly in the past.
<ogra_> haha
<ogra_> upgrade these gutsy installs
<doko> jibel: a lot of autopkg tests are marked as running for some time now ...
<doko> infinity, you did trade in the lintian ftbfs to a dep-wait ...
<infinity> doko: Hrm?  See the upload in the queue.
<rsalveti> infinity: ogra_: it's a lot of work to rename it to generic
<rsalveti> the android build system doesn't support a device with the same name but different arch
<ogra_> heh, yeah
<ogra_> and I guess the other way round its not less work
<rsalveti> and for the kernel is indeed confusing, but the upstream name is indeed just goldfish
<rsalveti> so the android generic build runs with the goldfish kernel
<rsalveti> would love to get this a bit more sane though, maybe next cycle
<infinity> rsalveti: Wait, I'm confused.  "the upstream name is indeed just goldfish".  Isn't that what we want it to be?
<infinity> rsalveti: I was complaining that having something called "generic" that has no relation to our "generic" kernel is confusing. :)
<ogra_> infinity, the upstream kernel name
<infinity> Who accepted that account-plugins upload without a changelog entry? :/
<slangasek> how can an upload have no changelog entry?
<slangasek> wow
<slangasek> ok then
<slangasek> and account-plugins isn't whitelisted?
<slangasek> infinity: oh, but it's a sync, so good luck reviewing it ANYWAY
<infinity> slangasek: I review syncs...
<slangasek> infinity: and good luck to you!
<infinity> I obviously didn't do that one. :P
<slangasek> infinity: how do you review them?  Last I knew, you couldn't fetch sources or diffs from the queue
<infinity> slangasek: One somewhat nice thing about the silos is that if you follow the queue link to the origin PPA, it's usually only got a couple of packages in it, unlike the old upstream merged that had hundreds, so it's not too hard, UI-wise, to get to the diff.
<slangasek> ok
<infinity> (And I think queuediff also tries to follow it back somehow, but I tend to just use the web UI for this)
<slangasek> right, good to know you can get there via the web ui; that's better than nothing
<slangasek> (though having to shell out to a browser (er...) to trace it is still annoying)
<infinity> It's seven kinds of not ideal, we're well aware.
<infinity> Hey, lazyIRC, is there a HOWTO on the wiki somewhere for doing autopkgtests at home?
<infinity> Possibly ECHAN...
<Laney> slangasek: infinity: queue fetch can fetch sync sources
<Laney> it definitely works for CI train syncs
<slangasek> also good to know
<slangasek> does that mean 'queuediff' works now?
<Laney> Nein
<slangasek> ok
<Laney> I wrote a shell alias that does that or fetch / pull-lp-source && debdiff as appropriate
<slangasek> infinity: 'doing autopkgtests at home' == 'adt-run /path/to/package.dsc --- adt-virt-schroot trusty-amd64'
<slangasek> Laney: fie, instead of submitting a fix to queuediff? :)
<Laney> Orders of magnitude quicker :P
<Laney> Last I looked queuediff was a screen scraper
<slangasek> yeah
<Laney> You could bolt some shelling out onto it though, I guess
<rsalveti> infinity: yeah, sorry, by upstream name I mean the upstream name for the kernel
<infinity> slangasek: Do you know anything about this efitools in the queue?
<cjwatson> account-plugins might have been me, I complained about the lack of changelog for one such package on #ubuntu-ci-eng but I decided I was OK with the rest of the diff and it wasn't worth redoing it
<cjwatson> slangasek: "queue fetch" works on syns
<cjwatson> *syncs
<cjwatson> oh Laney said that
 * slangasek nods
<slangasek> infinity: efitools> um no
<cjwatson> (I use queue fetch --source to stop it fetching the binaries too)
<infinity> slangasek: Given your love of EFI and SB, care to look at the FFe and evaluate the assertion that we need this package before I go trying to review the package itself?
<slangasek> infinity: I'm familiar with the tools in question, and even have a copy checked out locally, but there were no explicit plans to use these in Ubuntu; would like to know what jpds's larger plans are here...
<slangasek> I mean, I don't really see any reason not to include them as a package in Ubuntu, but the claim in the FFe bug that they "will be needed for enterprise platforms" is eyebrow-raising
<infinity> slangasek: Right, inclusion or not is entirely up to it passing an AA review and, really, if it's going to be a leaf package in universe, it doesn't need an FFe.
<infinity> slangasek: But the wording of said FFe seems to imply it might want to be in main for some reason or other that I can't fathom and thought you might know (but apparently don't).
<slangasek> infinity: it should not be in main
<slangasek> if jpds thinks otherwise, he should discuss with the foundations team :)
<ScottK> infinity: Generally we have been asking for an FFe for new packages, but I almost always approve conditional on finding a willing AS.
<ScottK> AS/AA
<infinity> ScottK: I suspect I view feature freeze a bit differently, in the sense that if nothing depends on a new leaf package, and it's not in a supported seed, it's not really a new feature from the POV of people installing/upgrading and getting a new behaviour.
<infinity> (I certainly don't ask for FFes for people syncing new shiny from Debian)
<infinity> ScottK: Seems to be a fair tradeoff for me being a perfectionist control freak about packages that *are* seeded. :P
<ScottK> When MOTU was a separate team we insisted on people at least asking because there were people who screwed stuff up otherwise.
<infinity> ScottK: (Please do apologise to your new contributor about my anal-retentive reject of calligra, though they did reupload a fixed version, so yay)
<ScottK> k.
<infinity> The number of things I reject for during hard freezes really makes me wish we had the human bandwidth to do queue reviews all cycle. :/
<knome> mmyes
<ScottK> :'(
<infinity> Huh, look at that.  I was planning to blame Intel for the ppc64el acpcia-unix FTBFS, but it's totally the fault of the packaging.
<infinity> ^-- Someone want to review that and let it in?
<cjwatson> haha, done
#ubuntu-release 2014-03-30
<infinity> There.  Mosh works on ppc64el.  Port done.  Nothing else matters.
<teward> has an official date been decided for the quantal EOL yet?
<stgraber> arkose has been badly broken for about a year due to LXC changes, changes to su, kernel changes and the introduction of userns
<stgraber> I won't have time to fix it this cycle, so I plan on getting it out of 14.04 entirely
<infinity> :(
<infinity> Poor arkose.
<stgraber> the upload above does just that for Edubuntu (only seeder of those packages), I'm also going to push a matching installer slideshow update and then file and archive removal bug
<stgraber> all the features I ever needed for arkose now exist but it needs pretty much a full rewrite to use them and that won't happen by release
<stgraber> I still hope for a 2.x release which will use userns and unprivileged overlayfs to provide the exact same features but without requiring any privileges
<infinity> stgraber: Maybe you can rewrite it in a language that doesn't suck next time. ;)
 * infinity blinks at ubiquity-slideshow-ubuntu being in the kubuntu packageset.
<stgraber> infinity: well, I don't feel like doing it in C, so my other options for the LXC binding is Go, Lua, Ruby or Python3. I think I'd stick to Python3 :)
<infinity> stgraber: No perl?
<infinity> (But yeah, C was what I was suggesting)
<stgraber> infinity: bug 1299904 (I probably shouldn't be processing that one myself)
<ubot2> Launchpad bug 1299904 in arkose (Ubuntu) "Please remove arkose from the archive for 14.04" [Undecided,New] https://launchpad.net/bugs/1299904
<infinity> Seems weird to sandbox potentially tiny/fast C applications by running a massive python interpreter.
<stgraber> I suspect 90% of arkose's code could now go away as it's since been re-implemented in liblxc itself so maybe doing it in C wouldn't be as horrific as it'd have been for the initial implementation :)
<infinity> shell would work too, I suppose, if there were enough CLI utilities to make that work.
<stgraber> the GUI and nautilus integrations would probably remain python, because those are definitely a pain to do in C :)
<stgraber> yeah, shell would be an option, I "think" I could actually do that with the current LXC tools, definitely a fun thing to try if it wasn't for ENOTIME...
<infinity> PS: Thanks for hiding your slideshow change in the middle of a translation update.
<stgraber> infinity: sorry :(
<infinity> Oh, hah, you just commented out the slide.  Kay.
<stgraber> yep, that's the usual way. Removing it would also remove the translations which may one day be useful again.
<infinity> stgraber: Yeah, seems sensible to me.
#ubuntu-release 2015-03-23
<ogra_> infinity, did you disable the system-image import job on nusakan in your hunt for the arm64 snappy issue ?
 * ogra_ tries to find out why it was disabled 
<infinity> ogra_: I don't know anything about any part of that sentence.
<ogra_> lol, ok
<ogra_> then i guess it was slangasek
<infinity> ogra_: Unless by "the arm64 snappy issue", you mean the firewall issue.
<infinity> ogra_: But I was just hunting firewalls, slangasek might have dropped the crontab bits.
<ogra_> yeah, your conversation in the backlog starts with slangasek trying to enable arm64 builds
<ogra_> i could imagine he switched off the importer for that ... then ran into the keyserver issue and forgot to switch it back on ...
<infinity> Possibly.
<infinity> He's on VAC this week, but if you yell loud enough, he might hear you.
<ogra_> would really be nice to announce it here if he switches it off ..
<ogra_> (we have some unwritten rule that we do this among all others that are able to disable it :) )
<ogra_> aha, seems my manual run just finished
<infinity> ogra_: I tend to announce when I'm disabling things.  Usually.  But that could mean either that he didn't announce or that he didn't turn it off. :P
<ogra_> right
 * ogra_ switched the importer back on now ... seems to have run fine
<doko> infinity, can you overwrite/disable the taskcoach autopkg test?
<infinity> doko: It did actually regress on Oct 26, would be nice to figure out what's up with that.
<doko> infinity, tell that the debian maintainer, they disabled the autopkg test now
<doko> just kept it for the last upload to see how it behaves in vivid
<infinity> doko: Diffing the logs, it looks like the difference is that the successful one pulls in wx*2.8, and the failed one pulls in wx*3.0
<infinity> doko: Half done transition, I guess?
<doko> infinity, no, I tried reverting back to 2.8, didn't work either
<infinity> doko: No, I mean the test deps pull in 3.0
<infinity> doko: When the deps pulled in 2.8, it worked fine.
<infinity> doko: So, maybe taskcoach needs to move to 3.0, now that other bits seem to have moved on.
<doko> infinity, please don't speculate. if you are interested, please have a look at the sources
<infinity> doko: Oh, I missed that you merged a new version a few days ago that uses 3.0.  Hrm.
<infinity> doko: My speculation made more sense without that context.
<doko> infinity, https://jenkins.qa.ubuntu.com/job/vivid-adt-zodb/ another one, always failing
<doko> jibel, ^^^
<flexiondotorg> I'd like to help an FFe get through. Who here can I discuss it with?
<infinity> flexiondotorg: Which FFe?
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1434412
<ubot93> Launchpad bug 1434412 in Folder Color "[FFe] Upload of Folder Color, Scalable folder should not be included." [High,New]
<flexiondotorg> Marcos has already got Folder Color in the 15.04 archive. Folder Color debuted in the 15.04 archive.
<flexiondotorg> Ubuntu MATE is including it.
<infinity> flexiondotorg: Does this affect anyone other than MATE?
<flexiondotorg> Marcos has discovered he needed to change Folder Color to interact with icon themes correctly.
<flexiondotorg> infinity, Nope. Not yet.
<infinity> flexiondotorg: Then go for it.  Quickly.  Beta on Thursday. :P
<flexiondotorg> infinity, How should I proceed?
<flexiondotorg> Does someone need to approve the FFe?
<infinity> flexiondotorg: I just did.
<flexiondotorg> infinity, OK. Now what? Debdiff?
<infinity> flexiondotorg: Uploads, ideally.
<flexiondotorg> infinity, So I can ask the MOTU to do that?
<infinity> flexiondotorg: *nod*
<doko> tumbleweed, do you still track the python-cffi FFe?
<flexiondotorg> infinity, Perfect. Thanks very much.
<jamespage> please can the oslo-log uploaded to vivid NEW last month be rejected; I have a more Debian future-friendly version to replace it with.
<infinity> jamespage: Done.
<jamespage> infinity, thankyou
<jamespage> zul, ^^
<jamespage> uploading the revised one now
<zul> jamespage:  ack
<jamespage> that sync is under bug 1434526
<ubot93> bug 1434526 in Ubuntu "[FFe] new packages to support OpenStack Kilo-3 milestone" [High,Triaged] https://launchpad.net/bugs/1434526
<jamespage> I also need a willing AA to deal with another oslo package required for OpenStack kilo-3 (oslo-policy)
<jamespage> another refactoring into a shared common library
<jamespage> (condition of the release team ack)
<flexiondotorg> infinity, ubiquity-slideshow-ubuntu recently merge some Ubuntu MATE changes. Changes I really need to test in the next Beta.
<flexiondotorg> infinity, Please can you direct me towards someone who could build a new ubiquity-slideshow-ubuntu package?
<infinity> flexiondotorg: I'd ask cyphermox nicely, if I were you.
<flexiondotorg> infinity, Thanks.
<cyphermox> let me get this done nao
<flexiondotorg> cyphermox, Thank you very much! :)
<doko> hrm, what keeps gcc-4.8 in main?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.vivid/rdepends/ALL/gcc-4.8 -> gcj-4.8-jdk in supported-development-common seed, gcj-4.8-source in development seed
<cjwatson> I see libstdc++-4.8-pic in the former and gcc-4.8-source in the latter too
<doko> argh ...
<doko> ok, didn't think about the seeds
<doko> infinity, please can we get python-defaults into the release pocket?
<infinity> doko: Yes.
<Mirv> could the mesa 10.1.3-0ubuntu0.4 be released to trusty, it keeps on hitting people trying to install SDK on Ubuntu 14.04.2?
<Mirv> the mlankhorst's proposed upload is now 11 days old
<infinity> Mirv: Looking.
<infinity> Mirv: Done.
<Mirv> thank you!
<Mirv> bzoltan_: ^ the SDK installability issue on 14.04.2 being resolved now(ish)
<flexiondotorg> cyphermox, I see version 94. Thank you.
<mlankhorst> goodie :)
<rbasak> infinity: mysql-5.6 is pretty broken right now. I'll be uploading a fix shortly. "I will be freezing the archive later today" means that's OK, right?
<infinity> rbasak: Yeahp.
<infinity> rbasak: As the email noted, I intend to sleep before I freeze anything.
<rbasak> Thanks
<slangasek> ogra_: sorry - yes, I had disabled the cronjob because I was starting to clean up some of the phone channels, then I was down all weekend with a fever so didn't get it reenabled
<ogra_> slangasek, can you try to remember to leave a note in the channel ?
<slangasek> I can try
<slangasek> :)
<rsalveti> slangasek: or at least in the cron job :-)
<rsalveti> hope you're feeling better today
<sil2100> slangasek: hey! Shouldn't you be away resting btw.? ;)
<balloons> infinity, when can we see a milestone for final beta?
<infinity> balloons: When I do the builds $later.
<infinity> Though, if someone wants to create the empty milestone now, I won't mind.
<infinity> stgraber: ^ :)
<infinity> stgraber: (One of these days, you need to show me if there's some QnD way to do that and I'm bugging you for no good reason)
<stgraber> infinity: it's about 5 click in a web UI :)
<infinity> stgraber: Today isn't that day, cause I need sleep between now and spinning images.
<infinity> stgraber: FIVE?!
<infinity> stgraber: Yeah, screw that.  Too many clicks.
<stgraber> well, not exactly the most user friendly web UI :)
<balloons> infinity, lol.. Just wondering on timing so I can tell folks to attack some images :-)
<stgraber> infinity: did you turn off cron already? otherwise all daily builds will show up in the milestone
<infinity> stgraber: It's pretty hostile, but at least it's not Jenkins?
<infinity> stgraber: I didn't.  I will. :P
<stgraber> oh yeah, it's beautiful and user friendly compared to Jenkins
<infinity> stgraber: Alright, cron disabled.
<stgraber> milestone ready
<infinity> balloons: Images will be many hours out still, I'm waiting on a new kernel, need to force some things to migrate, do a d-i upload, and I need a nap before all that happens.
<infinity> balloons: If there are people bored and wanting to test things, bugs reported against the last daily would still be worth knowing about.  Nothing particularly magical about the next image.
<balloons> infinity, yes tis true. thanks for the heads up
<slangasek> anyone else seeing debconf failures under update-manager in vivid?
<slangasek> nothing that uses debconf in postinst is configuring successfully for me
<slangasek> (and this is a recent regression, no more than a week or two since the last successful update)
<slangasek> last successful update on 2015-03-18, which brought in a qt update and probably nothing that talked to debconf.  first failing update on 2015-03-20, which pulled in a lot of new packages, including glib2.0 which but nothing that would obviously account for debconf breakage
#ubuntu-release 2015-03-24
<slangasek> the perl upgrade was on Mar 4... seems unlikely to have no packages with debconf questions from the 4th until the 20th, though I guess it's possible
<doko>  o console-setup-freebsd-charmaps-udeb console-setup-freebsd-fonts-udeb console-setup-linux-charmaps-udeb console-setup-linux-fonts-udeb console-setup-pc-ekbd{console-setup}
<doko> cjwatson, is there anything needed in main?
<doko> ohh, I see python3-launchpadlib. should we keep that in main?
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Alpha 2 | Archive: Beta Freeze | Vivid 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> doko_: console-setup-linux-charmaps-udeb console-setup-linux-fonts-udeb console-setup-pc-ekbd belong in main, the freebsd ones are irrelevant
<infinity> slangasek: I have a couple of bug reports about that debconf failure, but hadn't yet seen it locally or managed to reproduce.  If it only happens under update-manager, that's a hint (though, an annoying hint...)
<smb> Not sure this isn't a wrong assumption on my part, but I just noticed that on the 14.04.2 amd64 server iso pool/main/l/linux looks like this: http://paste.ubuntu.com/10667920/ Since the installer kernel is a 3.16, should there be not 3.16 udebs? Also the md and multipath modules seem to be over-eagerly supplied...
<mparillo> stgraber: I am noticing some obsolete test cases for Kubuntu. https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1425193 Riddell sent me your way. Would I be able to remove the obsolete Kubuntu test cases and edit them? You can find me on Launchpad at marco-parillo (first e-mail), if I am not on-line here.
<ubot93> Launchpad bug 1425193 in Ubuntu Manual Tests "Plasma-netbook is not ported to Plasma 5" [Undecided,New]
<elfy> mparillo: re manual testcase, probably better to just create new testcases
<elfy> as far as removing them - anyone in kubuntu release team should have perms to remove old testcase from the list
<elfy> not sure who's about interested in beta2 images but bug 1435714
<ubot93> bug 1435714 in ubiquity (Ubuntu) "Keyboard layout missing during install setup" [Undecided,Confirmed] https://launchpad.net/bugs/1435714
<elfy> I assume that'll affect everyone - it certainly affects Xubuntu, Ubuntu and Mate
<flexiondotorg> http://launchpad.net/bugs/1432285
<Odd_Bloke> I can see cloud-init apparently being accepted in http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_output.txt; did it miss migrating before the beta freeze (or is there something else happening)?
<ubot93> Launchpad bug 1432285 in ubiquity (Ubuntu) "Vivid live DVD fails to provide means to eject disc" [Medium,Confirmed]
<cjwatson> the beta freeze should have no effect on trusty
<cjwatson> stable release migrations are always manual, though
<cjwatson> proposed-migration runs in a dry-run mode there
<cjwatson> it merely serves to provide input to http://people.canonical.com/~ubuntu-archive/pending-sru.html
<Odd_Bloke> Aha, I thought there was a page I was missing.
<Odd_Bloke> Thanks!
<Odd_Bloke> *some documentation reading later* Could I get an AA to promote cloud-init in precise, trusty and utopic?
<mparillo> Thank you elfy. Apparantly, there is no separate Kubuntu Release Team. Do you know how I can apply to join the Ubuntu release team?
<flexiondotorg> elfy, The eject issue is critical. On EFI system you'll enter and almost inescapable boot loop and the end of the install.
<flexiondotorg> elfy, <davmor2> flexiondotorg: the other nice issue is if you are on a system with UEFI there is no boot from HD option in the menu so you are stuck in a menu/boot loop where you cant remove the dvd, you can't can't eject the dvd and you can't boot to another device so you eject the dvd, bit of an issue :)
<davmor2> added it as a comment to the bug will be filing another for the menu to have a boot from hdd
<flexiondotorg> davmor2, Thanks.
<doko> slangasek, cjwatson: demoted the freebsd ones, I assume the other need seeding. but then I noticed that the other seeded console-* packages don't exist anymore
<doko> also, there are still ttf-* packages seeded, instead of fonts-*
<cjwatson> feel free to sort this out, I wasn't involved in the latest console-setup merge
<doko> ok
<cjwatson> and ttf- => fonts- has been a gradual process for ages
<infinity> So, I hear everything failed miserably overnight?
<flexiondotorg> infinity, Hi
<flexiondotorg> infinity, http://launchpad.net/bugs/1435714
<ubot93> Launchpad bug 1435714 in ubiquity (Ubuntu) "Keyboard layout missing during install setup" [Undecided,Confirmed]
<infinity> cyphermox: ^
<infinity> cyphermox: Can you hunt this down?  Might relate to the console-setup package split?
<infinity> flexiondotorg: Going to assume from the Xubuntu and MATE mentions that pretty much every one is seeing this bug?
<flexiondotorg> infinity, I know you're catching up. When you've had a coffee and what have you could you do some magic to make the PowerPC build for Ubuntu MATE appear in the Beta 2 tracker please?
<davmor2> infinity, jibel: who adds netboot?
<infinity> flexiondotorg: That might need stgraber, I'm less familiar with that part of the "UI" (and I use that term loosely).
<jibel> davmor2, I'll do
<infinity> flexiondotorg: Oh, wait.  Maybe I found it.
<jibel> and upgrade tests too
<davmor2> infinity: the scariest bug so far is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1432285
<ubot93> Launchpad bug 1432285 in ubiquity (Ubuntu) "Vivid live DVD fails to provide means to eject disc" [Medium,Confirmed]
<infinity> flexiondotorg: Okay, it's added to the manifest, won't show up until the next rebuild unless someone manually fiddles a bit.
<flexiondotorg> infinity, Thank you.
<davmor2> infinity: and of course that's all cyphermox 's fault ;)
<infinity> davmor2: He's the new kid, he gets to take blame^Wresponsibility for everything.
<flexiondotorg> infinity, If you get the time can you update the ubuntu-mate-meta package and push it into the repo?
<infinity> flexiondotorg: What did you change this time?
<flexiondotorg> infinity, Nothing.
<davmor2> infinity: I told him straight you know that means that anything to do with installs now is all your fault when he took the job ;)
<flexiondotorg> Not seeing the new version.
<infinity> flexiondotorg: Then there's nothing to upload?
<infinity> flexiondotorg: Or you missed all my nick hilights to you last night? :P
<flexiondotorg> infinity, Was waiting for the updated ubiquity-slideshow-ubuntu to hit the repos so the meta package update could "see" it.
<infinity> flexiondotorg: ship and ship-live don't affect metapackages, so nothing to rebuild.  They just affect how the /pool/ on CDs is built.
<flexiondotorg> infinity, I did :( Nothing in my bouncer.
<flexiondotorg> infinity, Ah. OK, great.
<infinity> flexiondotorg: Furthermore, I reverted your seed change, since oem-config/ubiquity has no idea how to install a non-standard slideshow.
<flexiondotorg> infinity, Sob!
<infinity> flexiondotorg: The part where no other flavour has a special slideshow might have been a hint. :)
<flexiondotorg> infinity, I just thought they were lazy ;)
<infinity> flexiondotorg: So, patches welcome, and happy to work with you on fixing that, but I figured for this week, you're better off with the generic slideshow than a broken CD. :P
<flexiondotorg> infinity, UNderstood. I'll add slideshow patches to my 15.10 work list.
<flexiondotorg> infinity, I'll update the seeds to not include any slideshow. It works fine without one.
<micahg> is there a link for the Xubuntu â«image failure that I could help with
<infinity> micahg: I think the problem was on our end, not yours.  I need to wake up enough to say that with certainty, though. :P
<cyphermox> infinity: could be; could also be related to when doko asked what packages should be in main yesterday
<micahg> infinity: ok, let me know if I can help then, thanks
<infinity> cyphermox: Well, having them in main won't magically get them installed.
<cyphermox> no
<infinity> cyphermox: So, if those packages are actually needed, maybe they should be depended on by... something.
<infinity> cyphermox: Anyhow, if you could figure out what's broken, that would be great.  It might not be the split at all, that could be a red herring, but it seems plausible.
<smb> infinity, Did you see my earlier question while looking through srollback? Or let me repeat... wondering whether I am turning mad... ok madder than usual...
<smb> Not sure this isn't a wrong assumption on my part, but I just noticed that on the 14.04.2 amd64 server iso pool/main/l/linux looks like this: http://paste.ubuntu.com/10667920/ Since the installer kernel is a 3.16, should there be not 3.16 udebs? Also the md and multipath modules seem to be over-eagerly supplied...
<cyphermox> infinity: indeed
<cyphermox> infinity: just moving this to my desktop right now
<cyphermox> "tada!"
<infinity> smb: The overeager thing is a bug I intentionally ignored due to time constraints, but the other bit seems rather wrong... Lemme look.
<infinity> smb: Oh, and indeed, just overeager in both cases.
<smb> infinity, Ok thanks. I just noticed while trying simulated multipathing and the magic runes did seem to do nothing
<infinity> smb: pool/main/l/linux-lts-utopic has the right bits.
<smb> oh duh...
<infinity> smb: It's absolutely a bug that there are 3.13 bits on the ISO, but that's really just cosmetic (and a bit of bloat), it shouldn't be causing harm.
<cyphermox> flexiondotorg: downloading the image. it seems kind of slow, so as soon as it's done I'll get on to fixing the keyboard.
<smb> infinity, ok. Yeah... got me a bit confused... hm...
<flexiondotorg> cyphermox, All flavours, including Ubuntu proper, are affected.
<flexiondotorg> cyphermox, So, If you have a recent Ubuntu image to zsync you can use that.
<cyphermox> yup, I got that
<flexiondotorg> cyphermox, k
<infinity> smb: cyphermox and an IBMer did a bunch of work on multipath in vivid, it's possible some of that needs backporting.
<cyphermox> not just possible :)
<infinity> smb: I was under the impression that multipath was working in trusty, but maybe I haven't tested it since precise, and no one else cared to. :P
<cyphermox> but that wouldn't change the packages being overeagerly included
<smb> infinity, That is quite likely... I neither did until now
<infinity> cyphermox: No, the overeager inclusion is a seed bug I was just too time-constrained to fix.
<cyphermox> ok
<cyphermox> well, if you want to quickly test multipath on trusty, etc. I can share a quick script to set things up in qemu
<smb> So with the caveat that I did something else wrong... which I would not rule out ... It seemed that adding disk-detect/multipath/enable=true did not cause the same as in did in Vivid...
<smb> cyphermox, I am just looking at that
<cyphermox> smb: http://bazaar.launchpad.net/~mathieu-tl/+junk/vm/files
<cyphermox> multipath.sh sets up qemu for amd64 with two multipath "controllers"
<smb> cyphermox, One thing which seems to be the same in V and T is that maybe we should tweak the default getuid arguments a bit to use -u (replace space by underscore)
<cyphermox> smb: I've just been discussing that, not a bad idea
<smb> cyphermox, I guess you have been exposed to the same IBM bug report about multipath. :)
<cyphermox> I probably was
<cyphermox> still working on some variant of that, actually, checking to make sure we really properly nailed the lock issue
<smb> cyphermox, I had a feeling that having udev rules causes everything to jump at the same disks ... but then with V there is also systemd and I can find none of the dear logs I am used to
<cyphermox> ok
<smb> cyphermox, so the question probably is: who whom we know, knows s**t about udev and its hiding in systemd... I guessed pi tti might be the latter and try to have a chat with him. Not sure about the former
<infinity> Bleh, looks like I'll have to do some of those rebuilds by hand to unwedge iso.qa's brain.
<cyphermox> smb: err, what for?
<elfy> infinity: generally if I see something like the keyboard setup missing I check at least Ubuntu as well as my own - just for the future
<cyphermox> smb: https://launchpad.net/ubuntu/+source/multipath-tools/0.4.9-3ubuntu11 should be fixing at least part of the problem with udev
<infinity> elfy: Yeah, that's generally sane debugging.
<infinity> elfy: And also lets you offload it on Canonical when Ubuntu is clearly broken too. :P
<cyphermox> yeah, looks like I broke ubi-console-setup by merging console-setup.
<infinity> cyphermox: \o/
<cyphermox> it's now seeing something as preseeded when it probably shouldn't
<cyphermox> at least, at a very quick glance
<smb> cyphermox, pi tti to figure out the sequence of udev events (again with systemd), someone who knows udev better to figure out a better udev rule. Well there is one ... or was until now that triggers when the block device is added
<cyphermox> smb: it might just have to go completely and be all systemd-magical.
<smb> cyphermox, maybe for vivid. It might be racing in Trusty too which has no systemd by default.
<smb> And not that I can change anything but systemd-magic sounds like bad mojo to me
<infinity> smb: Your attempt at not nick hilighting pitti on his vacation is noble, but you realise he's not on IRC, right? :)
<smb> infinity, One cannot be careful enough
<smb> :-P
<cyphermox> smb: after this multipath-tools update it looks like things are much less racy than they were, at least
<smb> He probably senses things even while not on irc
<cyphermox> hehe
<cyphermox> yeah, pitti sense tingling
<smb> cyphermox, I should look at those... they have not been there when I last looked
<cyphermox> smb: it's one change to not exclusively lock; cherry-picked from upstream, since udev also locks
<cyphermox> plus some other crap
<smb> cyphermox, ack. I try to pull the latest into my vivid vm and see whether I can get it up more reliably then
<elfy> infinity: :)
<infinity> Riddell: I'm guessing that mess of KDE packages hitting the queue is expected? :P
<infinity> Riddell: Were those for beta, or post-beta?
<davmor2> infinity, jibel: Netboot fails, No installable kernel was found in the defined APT sources :(
<infinity> davmor2: That sounds rather unlikely.
<infinity> davmor2: Which arch?
<infinity> davmor2: And which media?  kernel/initrd, mini.iso?
<davmor2> infinity: mini.iso, amd64, dvd.
<davmor2> infinity, jibel: http://people.canonical.com/~davmor2/image20150324_151921602.jpg
<infinity> davmor2: Getting there in my test, hold on. :)
<infinity> davmor2: Did you pick a non-standard mirror?
<davmor2> gb mirror
<davmor2> I love that it gives me the option to Continue without installing a kernel :D cause who needs the kernel right :D
<infinity> davmor2: "continue without kernel" and "continue without bootloader" are amazingly handy for port bringups, and for people installing to devices we don't officially support.
<infinity> davmor2: But yeah, perhaps a bit dangerous for the average end user.
<infinity> davmor2: Then again, it's a screen the average end user isn't ever mean to get to.
<davmor2> infinity: indeed
<infinity> cjwatson: live-installer has spoiled me, debootstrap from d-i is terribad now.
<infinity> cjwatson: Did you ever consider publishing the live squishyfses and using live-installer+http for non-ISO installs too?
<ianorlin> hmm do we have documentation on how to get the syslog and other nesecary stuff out when a user does reach the no installable kernel was found in the apt sources screen
<infinity> ianorlin: Hit a commandline, anna install openssh-client-udeb, and scp files off.  Not sure if we have a pretty doc anywhere that says that, though.
<infinity> ianorlin: And lifes more complicated if network setup fails too.
<infinity> life's*
<infinity> davmor2: Speaking of, do you have a syslog from that?
<infinity> davmor2: I'm expecting to tell you "I can't reproduce that" in a few minutes here, and it might just be that the mirror you used it stuck in the past, but would be nice to see the log.
<davmor2> infinity: I can drag it off for you in a moment
<infinity> davmor2: So, as expected, I can't reproduce that.  Installation completed fine (amd64/mini.iso) and rebooted.
<infinity> davmor2: I did, however, use us.archive, not gb.archive, since you told me that after I started.
<davmor2> infinity: http://people.canonical.com/~davmor2/syslog-mini
<cjwatson> infinity: Not very hard, although of course it'd be possible.
<cjwatson> Mirroring issues etc. though.
<infinity> cjwatson: Yeah, I suppose adding root filesystems for every arch to every dists mirror would be less than ideal.
<infinity> davmor2: Mar 24 15:15:16 base-installer: W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/vivid/main/binary-amd64/Packages  Hash Sum mismatch
<infinity> davmor2: You just had a mirror hiccup.  A second go should make it work, I'd guess.
<davmor2> infinity: I'll give it another go then
<infinity> This is a fun bug, though: Mar 24 15:15:07 debootstrap: /var/lib/dpkg/info/keyboard-configuration.postinst: 1: /var/lib/dpkg/info/keyboard-configuration.postinst: udpkg: not found
<infinity> cyphermox: ^
<infinity> cyphermox: More keyboard fun.
 * infinity wonders why it's looking for udpkg in the target...
<cjwatson> that code is generated in twisty ways
<davmor2> cjwatson: are they timey wimey squirmy wormy ways?
<Riddell> infinity: for beta if it's possible/sane
<cyphermox> ugh
<cyphermox> infinity: err, wait, is that failing or just writing out the error message?
<ianorlin> infinity: oh I normally use another method that lets you start a webserver from debian installer itself than wget the files it provides
<infinity> Riddell: Your call, really.  Most/all of those are only seeded to your images, so if you want to let things in and respin and retest, that's up to you.
<infinity> cyphermox: It's a no-op for Linux, looks like it's a hurd check.
<infinity> cyphermox: So, not a big deal.
<infinity> cyphermox: Just ugly.
<cyphermox> yeah, that's what I was about to say
<davmor2> infinity: yeap working now :)
<infinity> davmor2: Good deal.
<infinity> ianorlin: I prefer the scp method because getting *to* the installed system is often harder than getting *out* of it.
<infinity> ianorlin: Especially when debugging on masqueraded VMs, etc.
<infinity> Riddell: Just double-check each source with seeded-in-ubuntu before you accept them, please?  So we know for sure that you're only messing with yourself. :P
<infinity> cyphermox: Anyhow, sorry, didn't mean to distract you.  The actual keyboard problem should be top priority.
<cyphermox> infinity: no worries, I think I know what's wrong, testing the hypothesis now
<infinity> cyphermox: \o/
<davmor2> infinity, jibel, cyphermox: https://bugs.launchpad.net/ubuntu/+source/indicator-keyboard/+bug/1434091 this is still in the install and it's all cyphermox 's fault ;)
<ubot93> Launchpad bug 1434091 in indicator-keyboard (Ubuntu) "mini.iso install of ubuntu desktop selecting only ENG_UK gives me eng_us and eng_uk" [Undecided,New]
<infinity> davmor2: Probably not a high priority for the beta, unless cyphermox's other fixes magically fix it.
<davmor2> infinity: indeed :)
<cyphermox> doubtful, it would be something quite different I'd expect
<flexiondotorg> infinity, I've rebuild Ubuntu MATE. Still no PowerPC iso for Beta 2?
<flexiondotorg> stgraber, infinity Suggested you might be able to help with the above? ^^^^
<infinity> flexiondotorg: Your powerpc build never happened.
<infinity> flexiondotorg: Let's see about resolving that.
<cyphermox> ok, got a way to fix the keyboard, just not sure why it comes to that
<gaughen> infinity, Hey Adam, I have 3 FFes that need some love. I had poked slangasek but found out he's on vacation. Would you take a look or help me get them some attention? pretty, pretty please?
<gaughen> infinity, https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1430760
<ubot93> Launchpad bug 1430760 in docker.io (Ubuntu) "[FFE] Bump up docker.io version to 1.5 in Vivid" [High,Triaged]
<gaughen> infinity, https://bugs.launchpad.net/ubuntu/+bug/1424029
<ubot93> Launchpad bug 1424029 in Ubuntu "[FFE] nova-compute-lxd" [Undecided,New]
<gaughen> and finally https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1425686
<ubot93> Launchpad bug 1425686 in lxd (Ubuntu) "[Ffe] Standing feature freeze exception for the 15.04 cycle" [Undecided,New]
<infinity> gaughen: You might note the last commentor on those two lxd ones...
<gaughen> darn it! I should have refreshed first!
<gaughen> infinity, thank you Adam. I will try to read next time.
<infinity> gaughen: Where's the fun in that?  You'd be denied my sarcastic responses.
<gaughen> infinity, true and I do like high quality sarcasm
<infinity> gaughen: Anyhow, I'll try to look at the docker one sometime, but feel free to poke me harder a bit later.  In the middle of juggling a bunch of things right now.
<infinity> And trying to understand why germinate does the things it does which, I think, requires a psychologist, not a programmer.
<apw> infinity, it relies on having a very good crystal ball ...
<gaughen> infinity, I have a magic 8 ball somewhere I could loan you
<doko> gaughen, rbasak, infinity: does docker.io even build in vivid with go 1.3?
<infinity> doko: No idea!
<rbasak> doko: I don't know but I guess I'll know tomorrow probably
<doko> rbasak, good to hear, because a golang update will break several phone builds
<flexiondotorg> infinity, I'm all set to rebuild. Is powerpc for Ubuntu MATE all set or shall I hold off?
<infinity> flexiondotorg: Hold off.
<infinity> flexiondotorg: Other changes are coming anyway, unless you really need to test this one Right Now.
<flexiondotorg> infinity, Are those other changes the keyboard thing?
<flexiondotorg> infinity, I'll head home and check the back log here a bit later.
<flexiondotorg> infinity, I would like to get the OEM testing grub-pc fix today if possible.
<flexiondotorg> infinity, Thanks very much for helping. Much appreciated.
<infinity> flexiondotorg: The keyboard thing, yes.  And a systemd bug.
<flexiondotorg> infinity, Got a LP for the systemd bug? I can test that too when fix it out.
<flexiondotorg> *is out
<infinity> Erk, who did a langpack export?
<infinity> Usually, I'd blame pitti, but he's on VAC...
<cjwatson> they're more automated now
<cjwatson> so cron probably did it
<infinity> cjwatson: Oh.  Really?  No human is signing those anymore?  Fun.
<infinity> I guess I'll just reject the lot, I have no urge to try to get them in.
<cjwatson> I don't know, guessing
<slangasek> infinity: passthrough frontend is rarely used except in update-manager, I think?  were you seeing reports of problems with passthrough or with other frontends?
<infinity> slangasek: Passthrough indeed.  I didn't notice that in the log before.
<infinity> slangasek: Yeap, passthrough in both duped bugs.
<infinity> Riddell: You may have missed a couple of kde things in the langpack noise (which I've cleared out now)
 * Riddell looks
<infinity> Riddell: libzip was a sync by mdeslaur, but happens to only be on your image.
<infinity> Riddell: Given the uploader, I'm assuming security fix.
<mdeslaur> yes, only a security fix
<infinity> slangasek: Do you know if there's a null client for the Passthrough frontend or something, or if the only way to debug it is from within update-manager?
<davmor2> infinity: might be an issue on server installs, the TTY you are in has no text, no prompt and just a flashing cursor and nothing works you have to move to tty 1-6 to do anything like erm login
<infinity> Riddell: I'm leaving kubuntu respins up to you or ScottK when all the things you care about are accepted/migrated.
<infinity> ScottK: ^
<Riddell> thanks infinity
<flexiondotorg> infinity, Is the keyboard fix in yet?
<infinity> flexiondotorg: It's been uploaded, I'll respin everything except kubuntu once it's migrated and published.
<flexiondotorg> infinity, Perfect. Many thanks.
<flexiondotorg> infinity, I also saw the PowerPC image too :)
<ianorlin> when did debconf break
<slangasek> infinity: null client for passthrough> really no idea; cjwatson or mvo might have a better notion
<infinity> slangasek: Kay.  Well, I'll sort out some way to test it.
<infinity> The passthrough frontend freaking out like this hardly seems like a new issue, Google gives a bajillion hits.
<infinity> But it's curious that I seem to have seen several this week.
<gaughen> infinity, me again. if you have the time would you look at https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1430760 pretty please?
<ubot93> Launchpad bug 1430760 in docker.io (Ubuntu) "[FFE] Bump up docker.io version to 1.5 in Vivid" [High,Triaged]
<gaughen> if you are still super slammed. I shall come back tomorrow again.
<gaughen> and again
<gaughen> and again
<infinity> gaughen: Hah.
<infinity> gaughen: Commented.
<infinity> Typo and all.
<gaughen> infinity, thank you!
<cjwatson> infinity: debconf hasn't changed in any meaningful way in forever
<cjwatson> infinity: there's some stuff in debconf/doc/passthrough.txt that might help
<infinity> cjwatson: Oh, it's certainly not a debconf bug, just trying to figure out how to isolate exactly when and where this is happening to blame someone else (likely myself).
<infinity> cjwatson: Hah.  Love the "Error Handling" section.
<veebers> Hi, is it possible to get the autopilot package into the approved queue?
<cjwatson> it was already auto-approved
<cjwatson> 22:40 -queuebot:#ubuntu-release- Unapproved: autopilot (vivid-proposed/universe) [1.5.0+15.04.20150226.1-0ubuntu1 => 1.5.0+15.04.20150323-0ubuntu1] (no packageset) (sync)
<cjwatson> 22:41 -queuebot:#ubuntu-release- Unapproved: accepted autopilot [sync] (vivid-proposed) [1.5.0+15.04.20150323-0ubuntu1]
<veebers> cjwatson: oh, sorry :-P I just saw the 'Unapproved' on both those lines. I didn't take a moment to realise the impact of 'accepted'
<veebers> thanks cjwatson for clarifying
<cjwatson> that's just referring to the queue in which state changed
<infinity> cjwatson: FWIW, "socket -sl" is awesome for this.  Except for the part where I can't get the frontend to crash.  But I can drive it, at least.
#ubuntu-release 2015-03-25
<elfy> infinity: keyboard stage working, still seeing no option to remove installation media, which davmor2 appears to see as an issue bug 1432285
<ubot93> bug 1432285 in ubiquity (Ubuntu) "Vivid live DVD fails to provide means to eject disc" [Medium,Confirmed] https://launchpad.net/bugs/1432285
<flexiondotorg> Morning. Looks like the Ubuntu MATE image rebuilds have stalled.
<oSoMoN> hi all, could someone ack the webbrowser-app sync to unblock it from the unapproved queue?
<elfy> flexiondotorg: looks like 32and 64bit both failed to build - at ~7am
<flexiondotorg> elfy, How do you know this?
<elfy> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/vivid/
<flexiondotorg> Thanks.
<flexiondotorg> elfy, That is yesterday morning I think.
<elfy> oh sorry - too early to read dates properly
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/vivid/daily-live-20150324.4.log
<flexiondotorg> cjwatson, PLease take a look at ^^^^^^^^
<flexiondotorg> cjwatson, Looks like something died.
<cjwatson> flexiondotorg: it's not in any interesting way, it just got unlucky and the load on that machine was temporarily too high or something.  just retry the build when you see taht
<cjwatson> *that
<flexiondotorg> cjwatson, So, I did cancel and then request a build before I left for work.
<infinity> Except that wedged the world a bit, so retrying won't work.
<flexiondotorg> The POwerPC build has completed. The i386 and amd64 still report as building.
<ogra_> infinity, can i have the livecd-rootfs above ? touch only ...
 * infinity cancels a bunch harder.
<flexiondotorg> infinity, Thanks.
<infinity> ogra_: Yeah, I saw.  And WTF? :P
<infinity> ogra_: Why do you need to explicitly install ubuntu-system-settings-online-accounts?
<ogra_> infinity, there is an "or" dependency that gets resolved reverse ...
<ogra_> thats a desparate try to fix this
<infinity> And you can't just seed ubuntu-system-settings-online-accounts?
<jamespage> bdmurray (or another SRU team member): please could the nova SRU for trusty be accepted into proposed? waiting on that to start verification testing.
<Odd_Bloke> If an AA could take a look at promoting the cloud-inits waiting in {precise,trusty,utopic}-proposed, it would be much appreciated.
<infinity> Odd_Bloke: Done.
<Odd_Bloke> infinity: <3
<ogra_> hmpf, if you said anything ... i had a reconnect ...
<infinity> 03:47 < ogra_> infinity, there is an "or" dependency that gets resolved reverse ...
<infinity> 03:47 < ogra_> thats a desparate try to fix this
<infinity> 03:47 < infinity> And you can't just seed ubuntu-system-settings-online-accounts?
<ogra_> infinity, it is seeded
<ogra_> <ogra_> thats a desparate try to fix this
<ogra_> <ogra_> Depends: libaccount-plugin-google | ubuntu-system-settings-online-accounts
<ogra_> <ogra_> from account-plugin-google
<infinity> adam_g: Have you considered being more consistent with who you commit as? :P
<ogra_> <ogra_> we dont want the lib
<ogra_> <ogra_> if you have any better suggestion i'm all ears :)
<infinity>  Adam Gandelman <adam.gandelman@canonical.com>
<infinity>  Adam Gandelman <adamg@canonical.com>
<infinity> +Adam Gandelman <adamg@ubuntu.com>
<infinity> ogra_: Find the seed where account-plugin-google is being pulled in, add ubuntu-system-settings-online-accounts to same seed, run germinate, see what happens?
<infinity> ogra_: If the alternate dep is already satisfied, you shouldn't get both.
<infinity> jamespage: I'm not sure to what level of scrutiny bdmurray has been reviewing these openstack point release uploads, so I might leave nova to him (plus, it's 4am, and my brain is wheeee), but if you can't get him to sort it for you tomorrow, lemme know.
<jamespage> infinity, thanks
<flexiondotorg> infinity, Please can you confirm if I should request Ubuntu MATE rebuilds?
<infinity> flexiondotorg: They should be building.
<flexiondotorg> infinity, Thank you.
<infinity> flexiondotorg: Seems like "network hiccups after I rebuild the world and go to bed" is going to be a thing this week. :P
<infinity> At least, it happened two nights in a row.  Less than pleased.
 * flexiondotorg sends infinity sleep wishes
<davmor2> jibel: vivid desktop if you open nautilus does it open a new icon in the launcher rather than the main icon?
<jibel> davmor2, it does
<jamespage> if any of the release team have time I've added another NEW package requirement to https://bugs.launchpad.net/ubuntu/+bug/1434526 that needs a review
<ubot93> Launchpad bug 1434526 in Ubuntu "[FFe] new packages to support OpenStack Kilo-3 milestone" [High,New]
<jamespage> I also need an AA to review the NEW packages associated with that bug if there is anyone available that has some cycles; once those are in archive, I can upload the kilo-3 milestone release for openstack projects
<ogra_> infinity, well, both packages are in the same seed since forever ...
<infinity> ogra_: Bleh.  Well, try to find a better solution for it at some point, livecd-rootfs hacks suck.  But I'll let it in for now.
<ogra_> infinity, it is only a test anyway
<ogra_> i'm not sure it will fix it at all
<ogra_> seb128, ^^^
<seb128> ogra_, infinity, thanks
<Riddell> kubuntu respin seems to have broken, can anyone diagnose? http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/vivid/daily-live-20150325.log
<cjwatson> Riddell: there was some work being done on the LP master database server, which seems to have caused slightly-odder-than-usual failure modes for things that caught it at the wrong time
<cjwatson> Riddell: just retry
 * Riddell retries
<sil2100> Hello release team!
<sil2100> We have published a new mir through the train just now
<sil2100> The upstream developers have assured us that it's a bugfix only release
<sil2100> Mir is also not really used on desktop images (besides desktop-next), so this should be a relatively safe upload - QA has signed it off and confirmed it's at least not causing any regressions on ubuntu-touch
<cyphermox> have they also tested it wasn't regressing desktop-next?
<cyphermox> (am not release team, just curious)
<infinity> sil2100: It's on all the images, it's going to have to wait.
<seb128> cyphermox, desktop-next doesn't do milestones or release so it doesn't matter much
<seb128> it's a rolling testing image, not a production ready product
<cyphermox> seb128: it would still be nice not avoid breaking it a bit, or to break it less :)
<seb128> right, but that's freeze specific
<seb128> +not
<cyphermox> nope
<cyphermox> seb128: since you're here, any news on the B word? :)
<seb128> cyphermox, no, not for this cycle :-/
<cyphermox> boo :(
<ogra_> if you mean the same B word i would mean, ChickenCutlass is just playing woth the PPA
<ogra_> *with
<ogra_> trying to get it to work on the phone
<cyphermox> ok, cool
<cyphermox> he's building his own custom kernel?
<seb128> cyphermox, speaking of which, I've a bug related which would be nice to look at
<cyphermox> seb128: ok
<infinity> Riddell: You around?
<ogra_> cyphermox, ask him, i think he wanted to talk to you anyway about cmdline tools to use for testing
<Riddell> hi infinity
<cyphermox> ogra_: got it
<infinity> Riddell: Hey.  Your images are marked "re-building" on the tracker, but I don't see them actually rebuilding.  Did you trigger rebuilds?
<infinity> Riddell: If you did, the infra might have gotten wedged, I can fix that for you.
<Riddell> infinity: yep, then cjwatson said there was a problem and I should try it again so I did
<Riddell> infinity: fixes welcome :)
<infinity> Riddell: I'll smack it around a bit.
<infinity> Riddell: Smack in progress.
<jibel> cyphermox, bug 1432285 is high importance and something to fix ASAP. The user cannot eject the CD is trapped in an install loop
<ubot93> bug 1432285 in ubiquity (Ubuntu) "Vivid live DVD fails to provide means to eject disc" [Medium,Confirmed] https://launchpad.net/bugs/1432285
<cyphermox> jibel: I know, working on it
<infinity> jibel: He's on it.
<infinity> See? :P
<infinity> jibel: The tracker seems pretty devoid of other interesting looking bugs.  Have you found any other showstoppers that I'm not seeing?
<jibel> infinity, that's the only one if we don't count the fact that I cannot do any successful installation in a VM. Tried qemu and vbox.
<jibel> but HW is ok
<infinity> jibel: Really?
<infinity> jibel: desktop, server, or both?
<infinity> jibel: I did a server install in a VM just last night.
<jibel> infinity, desktop
<infinity> Fun. :/
<infinity> Lemme kvm up a desktop install and see WTF.
<cyphermox> it was working for me yesterday in qemu
<jibel> there is no live session on i386 qemu bios mode
<cyphermox> ok
<jibel> and amd64 doesn't boot after installation in bios and uefi
<infinity> That all sounds rather sketchy.
<infinity> I did have an issue where my server VM hung on reboot once or twice, but it was happening so early that I blamed qemu, not the image.
<infinity> After I killed it, it booted fine.
 * infinity grabs fresh ISOs to give them all a once-over in a bit.
 * infinity grabs fresh ISOs veeeeeery slowly.
<infinity> seb128: Ahh, does that fix the lack of icon reuse?
<seb128> infinity, for upgraders yes, for new install we need https://code.launchpad.net/~seb128/unity/nautilus-desktop-rename/+merge/254103
<cyphermox> ah, perhaps the jenkins issues got current to not get updated
<infinity> seb128: Ahh, kay, so can't be entirely fixed for beta, that's fine.  If it'll be fixed later, that works for me. :)
<seb128> right
<seb128> sorry about that
<infinity> seb128: Sorry for fixing bugs?  Have you turned Canadian when I wasn't looking?
<seb128> lol
<cyphermox> lol
<cyphermox> french canadian is teh worst.
<infinity> No argument here.
<cyphermox> ;)
<infinity> Quebec and Vermont need to split off and form some logging and maple syrup powerhouse.
<jibel> infinity, what is the difference between ubuntu desktop 20150325 and 20150324?
<infinity> Nothing but flannel and bad accents as far as the eye can see.
<infinity> jibel: 20150325 sucks less.
<cyphermox> infinity: only if there are no huge maple syrup heists again.
<jibel> infinity, sucks less but didn't migrate from pending to current :/
<infinity> Riddell: ^ There you go.
<Riddell> thanks infinity
<infinity> jibel: Yeah, the pending/current thing may have broken due to network hiccups and such.
<infinity> That machinery is mostly a black box to me.
<infinity> stgraber: Do you know how the pending/current stuff on cdimage works, and how to make it happy (or check why it's not)?
<cyphermox> it depends on smoketests in jenkins, no?
 * cyphermox looks
<cyphermox> brb
<jibel> yeah, jenkins job broke because of some networking issue and the node it runs on is offline
<jibel> cyphermox, discussing with CI
<cyphermox> ok
<jamespage> slangasek, would you have archive-admin time to review three new oslo packages to unblock openstack kilo-3 entry into the archive?
<jibel> infinity, cyphermox desktop amd64 migrated from pending to current, but i386 didn't. re-re-retrying
<infinity> jamespage: He's on vacation this week.
<infinity> jamespage: That said, if any openstack stuff is on ISOs, it'll have to wait until after tomorrow anyway.
<jamespage> infinity, its not
<infinity> None at all?
<jamespage> infinity, none of the 29 I need to touch for kilo-3
<infinity> Heh.
<jamespage> that's not what I said :-)
<infinity> jamespage: I'll look at these two when I get a chance.
<jamespage> infinity, am I OK to upload the third to the NEW queue as well please?
<infinity> jamespage: What's the deal with the "openstack" package?  Just some convenience metapackages?
<jamespage> infinity, I honestly don't know
<jamespage> I should but I don't
<infinity> confidence++
<jamespage> I think its the 'openstack installer' - lemme check to stokachu
<jamespage> infinity, its not something that comes from my team at least
<stokachu> it's the installer
<infinity> jamespage: And yes, upload the other NEW thing you have.  I'd rather do them all at once if they're similar, since the bugs will likely also be similar.
<jamespage> infinity, indeed
<jamespage> infinity, OK - uploaded - they all prefix 'python-oslo.'
<jamespage> infinity, thankyou
<infinity> jamespage: Are any of these renames of existing things, or are they all entirely new?
<jamespage> infinity, entirely new packages, but refactoring of shared common openstack code into python modules
<infinity> jamespage: Righto.
<infinity> jamespage: Grabbing an early lunch, then I'll review those while I'm playing with beta ISOs.
<jamespage> ta
<jibel> desktop i386 migrated too, finally
<flexiondotorg> Anyone seen an issue when try to install 15.05 on a system that already has btrfs partitions?
<ianorlin> flexiondotorg: are you trying to resize them
<ianorlin> I found an issue that you couldn't back in utopic
<flexiondotorg> ianorlin, Nope. Ubiquity hangs before you see any user prompts. Timeout while kernel waits.
<ianorlin> arhg that isn't good
<flexiondotorg> ianorlin, http://i.imgur.com/NERrzov.png
<flexiondotorg> Trying to create a reproducible test.
<ianorlin> flexiondotorg: what kind of graphics do you have in that machine ?
<stgraber> infinity: I vaguely remember jenkins having a restricted ssh access to nusakan and calling some bin/ script to flip the switch, but that's about as much as I know
<infinity> stgraber: Kay, I think you know about as much as I do about it.
<infinity> stgraber: :)
<infinity> cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1436497 sound less than ideal.
<ubot93> Launchpad bug 1436497 in ubiquity (Ubuntu) "Fails to start from kubuntu live session with failed to remove /run/udisks2/inhibit-polkit " [Undecided,New]
<cyphermox> yuck
<infinity> cyphermox: Still not seeing any particularly dire bugs reported, though, which is nice.  A few that are definitely RC for final, but nothing really beta-critical.
<cyphermox> yep
<infinity> Except maybe the CD eject bug, if people get stuck in a loop and have to go look for a paperclip. :P
<elfy> infinity: is anything likely to happen re the eject bug? that is - rebuilds?
<cyphermox> well, not really
<cyphermox> while you boot you can eject the CD
<cyphermox> and I bet when you're at the grub menu you also could
<infinity> elfy: If it can be fixed by cyphermox soon (very soon), I'd consider a respin for it, but time's running out on it being worth caring about, I think.
<cyphermox> it's trickier and not super friendly, but still
<cyphermox> nah, still just tracking it down
<cyphermox> I think it's because we now call some systemd restart magic so it happily skips everything else.
<infinity> elfy: Definitely an RC bug for final, but not sure it's worth holding the beta up for.
<elfy> infinity: thanks - just needed to know what was likely to happen between now and tomorrow PM
<infinity> cyphermox: Oh, indeed.  The whole shutdown sequence has been mangled.
<infinity> cyphermox: Not sure if casper/ubiquity/misc has changed at all to take any of that into account.
<cyphermox> nope
<infinity> I suspect the answer is "no".
<infinity> Yeah.
<infinity> So, this might be intractable for beta, cause it might be a rewrite of some bits, not a quick fix.
<infinity> Unless there's just somewhere we can poop a .service file that papers over it for now.
<cyphermox> well, I'm going to see. When do you give me until?
<cyphermox> I was going to try to fit in a .service just now
<cyphermox> (or you know, at least start with trying that out on my system)
<infinity> cyphermox: Well, I'm comfy with releasing up to midnight my time tomorrow.  Which probably means respins, if we have any, would need to happen overnight our time, so there's enough time to smoketest, push to mirrors, etc during the day tomorrow.
<infinity> cyphermox: So, if you can some up with something workable in the next 5 or 6 hours?  If you're keen on fixing this.
<cyphermox> yeah
<infinity> s/some/come/
<cyphermox> I'll give you an answer of whether it's an easy fix or not within the next two hours?
<cyphermox> I bet the kubuntu inhibit-polkit issue is also something similar
<infinity> cyphermox: Works for me.
<infinity> The kubuntu thing looks like systemd mounting new things that weren't mounted before, yeah.  And ubiquity being entirely unsure how to deal with that.
<ianorlin> I think fixing bug  1424362 may fix bug 1429531 as well and the to get it to work is just starting libpolkit-backend-1-0
<ubot93> bug 1424362 in software-center (Ubuntu) "no permissions to install or remove packages in vivid daily lubuntu beta 1" [Critical,Confirmed] https://launchpad.net/bugs/1424362
<ubot93> bug 1429531 in gnome-system-tools (Ubuntu) "users-admin cannot create a new user in Lubuntu" [High,Confirmed] https://launchpad.net/bugs/1429531
<infinity> I miss upstart.  I never thought I'd say that.
<cyphermox> haha
<infinity> ianorlin: Absolutely agree that should be fixed.  Not sure today's the right day to fix it, when it's been known about for a month, but if the Lubuntu folks want to push a fix and retest, they're welcome to.
<doko> infinity, accepted the gccgo-5 package dancing with sagari. will be blocked anyway
<infinity> doko: Mmkay.
<ianorlin> bdmurray: for lubuntu gnome-settings-daemon would be correct package for no pointer showing up but you said it should have its own bug but I reported wrong place but can fix that
<bdmurray> ianorlin: I said an issue with the pointer not appearing after an upgrade is different than one after a fresh install or on a live CD.
<ianorlin> bdmurray I know I reported bug 1436509 and think I might have misfiled it at first which seems to be the same issue
<ubot93> bug 1436509 in xserver-xorg-input-mouse (Ubuntu) "cursor not visible but mouse moves on first login after install " [Undecided,New] https://launchpad.net/bugs/1436509
#ubuntu-release 2015-03-26
<cyphermox> anyone here willing to help me test a fix for the CD-ROM ejection bug? I should have a package ready any minute that looks okay on my end
<elfy> cyphermox: in vbox I got corruption, but power off and restart, it had ejected. In kvm it just seemed to hang - had to poweroff - but again it had ejected
<elfy> on a laptop I confirmed bug 1436715
<ubot93> bug 1436715 in casper (Ubuntu) "Vivid DVD fails to reboot or shutdown w/o hard reset" [Undecided,New] https://launchpad.net/bugs/1436715
<flexiondotorg> The is an update to caja in the upload queue. Could someone let it through please?
<flexiondotorg> Just contains a fix for a segfault.
<flexiondotorg> Caja is in the upload queue. It fixes a segfault.
<flexiondotorg> Would somebody be good enough to let in to the vivid archive please?
<brendand> flexiondotorg, see topic
<flexiondotorg> When beta 2 is done, will I be permitted to have the updated Caja included in vivid
<flexiondotorg> Been stuck onm
<flexiondotorg> The motorway for 3 hours so doing this on my phone.
<brendand> flexiondotorg, do you have an FFe?
<cjwatson> brendand: bug fixes don't require FFe
<brendand> cjwatson, indeed - that was the next question (which yes, could have been asked simultaneously)
<cjwatson> Well, you can look at the queue yourself :)
<cyphermox> good morning!
<cyphermox> elfy: thanks, I was aware, I tested the ubuntu iso early after respin.... which means very late last night or very early this morning
<cyphermox> this needs more work to make sure all the systemd jobs get started properly, I guess
<amjjawad> hello everyone
<amjjawad> I have a problem: http://iso.qa.ubuntu.com/qatracker/milestones/336/builds/91028/testcases
<amjjawad> installer crashes :(
<amjjawad> should I re-spin or it is too late?!
<infinity> amjjawad: What would a respin do for you?
<amjjawad> infinity, not really sure, it is 1:00am here and I'm super dead tired and sleepy
<amjjawad> and can't install anything
<amjjawad> it crashes
<infinity> amjjawad: It sounds more like a virtualbox bug?  But I suppose it could be a broken ISO somehow.  Let me grab the GNOME ISO quickly and see how it fares here.
<amjjawad> infinity, ok, thanks!
<ara> infinity, ping
<infinity> ara: If it's the usual question, it's happening this morning because if it doesn't, I won't have room to release the beta.
<infinity> ara: If it's another question, what's up?
<ara> infinity, it was that one :)
<ara> infinity, why is it taking so long? anything we can do differently to avoid this from happening again when 14.04.2 gets released?
<ara> sorry, .3
<ara> infinity, can we add it to the release process steps?
<infinity> ara: I'm afraid I don't have a good answer to the why.  It just kept slipping through the cracks.  Will be improving things for .3, yes.
<ara> infinity, thanks :)
<amjjawad> infinity, same goes to i386 :(
<Riddell> can someone add upgrade to iso tracker? or tell me how to add?
<apw> amjjawad, that would be expected if it is virtual box blowing up, and if you are saying your hosts virtual box is blowing up ... that sounds very much like a bug in the host not the guest
<amjjawad> apw, I can understand but never happened to me as I always test and this is the very first time ..
<apw> amjjawad, and had your host stayed the same for the entire time or have you also upgraded that ?
<amjjawad> also, not sure if this bug: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1436715 is critical or not
<ubot93> Launchpad bug 1436715 in casper (Ubuntu) "Vivid DVD fails to reboot or shutdown w/o hard reset" [Undecided,Confirmed]
<infinity> amjjawad: Not sure that we'll be able to fix that one for the beta, but it's certainly critical for final release.
<amjjawad> I see, thanks infinity but what about the crashing :(
<amjjawad> apw, usually, the vb complains if there is a newer version but it didn't for a while now
<amjjawad> and I am sure this is the first time apw
<apw> amjjawad, people are downloading your image now to test it, takes a little time
<amjjawad> apw, it is 1:22am now here and I'm doing my best to stay awake but ... so tired :(
<amjjawad> maybe I should sleep and check in the morning
<amjjawad> infinity, how many hours left to the release ?
<infinity> amjjawad: Undecided.
<amjjawad> I can't hold it more ... must sleep so will check later infinity
<amjjawad> just saw this infinity : https://lists.ubuntu.com/archives/ubuntu-gnome/2015-March/002882.html
<infinity> amjjawad: I'm testing in qemu/kvm right now...
<amjjawad> infinity, thanks a lot
<apw> amjjawad, i am installing under VB on a vivid host right now
<amjjawad> apw, many thanks
<stokachu> infinity: wrt 'openstack' looks like I uploaded it a day or two late, it replaces cloud-installer package which is in the archive already
<stokachu> infinity: honestly it isn't that bad if it doesn't make it in vivid since its not lts
<apw> amjjawad, ok it installed ocmpletely, i think i am seeing the other "reboot does not work" issue
<infinity> apw: Yeah, everyone should see that one.
<amjjawad> apw, many thanks so that means my Oracle VB is acting naughty?
<infinity> Hrm.  Which, to be fair, could occasionally cause a corrupted target filesystem, if it never syncs.
<apw> amjjawad, yep forced it off and it boots just fine into GUbuntu
<infinity> I really don't want to respin again today...
<apw> infinity, if yours boots and installs ok, i'd say its local to amjjawad
<infinity> cyphermox: What are the odds that we could fix the "not listening for keypress" issue (at least, I assume that's what it is, we're just blocking forever on a keypress we'll never see)
<infinity> apw: yeah, it installed fine, and hard-killing it after the failure to reboot brings up the installed system fine.
<cyphermox> pretty good, I'm assuming it's just more of the same systemd unit ordering issue
<infinity> amjjawad: ^-- Under kvm.
<stokachu> infinity: hmm feature freeze was feb 19th and the package was uploaded on the 19th
<cyphermox> maybe the casper job isn't happening at the right place.
<infinity> stokachu: Oh, I'm not asking for FFes or anything here, I just literally wanted to know what it was about. :P
<amjjawad> infinity, I'm using Oracle VB
<stokachu> infinity: ahhhh
<infinity> stokachu: It was an idle question, not a solicitation for process.
<apw> amjjawad, i am using VB here without issue on a vivid host on those images
<stokachu> infinity: ah ok, sorry i thought I messed up somewhere
<stokachu> infinity: yea basically its the Ubuntu OpenStack installer renamed from cloud-installer to openstack package
<infinity> cyphermox: Ordering seems like a weird thing to blame.  Unless there's a job that says "hey, stop listening to input devices trololol".
<amjjawad> apw, then I have no other choice but to trust your words and accept them and blame my machine.
<amjjawad> but I don't know if it is wise to mark these images as ready
<infinity> cyphermox: I mean, your job is obviously running, since it's popping out CD trays all over the land.  So, it's a question of why isn't plymouth getting control.
<amjjawad> giving that just me and lance tested them
<cyphermox> infinity: well, it seems likely to me that it's not getting the input because either plymouth is started but not quite started right, or the casper job isn't started at the right moment, or the casper job breaks plymouth by not caching it properly.
<amjjawad> at least, that's what the tracker says
<apw> amjjawad, well i suspect we may have to get more testing on them indeed if you are normally tester for themm
<cyphermox> infinity: so that's what I meant by ordering.
<infinity> cyphermox: Fair enough.
<infinity> cyphermox: So, historically, the caching issue only led to a lack of display, but the input still worked (so, people whacked [enter] blindly on their "hung" computers, and they'd reboot).
<cyphermox> yes
<infinity> cyphermox: But that if we're now running it a tiny bit later, I could see how it would just fail to work entirely.
<infinity> s/that //
<cyphermox> as far as I know, we are
<cyphermox> we're running this about as late as it seems we could
<amjjawad> apw, I sent more than one email and posted on our social media channels but not sure why we have very few testing :(
<infinity> Yeah.  Which, to be fair, seems like the right time to run it.
<cyphermox> (from my very limited understanding of it)
<cyphermox> yeah
<infinity> But will break miserably if the filesystem is effectively already gone.
<cyphermox> fwiw, the call to plymouth to display the message happens before eject, and the input listening happens after, so my money is on caching for now
<cyphermox> otoh, it could also just display the message, not wait for input and reboot if it was just not getting the request for input
<infinity> cyphermox: You know, it could be worse.  It could be the whole system just freezing immediately after eject.
<cyphermox> it could be
<cyphermox> it doesn't seem to explode as badly if you don't run with splash though
<elfy> cyphermox: I thought you probably were - but just in case I mentioned it :)
<cyphermox> no problem
<cyphermox> elfy: that's what I'm working on right now
<elfy> ok :)
<infinity> cyphermox: So, I think we need to make a hard decision soon for "try to fix or just release note" on the reboot thing.  If it looks like it'll be architecturally painful (or time consuming) to fix, I think we'll just have to pass and fix it ASAP post-beta so we don't forget.
<cyphermox> fixed it!
<cyphermox> :D
<cyphermox> let me make sure it's really really good
<cyphermox> elfy: want to help test the fix?
<mdeslaur> infinity: who do I need to bug to get vlc approved, the mate folk?
<cyphermox> it's just a matter of editing /sbin/casper-stop and adding /lib/systemd in place of /etc/rc?.d in the caching list
<mdeslaur> (not sure what "mozilla" is in the seed there)
<infinity> mdeslaur: Looks like mate and myth, according to seeded-in-ubuntu, and myth is lts-only, so just mate.
<mdeslaur> infinity: who's in charge of mate?
<mdeslaur> yo, mate people, speak up! :)
<cyphermox> flexiondotorg: ^
<elfy> cyphermox: if possible - always happy to help
<cyphermox> I had a good response in console in qemu, so now it's hardware testing
<elfy> cyphermox: and this would work from a livesession ?
<cyphermox> yeah
<cyphermox> you can just sudo vi it
<elfy> okey doke - just booting laptop then
<infinity> cyphermox: Does this magically give us a visual prompt too, or just make [enter] work blindly again, as before?
<cyphermox> maybe it's not quite there though, still no response
<cyphermox> infinity: you already do have the visual prompt
<infinity> cyphermox: I sure don't.
<cyphermox> where?
<infinity> cyphermox: At least, not on the xubuntu I tested a while ago.
<infinity> cyphermox: Maybe it's a timing thing, but on xubuntu, when you click the "reboot" button from ubiquity, the system basically just hangs there.
<cyphermox> I'm still using the dvd I burned for ubuntu last night
<cyphermox> in qemu?
<infinity> Yeah.
<cyphermox> I also get a hang, the display doesn't change
<elfy> infinity: I get similar in vbox and kvm - just hangs, but h/w gives the Enter and remove
<infinity> elfy: Fun.  So totally a timing thing.
<cyphermox> it does fix the rebooting from a VT with no splash, though, on qemu
<infinity> cyphermox: Well, I'm about 75% on the way to just calling the current images "good enough" and starting with all the paperwork, but if you can come up with something better than the current state, lemme know.
<cyphermox> ok
<infinity> I've done no paperwork at all this cycle, so ugh... Whee.
<cyphermox> arf
<elfy> cyphermox: well - that didn't work, assuming not using vi isn't an issue
<cyphermox> no, I noticed, it only seems to help a bit with the vt-only reboot, not with teh splash
<infinity> mdeslaur: 3.3MB diff from 2.2.0~rc2 to 2.2.0?  How did you manage that feat?
<mdeslaur> infinity: heh, don't blame me :)
<infinity> cyphermox: Any news, or am I just calling this good enough?
<cyphermox> good enough
<cyphermox> it's going to take a few more hours to get it better
<cyphermox> and I am hungry :/
<infinity> Alright.  Spinning source ISOs and tying off some bows.
<infinity> ... after I teach publish-image-set about MATE.
<cyphermox> ah?
<ianorlin_> argh not much lubuntu testing got done after the last respin
<infinity> ianorlin_: All that really should be needed is boot/install/reboot smoketesting to make sure it didn't somehow regress horribly.
<flexiondotorg> I've been stranded in the car all day.
<flexiondotorg> 'sup with the release?
<flexiondotorg> See new iso images. Will do a quick test.
<flexiondotorg> Is there a release ETA?
<infinity> flexiondotorg: ETA is "later today", but these are the images I intend to ship unless someone decides to pull their flavour (or an image) at the last minute.
<flexiondotorg> infinity, Understood. Looking at the tracker it seems things are in better shape than yesterday.
<flexiondotorg> :)
<infinity> flexiondotorg: Well, MATE looks entirely untested right now, so some smoketesting there would be nice.
<infinity> flexiondotorg: Note that there is a reboot bug (or, rather, a failure to reboot), which we're not going to fix before release, but it's bad enough that I think I'll mention it in the release announcement, not just bury it in the release notes.
<flexiondotorg> infinity, Will do. But we did extensive testing yesterday. The only issue we encountered appear half (mostly) fixed now.
<flexiondotorg> infinity, That is the half fixed thing to which I refer :) I think the current situation is better than no eject prompt.
<infinity> flexiondotorg: I'm on the fence about which is worse, but really, we just need to fix it properly before final.
<rcj> infinity, cloud images are ready to go
<infinity> rcj: Shiny.
<rcj> infinity, I'll be watching for the go-ahead to start publication
<flexiondotorg> infinity, Downloading now. But, I live in a rural area and connected to the Internet with short wave radio, so.....
<infinity> rcj: It'll be several (many?) hours, but we don't have to be perfectly in sync either.  If you push early, you'll be all set up by the time I do the release announcement after all.
<infinity> flexiondotorg: I assume zsync helps a bit.
<flexiondotorg> I t   d o e s . . .
<flexiondotorg> Still 13 mins for me though.
<infinity> Ouch.
<rcj> infinity, I'll kick things off in ~2 hours to get them going
<flexiondotorg> Yeah, but the view is lovely and the cows have nice grass to chew on ;)
<flexiondotorg> infinity, This is my first official cycle and I'm still learning.
<flexiondotorg> Can you clear something up for me
<flexiondotorg> Caja is in the upload queue. It was a sync from Debian to fix a segafault.
<infinity> flexiondotorg: It'll get in right after we push out the images, so people will get it on upgrade.
<flexiondotorg> Do I have to request any new packages be let in from now on or when Beta2 is over will that stuff just "flow in"?
<flexiondotorg> infinity, Thanks.
<infinity> flexiondotorg: For bugfixy things, you shouldn't need to make any justifications, we'll just review and let it in.  For larger things that should have had Feature Freeze Exceptions, you might need to make a case.
<flexiondotorg> infinity, I'm only doing bug fixes.
<infinity> flexiondotorg: Right, then you don't have much to worry about, just upload as usual.
<flexiondotorg> infinity, But I understand I can submit package updates that just carry new translation stings until April 9th, right?
<infinity> flexiondotorg: You can keep pushing bugfixes pretty much right up until final release.  The non-langpack-deadline is actually a weird thing for just a few packages, and not really worth thinking about.
<infinity> flexiondotorg: New master strings were frozen long ago, but for packages that only affect you, you have some leeway if you'd prefer to break translations for a good cause.
<flexiondotorg> So, I can request new uploads for a couple of package that just carry new translations early next week?
<infinity> flexiondotorg: Yeah.  If you're just adding new translations, that can really happen any time.  It's new master strings that are problematic, as they invalidate all the other translations.
<flexiondotorg> infinity, Thanks. Understood. I'm not adding new msater strings.
 * infinity goes to find a snack while source ISOs build.
 * flexiondotorg haz iso
<mitya57> Hi, can someone please reject my gnome-flashback upload from the queue?
<mitya57> The changelog entry is wrong + I want to include one more fix.
<mitya57> (In vivid)
<infinity> mitya57: Done.
<mitya57> thanks
<jibel> infinity, desktop testing is almost done. The major issue is OEM installations. Sometimes the session doesn't start (X or unity-settings-daemon crash bug 1436861) and the OEM user is not removed ( bug 1436936 )
<ubot93> bug 1436861 in unity-settings-daemon (Ubuntu) "unity-settings-daemon crashed with SIGSEGV in engine_update_composite_device()" [Medium,New] https://launchpad.net/bugs/1436861
<ubot93> bug 1436936 in muon (Ubuntu) "toolbar and configure toolbars missing in muon muon on Kubuntu 15.04 Beta 2" [Undecided,New] https://launchpad.net/bugs/1436936
<jibel> bug 1436937
<ubot93> bug 1436937 in ubiquity (Ubuntu) "Temporary OEM user not removed after end user setup" [Undecided,New] https://launchpad.net/bugs/1436937
<infinity> jibel: That second one looks like another "needs porting to systemd" bug.
<infinity> jibel: Can you note whatever you think is relevant in the release notes?
<jibel> infinity, OK, we'll just verify that the end user is admin of his system even if OEM is still present.
<elfy> infinity: clarifying - we're going with what we have now?
<infinity> elfy: Yeah, that's the plan.
<elfy> ta :)
<flexiondotorg> infinity, I'm also testing the OEM user thing.
<ianorlin_> I don't really see a fix for bug 1432843 coming out in a few hours
<ubot93> bug 1432843 in xorg (Ubuntu) "Lubuntu failed to boot" [Critical,Triaged] https://launchpad.net/bugs/1432843
<flexiondotorg> infinity, When do you need confirmations?
<infinity> ianorlin: No, and I'm not sure exactly what to make of that one.
<infinity> flexiondotorg: Soon.
<flexiondotorg> infinity, OK. I'll test faster...
<ianorlin> at least the alternate for 32 big lubuntu will work but I don't see how that will get fixed in time
<infinity> flexiondotorg: I'm not in a huge rush, still have a bunch of cleanup to do on the master cdimage system.
<infinity> ianorlin: Well, the reason I don't know what to make of that bug is that the claim is that Ubuntu i386 has the same problem, which no other testers are seeing.
<infinity> ianorlin: So, if it's simply very hardware specific, we can certainly test that and release it still.
<ianorlin> infinity: there isn't a boot option for turning zram off is there
<ianorlin> infinity: the wierd thing is I had that same hardware install amd64 just fine
<infinity> ianorlin: There are no boot options to influence zram, no.
<cjwatson> I'm pretty sure "nocompcache" disables it
<cjwatson> Used to, at least
<infinity> cjwatson: Ahh, for the builtin one, yeah, but they also have zram-config seeded.  I wonder if that could interact poorly.
<infinity> I really should have merged those ages ago.
<ianorlin> um I just tried with nocompcache on the i386 dialy and the installer started on the same hardware it failed on earlier
<infinity> ianorlin: So, probably not an xorg bug.
 * infinity wonders why you have zram-config seeded to lubuntu-live
<ianorlin> there were certain machines were it made a huge performance difference on the low end when they don't yet have swap so installs would take a really long time if you were say resizing an ntfs partition
<infinity> ianorlin: So, this absolutely sounds like something we can fix over the next few days.  But not right now.  If you're comfy with telling people to boot with "nocompcache" for the lubuntu installer, we can release what you have and fix it later.
<infinity> How this ever really worked is a mystery to me, though.
<infinity> ianorlin: If you're not comfortable with that, we can skip releasing the i386 desktop image for the beta.
<flexiondotorg> infinity, cyphermox OEM config is quite busted.
<flexiondotorg> infinity, cyphermox I confirm the the oem user is left behind and has admin rights.
<flexiondotorg> Or rather sudo rights.
<flexiondotorg> infinity, cyphermox I've updated https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1436937
<ubot93> Launchpad bug 1436937 in ubiquity (Ubuntu) "Temporary OEM user not removed after end user setup" [Undecided,Confirmed]
<rcj> infinity, cloud images will be live in a bit, I've kicked it off before I have to drop off for a bit.
<infinity> darkxst: Around?
<darkxst> infinity, morning
<infinity> darkxst: Hey.  You have enough context and a willingness to sign off on the gnome images as "good enough"?
<infinity> darkxst: amjjawad was apparently having some issues with them in his local virtualbox setup, but apw and I couldn't reproduce in vbox or kvm.
<darkxst> infinity, yeh, I not heard of any other reports of that crash
<flexiondotorg> infinity, All set for Ubuntu MATE.
<infinity> flexiondotorg: Has that powerpc image actually been tested?
<flexiondotorg> infinity, Yes, but none of the buggers could be arsed to do it properly.
<flexiondotorg> infinity, As far as I can tell depending on the system it works.
<infinity> Heh.
<infinity> Yeah, it'll be hit and miss, given that it's > 10 year old hardware they're playing with.
<flexiondotorg> infinity, There are regressions though. X is dying on iBook G4s which worked fine in Beta 1.
<flexiondotorg> I think the new Xorg is busted for PowerPC. But, they are a motivated group and maintain custom versions of mesa etc. So, I'll try and get them engaged.
<infinity> flexiondotorg: Yeah, custom versions don't really help anyone, you should see about getting them engaged with upstream or us or both.
<flexiondotorg> infinity, I intend to for 15.10.
<flexiondotorg> I want them to help with the initrd customisations.
<infinity> ianorlin: Alright, it's all on you and your last three unmarked images.  What's the story with them?
<flexiondotorg> So, they don't patch post-install.
<ianorlin> I think wxl wanted powerpc for dialies but lts only
<infinity> ianorlin: Okay, so that just leaves i386 desktop.
<ianorlin> nocompcache still failed on a kvm virtual machine so it doesn't solve everything
<ianorlin> I sent out a mail asking other people to see if nocompache solves it but no repsonse yet
<ianorlin> still think desktop i386 is pretty broken
<infinity> ianorlin: We can skip publishing it, up to you.
<ianorlin> I think that is best since the alternate works well enough
<infinity> ianorlin: Alrighty.
<Riddell> infinity: ETA to announce?
<infinity> Riddell: Just synced mirrors now, so going to give in some time to settle.  Maybe a couple of hours.
<Riddell> thanks, I'll take my laptop home
<ianorlin> I have my release notes at https://wiki.ubuntu.com/VividVervet/Beta2/Lubuntu but need to get grocieres so will be afk for  a bit
#ubuntu-release 2015-03-27
<flexiondotorg> infinity, Well done. You can have that sleep now ;)
<infinity> flexiondotorg: Not until I verify a bunch of bits and send an email.
<infinity> flexiondotorg: But yeah, close.
<flexiondotorg> I posted my release notes. Time for sleeping...
<infinity> flexiondotorg: G'night. :)
<flexiondotorg> Zzz..
<cyphermox> o/ am back.
<infinity> cyphermox: Good, you can proof-read the release announcement.
<infinity> cyphermox: http://paste.ubuntu.com/10686986/
<infinity> cyphermox: Most of it is copy-and-waste from 6 months ago, but the hilighting of the two important bugs isn't.
<infinity> Riddell: ^-- That wording seem sane to you?
<doko> you start with "ubuntu team", but end with "ubuntu release team"
<infinity> doko: Yeah, well.  The release team is sending the email, but the broader Ubuntu team is responsible for the 5 months of work that went into it.  At least, that's how I read it.
<infinity> But if no one has any input on the wording of the section about the two bugs, I'll just go click send. :P
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Beta 2 | Archive: Beta Freeze | Vivid 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
<Riddell> awooga
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Beta 2 | Archive: Feature Freeze | Vivid 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
<cyphermox> so, who's going to update the slideshow to get rid of the unicorn and replace it with a vervet or a reasonable facsimile?
<infinity> cyphermox: Well, if we follow with tradition from last release, it'll be me, on release day.
<infinity> cyphermox: So, let's not go with tradition and chase up some design people next week. :P
<cyphermox> infinity: sorry to remove the fun work from your plate.
<cyphermox> fwiw I just did a ubuntu oem install and the user got removed... it didn't quite work as well as it should have though, the reboot after running oem-prepare showed a userdel warning on screen on VT1, VT2 was fine to login, VT7 I can't remember.
<cyphermox> I still can't make the casper eject prompt answer to enter, I'm still thinking it's some kind of issue in plymouth given that it works properly if I remove splash altogether; but I'm going to sleep on it
<infinity> cyphermox: Interesting.  So maybe it's racy?
<cyphermox> infinity: probably
<cyphermox> like you said, more fun stuff to port to sytemd
<Mirv> hey archive admins. again the train would like to bypass binNEW queue if I
<Mirv> 'd push publish, so I'd like you to review the new doc/doc-html packages at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+packages similar to what you would do if they were in NEW queue
<Mirv> qtpim5-doc, qtpim5-doc-html, qtfeedbac5-doc, qtfeedback5-doc-html
<jamespage> infinity, nudge re oslo packages in NEW (guess you've been a bit busy :-))
<infinity> Mirv: Looks sane to me.
<Mirv> thank you
<infinity> Mirv: Oh, wait.  One thing I didn't check, were those docs previously shipped in other packages, or are they entirely new files?
<infinity> Mirv: I see no Breaks/Replaces on anything, so I hope they're all new files.
<Mirv> infinity: too late! but no not previously shipped anywhere.
<infinity> Mirv: Mmkay, then +1 for having docs we didn't have before. :P
<infinity> (I do wonder how often the modern user uses doc packages, but I'm sure someone does)
<Mirv> thank you, again. the community team wants them in archives from where they can fetch their web documentation, and SDK team wants to include them in the Qt Creator index.
<infinity> Maybe I'm weird, but I live in an old skool new skool mix where I look for a manpage, and if man can't help me, it's Google.  Very little in between.
<Mirv> quite few people probably install html documentation and then point their browser to those instead of online copy that surely exists. but the inline .qch documentation in qt creator is useful so that one does not need to switch to browser.
<infinity> Ahh, yeah, I assumed from the file extension that it was a help browser format.
<infinity> Though, I think the most helpful thing one can do with help browsers is write about 300 pages on every single possible way your Internet connection might be broken and how to diagnose and fix it.
<infinity> And then, Appendix A: Firefox, Appendix B: Google. :P
<infinity> My parents, on the other hand, use in-app help extensively, and refuse to admit that strangers on the Internet might know the answers.
<infinity> So, to each their own.
<ianorlin> hmm id the cron job not back on?
<ianorlin> I don't see cron jobs back on
<infinity> ianorlin: Nope, I'll re-enable them.
<elfy> where would you look to see? other than noticing nothing new on the tracker ...
<infinity> elfy: crontab on a host no one has access to.
<infinity> elfy: But re-enabled now.
<elfy> ok :)
<elfy> so - just noticing that nothing new is on the tracker for us meremortals :D
<infinity> elfy: Sure, I enabled the cronjob, that didn't magically build new images.  They'll build at their scheduled times over the next day.
<elfy> infinity: not quite what I meant - for me to see that - just seeing there's not been a new image on tracker is the way?
<infinity> elfy: Well, tracker or the usual dated directories on cdimage, or the build logs on people if the builds are failing.
<elfy> yep
<elfy> I'd look on tracker first - usually bleary eyed
<elfy> anyway - thanks :)
<slangasek> infinity: I see that ubuntu-core arm64 builds are still failing, now with a keyserver.ubuntu.com connection failure.  is that RT still in progress?
<infinity> slangasek: The RT still exists, I didn't push anyone to add a cowboy, since no one was attempting builds (or mentioning failures).
<slangasek> infinity: not looking for a cowboy, but a proper fix
<infinity> slangasek: Right, well the other firewall change was a cowboy, the RT is to make it permanent.
<slangasek> yep
<infinity> slangasek: But given backlogs, a cowboy is your best bet if you need the images working ASAP.
<infinity> slangasek: Compounding the hilarity, lamont is working on replacing the firewall in question.
<slangasek> ah fun
<infinity> slangasek: The current one is, I believe, lucid-only hardware, so needs to go.  Much like chinstrap, and a few others.
<lamont> infinity: the current one is actually post-lucid capable, but lucid needs to go, and that's a reboot, and the new one is just sitting there.  so rather than reboot for the outage, we're going to cutover for the possible non-outage
<lamont> infinity: I have a littel more testing before it becomes a "hey, I think we can pretend it never happened" or "there will be a reboot of the firewall at $DATETIME"
<infinity> lamont: Fair enough.
<lamont> infinity: and the former case there is "brace for possible outage" mixed with some mitigation, depending on how scarry the cutover testing proves
<lamont> infinity: all of which means: have you any pariticular dates in the next couple weeks that I should avoid for cutover day?
<infinity> lamont: The sooner, the better, and have me on hand when you do it.
<infinity> lamont: Don't want it to happen during release week nor, ideally, the week before.
<infinity> lamont: So, sometime in the next two.
<infinity> lamont: In the next two, or wait for a month, I guess.
<lamont> ack.  I'll work on my testing between now and monday, for the additional reason of wanting to get the 4 laptops and the switch off my desk.
<infinity> lamont: Most intense pain (at least for the buildds) can be mitigated by just stopping buildd-manager before you screw with firewalls, mind you.
<lamont> infinity: that is a "definitely-do" step
<infinity> lamont: But if this is kiwi (it is, right?), there's a lot more behind that, so I assume you need a better downtime plan than just "make the buildds happy".
<lamont> yep
<lamont> "Even if we do this as a seamless cutover, stop the buildd-manager while it's happening, and restart it after we're done. trivial step that saves worlds of pain if we trip."
<lamont> infinity: and by "next two" you mean the weeks beginning 30 mar and 6 apr, yes?
<infinity> lamont: Yeahp.
<infinity> lamont: Anything later than that is probably "too late" until after release.
<lamont> ack
 * lamont put s"must be done by 9 apr" on that
<infinity> lamont: Since we're talking firewalls, could I get you to cowboy something for slangasek on the current firewalls? :P
<lamont> no
<lamont> how many firewalls, how many commands?
<infinity> lamont: Sadness.
<infinity> lamont: 1SS buildds need to see keyserver.ubuntu.com:11371 TCP.  Not sure how many firewalls that is.  See RT#79768
<infinity> lamont: My bet it it's only one firewall blocking it.
<infinity> s/it it/is it/
<lamont> ugh.  let me see if I can find you a victim
<infinity> lamont: Anyhow, the real subject of RT#
<infinity> Err.
<infinity> lamont: Anyhow, the real subject of RT#79768 (normalize 1SS firewall setup with 3FP) should hopefully be on your radar for the cutover.
<lamont> I assume that an RT got filed for it?
<infinity> lamont: The above referenced RT, yes.
#ubuntu-release 2015-03-28
<lamont> infinity: stake in the ground for 2015-04-02 2000Z for kiwi "upgrade"
<lamont> infinity: I even sent  you an invite, so you see it
<infinity> lamont: Shiny.
<lamont> which gives me a deadline to figure out by monday just how I'm announcing that
#ubuntu-release 2016-03-28
<jcastro> Can someone lend us a hand with https://bugs.launchpad.net/ubuntu/+source/charm-tools/+bug/1546776
<ubot5> Launchpad bug 1546776 in charm-tools (Ubuntu) "[FFe] charm-tools 2.0" [Undecided,New]
<jcastro> and https://bugs.launchpad.net/ubuntu/+bug/1547115
<ubot5> Launchpad bug 1547115 in Ubuntu "[FFe] charm 2.0" [Undecided,New]
<cyphermox> slangasek: ^ was that you?
<cyphermox> (libcxl)
<slangasek> cyphermox: yes
<cyphermox> mkay
<slangasek> why? are you going to tell me there was something wrong with it? ;)
<cyphermox> it made infinity cry last time
<slangasek> oh?  the packaging looked straightforward to me
<cyphermox> it's not terribly bad, just not great either. I gave frediz feedback
<cyphermox> no, it's more about the upstream build system
<cyphermox> it is pretty straightforward, yes
<jdstrand> fyi, ubuntu-core-launcher adds a feature (devpts newinstance handling), but I thought Ubuntu Core had a freeze exception? let me know if I need to do all the paperwork
<slangasek> infinity: oh neat, this dep-wait will be clearable soon. https://launchpad.net/ubuntu/+source/wings3d/1.4.1-5ubuntu1
<slangasek> infinity: so, gcc-5 is blocked in -proposed because of the linux autopkgtest failures (-proposed vs. xenial mismatch).  What's the policy on those?  Just force it through?
<infinity> slangasek: If you're positive the test failure isn't GCC's fault, just skiptest gcc-5.
<slangasek> infinity: oh, actually I was assuming that this was the usual problem of linux autopkgtests failing when there's a new version in -proposed; looks like this might actually be some sort of kernel regression.  Even more clearly not gcc-5's fault!
<infinity> slangasek: Either a kernel regression or a test regression (the tests aren't in the package, but pulled from git at test time).
 * slangasek nods
<jdstrand> slangasek: hey, I just uploaded ubuntu-core-launcher 1.0.22. it has a critical bug fix (1.0.22) but also a feature (newinstance of devpts in 1.0.21 that hadn't been approved yet)
<jdstrand> slangasek: I didn't do FFe stuff since I thought snappy stuff had a standing exception. I can do so if needed, or we can talk about it
<slangasek> jdstrand: do you have a bug # for the standing exception?  that seems like something we /should/ do but I'm not sure we went through the process
<jdstrand> slangasek: I don't know of one. I just remember I asked about and people agreed and I thought they went off to do it
<slangasek> heh
<jdstrand> this was some time ago
<infinity> jdstrand: Your changelog is syntactically broken.
<jdstrand> infinity: in what way? lintian is happy enough...
<slangasek> aaaaaand why is my chroot missing /dev/shm
<infinity> +ubuntu-core-launcher (1.0.21) xenial; urgency=medium
<infinity> +  * src/main.c: setup private /dev/pts
<infinity> jdstrand: ^-- Missing a newline.
<jdstrand> oh, weird, so it is..
 * jdstrand fixes
<jdstrand> ok, as you can see I rejected my own upload, and now I just uploaded a new one
<jdstrand> slangasek (and infinity, not sure who is looking at this): to ease your review, this is the pts change: http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/revision/100. it was reviewed by the security team. tested in varous snappy configurations including docker and lxc running under it
<slangasek> jdstrand: I don't see any FFe bugs for ubuntu-core.  Can you (pester someone to) open one and provide a list of packages that should be covered?
<jdstrand> slangasek: yes. I'll be in a meeting tomorrow and in a position to do that
<slangasek> jdstrand: ta
<jdstrand> I'll also note that the pts changes got signoff from sarnold and the profile changes in 1.0.22 were reviewed by tyhicks
<jdstrand> I'm going to stop away but I'll keep an eye on backscroll
#ubuntu-release 2016-03-29
<rcj> sru folks, can I get a promotion for walinuxagent to wily-updates for bug #1559307?
<ubot5> bug 1559307 in walinuxagent (Ubuntu Wily) "[SRU] update walinuxagent to 2.1.3 in Wily" [Undecided,Fix committed] https://launchpad.net/bugs/1559307
<rcj> infinity or arges ^
<arges> rcj: i can handle
<rcj> arges, thanks
<rcj> much appreciated
<arges> rcj: done
<stgraber> ^ I rejected juju from the queue as it doesn't have an approved FFe, this doesn't mean that there is anything wrong (or right) about the upload itself
<slangasek> so... how did we just get a new component mismatch for po-debconf, post-beta?
<infinity> slangasek: *blink*
<slangasek> or is this email lying to me?
<infinity> slangasek: Oh, new perl modules.
<infinity> slangasek: I thought you meant po-debconf itself.
<slangasek> no, I mean po-debconf, which ought not to have changed recently, now has new deps?
<infinity> Guessing one of its deps has new deps.
<infinity> Or something.
<infinity> Erm.  Nope.
<infinity> Wat?
<slangasek> libio-compress-perl is a direct Recommends of po-debconf and is in universe
<infinity> Right.
<slangasek> did cjwatson and xnox land germinate changes that confused c-m?
<infinity> In wily, it only did libcompress-zlib-perl
<infinity> But, as you say, it hasn't changed in ages in xenial.
<slangasek> libcompress-zlib-perl is not a package it seems, but a virtual one
<infinity> Oh!
<slangasek> Reverse Provides:
<infinity> Yes, same deps in both.
<slangasek> libperl5.22 5.22.1-9 (= )
<slangasek> libio-compress-perl 2.069-1 (= )
<infinity> So maybe an alt resolution changed.
<infinity> In wily, perl provides libcompress-zlib-perl
<infinity> And libperl in xenial, as you say.
<infinity> But also no new perl recently that moved that around.
<infinity> So still a bit confused.
<infinity> slangasek: It's probably resolvable by explicitly seeding libperl in the same place as perl, or something equally gross, but the timing of this certainly points to someone breaking germinate.
<infinity> (given that none of the packages involved changed recently)
<slangasek> infinity: well, but that germinate output comes from the copy running on ftp-master, which I wouldn't expect to change without mention :)
<infinity> slangasek: Plot thickens.  It's only listed in armhf output.
<slangasek> hmm!
<infinity> http://paste.ubuntu.com/15554184/
<infinity> slangasek: So, maybe something went out of sync or otherwise busticated on ARM.
<infinity> Or something touch-specific.
<infinity> slangasek: Are you digging further into the po-debconf WTFery, or did you want me to run with it (after I finish some IBM bits I've been working on)?
<infinity> slangasek: Realised we may have both dropped it on the floor, thinking the other was dealing with it. :P
<slangasek> infinity: it's still on my queue, but I've been flash-sponsoring php uploads and will now grab food; feel free to dig without me
 * ogra_ notes that this channel looks more and more like a logfile
<stgraber> that tends to happen during this part of the cycle, especially when doing mass rebuilds after a freeze :)
<slangasek> so does my inbox :P
<ogra_> haha
<cjwatson> slangasek: Nothing's changed in germinate as yet.
<slangasek> cjwatson: yep, thanks :)
<xnox> slangasek, i'm pretty sure i have not addressed cjwatson's comments hence nothing was merged nor deployed yet.
<LocutusOfBorg> pretty please accept cmake 3.5ubuntu2 from unapproved
<LocutusOfBorg> the ubuntu1 in -release that has just landed is broken
<LocutusOfBorg> and the block for migration has been removed too much in advance :s
<LocutusOfBorg> (because ubuntu2 went in that queue)
<cjwatson> xnox: Also the LP side must be implemented and deployed before deploying germinate.
<cjwatson> xnox: (Otherwise we'll break a ton of builds.)
<cjwatson> xnox: (Or at least incite AAs to do so.)
<LocutusOfBorg> yay the first bug because of that landing https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1563548
<ubot5`> Launchpad bug 1563548 in cmake (Ubuntu) "CMake 3.5's pkg-config support broken" [High,New]
<xnox> cjwatson, my understanding is that germinate changes can land, it's just we may not flip the "no-follow-build-depends" feature in the seeds until lp is ready.
<xnox> cjwatson, speaking of lp - should i be providing patch for that too?
<slangasek> LocutusOfBorg: reviewing.
<LocutusOfBorg> thanks slangasek
<slangasek> LocutusOfBorg: I am singularly unimpressed with FFes for core build components, past beta freeze
<LocutusOfBorg> actually as you can see it wasn't intended to land, the block migration has been removed with an assumption of "package auto accepted" probably
<cjwatson> xnox: Ah, true, we could land it without the seed feature flag once you fix those bits.
<slangasek> it shouldn't have been uploaded if it wasn't intended to land
<slangasek> it's a *build* system
<LocutusOfBorg> slangasek, a good archive rebuild has been done, and Debian had that cmake too since some time
<slangasek> we build in -proposed
<LocutusOfBorg> slangasek, I mean ubuntu2 should have been gone in -release
<cjwatson> xnox: I suspect neither of us has much more time to spare than the other, and I can probably do an LP change more quickly, but we'll see
<LocutusOfBorg> ubuntu1 was migration-blocked
<LocutusOfBorg> but removing the block without the ubuntu2 accepted in proposed triggered the migration
<infinity> LocutusOfBorg: The block was removed by a human, not a computer.
<infinity> (It was pitti)
 * LocutusOfBorg is not real part of this issue, he is just trying to help, nothing more
 * LocutusOfBorg has some knoledge on the particular patch due to previous merges, and helped in fixing the fixable, and he will help more if new issues arises
<slangasek> infinity: you see that on a blocking bug?
<infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1534263
<ubot5`> Launchpad bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.5 series to Ubuntu Xenial 16.04LTS" [High,Fix released]
<xnox> cjwatson, i wonder if things will be resolved differently with universe enabled.... due to e.g. "a | b" build-depends, where "a" is in universe =/
<cjwatson> xnox: Almost surely.
<slangasek> infinity: thanks
<cjwatson> xnox: We can hope that the consequences are minor ...
<xnox> i wonder if it is statically analyzable, surely we don't have that many "a | b" build-depends.... one can hope.
<cjwatson> (I think they probably will be, but perhaps somebody should try to work out how to simulate the resolver for everything)
<infinity> We intentionally use a|b to pick a preferred b due to the ogre model.
<infinity> But I don't know how often we do it.
<infinity> And, really, we should just stop doing it that way.  But "just stop that" is a hard thing to do with 4 weeks to go.
<infinity> cjwatson: I suspect it's a lot less prevalent these days, since the Debian release team has been pushing people for binNMUability for transitions.
<infinity> cjwatson: We used to take heavy advantage of a|b due to deps like "libfoo2 | libfoo-dev", so we could rev libfoo before Debian.
<xnox> only 256 with a '|' in build-depends
<infinity> But Debian has been changing that for years, so transitions can be hands-off.
<xnox> in main
<infinity> xnox: That might almost be analyzable.
<cjwatson> I think a lot of those will be non-existent-in-Ubuntu | existent-in-Ubuntu or vice versa.
<infinity> Hopefully they all are. :P
<cjwatson> With that it might be possible to get it down to a list short enough to check by hand.
<cjwatson> Which is probably quicker than trying to write an analyser if it's that sort of length.
<infinity> As I said, historically, it was "in-universe | in-main" to force forking from Debian.
<infinity> I'd like to think 99% of those are gone.
<infinity> Well, more subtly, "in-universe | provided-in-main"
<cjwatson> FWIW my plan was to (ab)use the newish DistroSeries.publishing_options column to add a new flag for this.
<cjwatson> I wish I'd thought of this and just called it options or something, but anyway.
<cjwatson> Yeah, gotta check Provides for the existence checks, definitely.
<infinity> Oh man, I just had an evil thought.
<infinity> cjwatson: This concern is purely about build-dep resolution in sbuild, not about germinate, right?
<infinity> cjwatson: Cause I could totally just pin main a tiny bit higher than universe, and it might DTRT. :P
<infinity> (Though, maybe not... apt might not be that smart)
<infinity> Actually, I'm sure it's not.
<infinity> Pinning is just for versions of the same package, now that I think of the code.
<infinity> Drat.
<infinity> No evil for me.
<cjwatson> Yeah, I doubt that would help.
<infinity> BUT I WANT EVIL.
<xnox> looking most of things are mostly harmless
<xnox> gazzilion of libperl-foo-dev | perl (>= new enough), or vice versa
<xnox> a bunch of libfooN-dev | libfoo-dev
<cjwatson> I'd suggest doing the initial filtering automatically.
<cjwatson> Grab all Package entries and all Provides (remembering to comma-split) from Packages on all architectures, use that as the existence filter.
<infinity> xnox: We use "libfooN-dev | libfoo-dev" to force transitions early sometimes.
<xnox> bison | byacc,
<mwhudson> hm i guess i should fix the one of those in golang-1.6 at some point
<infinity> But if they all resolve fine in xenial today, we can deal with the fallout for 16.10.
<xnox> mawk | awk, is popular too.
<xnox> sometimes with gawk
<infinity> mawk | awk is a no-op, given awk is Essential.
<infinity> gawk, however, is not.
<xnox> autopoint | gettext (<< 0.18-1), autopoint | cvs -> looks weird
<xnox> why "gawk | awk" or "mawk | awk" make any difference?
<xnox> i'm pretty sure neither generate runtime, or built-using dep =)
<xnox> hence it's irrelevant in the no-follow-build-depends world as to which one was used to build stuff.
<cjwatson> It sure is relevant if one of them runs code correctly and the other doesn't.
<xnox> unless things FTBFS with wrong awk ofcourse.
<slangasek> I build-depend on awk exclusively for use of libawkpic.a
<cjwatson> Which has been known to happen.
<xnox> cjwatson, oh really =/ sigh
 * xnox assumes maintainers that declared " | awk" have tested other awk implementations.....
<cjwatson> However, mawk vs. gawk is not relevant to the question of main vs. universe, since both are in main.
<slangasek> I'm also working on a cross between awk and lua called skwa
<cjwatson> So if it's resolved correctly today it should still be resolved correctly after no-follow-build-depends.
<xnox> slangasek, nice, does it have guile bindings?
<slangasek> xnox: no, my interpreter is guileless
#ubuntu-release 2016-03-30
<mwhudson> um i'm confused
<mwhudson> i uploaded golang-1.6_1.6-0ubuntu3_source.changes a while ago but it seems to have disappeared
<mwhudson> about 25 mins ago i think
<slangasek> mwhudson: I see one in the unapproved queue that arrived 9 minutes after your last comment
<mwhudson> slangasek: yes, that's the one that arrived when i just gave up waiting and tried again :/
<slangasek> ok
<mwhudson> slangasek: should the bot that auto accepts non-seeded uploads still be running?
<slangasek> mwhudson: yes, it should
<mwhudson> ah there it is
<stgraber> golang doesn't get auto-accepted as it's in the supported seed
<stgraber> I manually reviewed it
<stgraber> slangasek: if you have a minute, can you review that lxc upload?
<slangasek> stgraber: yeah... and I guess you just accepted squid3, which is buggy
<slangasek> queue needs proper locking. :P
<stgraber> there a bunch of things the LP queue implementation needs before locking :)
<stgraber> *are
<mwhudson> stgraber: oh ok
<mwhudson> stgraber: thanks
<stgraber> slangasek: I'm taking a look at maas
<slangasek> stgraber: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691/comments/26
<ubot5`> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Critical,Fix committed]
<stgraber> slangasek: shouldn't the new squid package preinst also nuke the old /etc/init.d/squid3 as it does the upstart job?
<slangasek> stgraber: yes, it probably should
<slangasek> but it doesn't, so that upload is buggy
<slangasek> stgraber: alright, this lxc upload doesn't look like something that wants me to do a line-by-line review on it.  Is this bugfix only? what upstream testing has been done?
<stgraber> slangasek: bugfix only ran through all of adt upstream as we do for every commit, has been in our ppa (as a git snapshot) for a few days
<stgraber> and yeah, those rcs are bugfix only
<slangasek> stgraber: ok, approved on the grounds that there are no /obvious/ bugs
<stgraber> yeah, that's been the case for the past 13 rcs, hopefully we'll soon be done catching the non-obvious ones :)
<stgraber> slangasek: ^ revert of previous upload + added conffile removal for /etc/init.d/squid3
<slangasek> stgraber: dpkg-maintscript-helper has bits that are supposed to be called from other scripts besides the preinst; see the postinst and postrm
<slangasek> ...which is a lot easier to keep track of if the maintainer were using .maintscript instead of trying to do this by hand
<stgraber> wow, wtf, that's not going to be fragile at all
<stgraber> grep tells me I've got the same number of those as there was for squid3.conf, that's about as much testing as this got
<slangasek> heh
<jamespage> hi release team - for some reason I thought I had already raised a FFe for the next Ceph stable release runup for 16.04
<jamespage> https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1563714
<ubot5`> Launchpad bug 1563714 in ceph (Ubuntu) "[FFe] Ceph Jewel stable release" [Undecided,New]
<jamespage> apparently not so here it is....
<rtg> infinity, pitti approved the FFE in bug #1558535. Could you also accept linux-snapdragon (and -meta) in the NEW queue ?
<ubot5`> bug 1558535 in Ubuntu "FFE: linux-snapdragon" [Undecided,Triaged] https://launchpad.net/bugs/1558535
<doko> rtg, done
<rtg> doko, thanks
<doko> cjwatson, infinity: what can we do about the migration of gcc-5-cross-ports / gcc-defaults-ports. gcc-5-cross-ports isn't mentioned in update_excuses at all
<cjwatson> will have to leave that question to somebody else, sorry
<stokachu> doko: mind rejecting conjure, i need to update it from the results around the juju discussions
<doko> stokachu, done
<stokachu> doko: thanks man
<infinity> doko: Did you review that new kernel you accepted at all?
<doko> infinity, only from a packaging point of view
<infinity> doko: A license review tends to be a good thing on BSP kernels like that.
<infinity> (it's not all upstream code from Linus's tree)
 * infinity grabs it to do a quick once-over.
<infinity> rtg: Alright, did a post-accept license review of linux-snapdragon, all looks sane.
<teward> infinity: mind if I poke/bother you about nginx for a bit, off-channel in PM, surrounding FinalFreeze?
<teward> s/surrounding/regarding/
<xnox> i wonder how bad is it that germinate says
<xnox> ? Missing source package: golang (for golang-github-gosexy-gettext-dev)
<xnox> ? Missing source package: golang (for golang-dbus-dev)
<xnox> ? Missing source package: golang (for golang-github-coreos-go-systemd-dev)
<xnox> ? Missing source package: golang (for golang-github-pborman-uuid-dev)
<xnox> ? Missing source package: golang (for golang-gopkg-tomb.v2-dev)
<xnox> ? Missing source package: golang (for golang-github-gorilla-mux-dev)
<infinity> xnox: Those should all be rebuilt against golang-1.6
<infinity> If we're about to start enforcing Built-Using.
<xnox> ah
<xnox> so this is legit =)
<infinity> Oh.  This is also broken. :(
 * xnox is like surely golang is not gone
<infinity> mwhudson: I found some lolz.
<infinity> (base)adconrad@nosferatu:/var/lib/apt/lists$ grep '^Built-Using: golang ' *Packages | wc -l
<infinity> 357
<infinity> (base)adconrad@nosferatu:/var/lib/apt/lists$ grep '^Built-Using: golang-1.6 ' *Packages | wc -l
<infinity> 0
<infinity> (base)adconrad@nosferatu:/var/lib/apt/lists$ grep '^Built-Using: golang-defaults ' *Packages | wc -l
<infinity> 12
<infinity> mwhudson: Note that last one.  I'm guessing there's something that does a Package->Source resolution for "golang-go" and fills in the wrong bits, when it should actually be hunting down the compiler used (golang-1.6 or gccgo-6)
<infinity> xnox: Anyhow, rebuilding all of those would probably turn "golang" into "golang-defaults" which, for the purpose of component-mismatches, will DTRT.  It's less ideal for actually tracking static compiling, though, and should be as above. :P
<cjwatson> xnox,infinity: incidentally, per our conversation the other day, I realised that we also need to check for cases where sources in main b-d on virtual packages without a preferred real alternative, since those could end up being resolved differently
<doko> does openstack still has a freeze exception?
<infinity> yes.
<infinity> doko: ^
<doko> ta
<teward> infinity: any chance you can review nginx (bug #1563393) for a freeze exception?  We're in the home stretch - keeping us as close to what upstream has for 1.10.x is still the goal.  which also reminds me, do you have any issues with me bouncing a couple of questions off you regarding nginx as we approach the final stretches of development?  (I'm keeping an eye on that FinalFreeze date, hence the need for a discussion)
<ubot5`> bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,New] https://launchpad.net/bugs/1563393
<teward> the discussion is more important than ^ that getting a review today, though
<infinity> teward: Discuss away.  I'm only doing IRC in small batches while I try to ignore blinky things to get other work done, but I'll get to you.
<teward> infinity: OK, the discussion has to occur off-channel, though, mind a PM for that?
<teward> given the info being shared
<teward> (E:NotForChannel)
<mwhudson> infinity: ah haha
<mwhudson> infinity: file a bug?
<infinity> mwhudson: Is that not what I did, via the IRC interface? :P
<teward> heh
<slangasek> mwhudson/api/v1/filebug
<slangasek> (Internet RESTful Chat)
<mwhudson> heh
<mwhudson> i wonder what package the bug should be against...
<infinity> mwhudson: Guessing dh-golang is where the magic happens.
<infinity> mwhudson: And it probably just needs to dereference paths before doing the file->package->source resolution.
<infinity> (Assuming it's checking the owner of /usr/bin/go and such)
<doko> wondering if mozc should be accepted ... we still have a very old version ...
<doko> https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1547816
<ubot5`> Launchpad bug 1547816 in mozc (Debian) "Merge mozc (2.17.2116.102+gitfd0f5b34+dfsg-1) from Debian unstable (main)" [Unknown,New]
<mwhudson> infinity: got an example of a package that has broken built-using?
<mwhudson> uh i guess lxd probably
<mwhudson> yeah
<rtg> infinity, thanks, re: linux-snapdragon
#ubuntu-release 2016-03-31
<bluesabre> Please approve the above blueman upload. Fixes a crash on first login for systems without bluetooth
<cyphermox> bluesabre: thanks! :)
<bluesabre> cyphermox: np, glad to be able to help with some of these things :)
<jamespage> hey arges - could we get the keystone upload associated with bug 1559935 accepted into wily-proposed alongside the nova update pls ?
<ubot5`> bug 1559935 in keystone (Ubuntu Wily) "[SRU] nova 12.0.2, keystone 8.1.0" [Medium,Triaged] https://launchpad.net/bugs/1559935
<arges> jamespage: sure
<arges> jamespage: didn't see that yesterday as I usually try to keep those together
<xnox> infinity, i think my s390-zfcp and s390-dasd uploads should have been held in the queue, instead of auto-accepted. They are priority-standard d-i things.
<xnox> and thus totally affect images =)
<cyphermox> flexiondotorg: do MATE installs have software-center or gnome-software? it's not immediately obvious in the seed? if it's gnome-software, you may want to update your slideshow
<teward> any chance I can get https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1563393 reviewed for a freeze exception approval?
<ubot5`> Launchpad bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed]
<stokachu> rbasak: ping
<rbasak> Skuggen: pong
<rbasak> Sorry
<rbasak> stokachu: pong
<stokachu> rbasak: hey so we've finish the juju ffe for 2.0 here: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913
<ubot5`> Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed]
<stokachu> and we have packages uploaded for conjure, bigdata, just needing an archive admin to review
<rbasak> I have NFI what is going on.
<stokachu> anyone you know of that has some time to get these pushed forward
<stokachu> heh
<rbasak> Are all the Juju-related FFEs approved?
<stokachu> ok
<stokachu> well we're trying to get the FFe's approved
<rbasak> I edited the description in bug 1545913 to link to them.
<rbasak> Well, you can't really upload and ask for AA approval without FFEs approved.
<stokachu> feedback was given by security team and those were incorporated
<stokachu> my packages aren't installed by default and are new so they didn't  need FFes
<stokachu> juju 2 is the one that needs the FFe approval
<rbasak> IMHO, all of these packages need to be considered for FFe as a whole.
<rbasak> infinity: ^
<rbasak> I summarised in the description of the main Juju FFe bug 1545913.
<ubot5`> bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] https://launchpad.net/bugs/1545913
<rbasak> Going in uncoordinated is crazy, and giving half the release team half the information isn't helpful either.
<stokachu> doing best i can with what ive got
<rbasak> Sure, nothing against your work.
<stokachu> i think that FFe summarizes everything though
<infinity> xnox: Ahh, hrm.  seeded-in-ubuntu (which is what drives the bot) doesn't know about udebs.
<jcastro> I am in the same boat as stokachu with the accompanying charm-tools
<xnox> infinity, brilliant!
<rbasak> The lack of coordination suggests that we're not ready for an FFe to me though.
<stokachu> rbasak: what else is missing from that FFe bug though?
<stokachu> i see the links to the packaging in the description and what has been done in response to the upgrade path
<infinity> rbasak: I've handed off juju2 to slangasek, cause he was super keen on joining the discussion.
<stokachu> ive got packages from juju-qa team uploaded to my ppa for review as well
<slangasek> <eyebrow>
<rbasak> slangasek: there just seem to be a growing number of packages impacted and every few days I learn of more.
<rbasak> I linked all the known ones in the bug.
<rbasak> There's also MAAS, but that's described in the bug description already though I don't see a bug on it.
<slangasek> rbasak: thanks
<rbasak> slangasek: there's also the complication that Juju 2.0 requires mongodb 2.6 and 3.2 to work, but won't have a dependency on those packages because Juju installs them manually. On the server side only, though.
<rbasak> But, AIUI, Juju 2.0 beta3 will be unusable to deploy Xenial until those are in.
<slangasek> rbasak: "until those are in" - I haven't seen any upload in NEW for this?
<rbasak> slangasek: they're blocked on my review feedback.
<slangasek> ok
<rbasak> slangasek: I'm interested in your opinion on some of that actually. https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557852/comments/6
<ubot5`> Launchpad bug 1557852 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb3.2 in xenial, wily, and trusty" [Wishlist,Incomplete]
<jamespage> bug 1546776 for all of those NEW packages
<ubot5`> bug 1546776 in charm-tools (Ubuntu) "[FFe] charm-tools 2.0" [Undecided,Triaged] https://launchpad.net/bugs/1546776
<bdmurray> any guesses on why the walinuxagent diff is using 2.1.2-0ubuntu1~14.04.2? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<infinity> bdmurray: Because LP isn't smart.
<infinity> bdmurray: Just diff by hand.
<infinity> 2.1.2-0ubuntu1~14.04.2 was in proposed and then deleted, and LP will forever consider it the "last upload" now, because of the higher version.
<bdmurray> okay, I didn't see 2.1.2 for Trusty anywhere hence the confusion
<flocculant> cyphermox: what's the current state on upgrading from 14.04?
<cyphermox> flocculant: very close to fixed
<flocculant> cyphermox: nice one :)
<cyphermox> I know exactly what fails, I'm just figuring out the correct way to fix it
<flocculant> even better :p
<flocculant> I did see the upgrade getting compix removed - which was good - I know we don't have that :)
<cyphermox> flocculant: well, the compiz crash I think was because of an issue in dbus
<flocculant> yea - wouldn't know, I just know that compiz wouldn't affect xubuntu upgrade failing :)
<cyphermox> the dbus-daemon-launch-helper lost its setuid bit when extracting, and the postinst wouldn't fix it until very late
<cyphermox> I still haven't managed to successfully build a source tarball for ubuntu-release-upgrader though, I keep getting incoherent hash sums from the archive
<infinity> cyphermox: Moving that dpkg-statoverride from postinst to preinst (or, keeping it in both) would likely do the trick?
<cyphermox> infinity: not according to changelog
<infinity> cyphermox: Pointer?
<cyphermox> - preinst: partially revert change from 1.9.4-2. It seems that the
<cyphermox>       preinst is too late to add a useful dpkg-statoverride entry: dpkg has
<cyphermox>       already loaded the statoverride database by this point, and if we add
<cyphermox>       the entry in the preinst, dpkg-statoverride won't run and have
<cyphermox>       its --update side-effect in the postinst. (Closes: #773107, #773838)
<cyphermox> that was in 1.9.6-1
<infinity> Huh.  That seems suboptimal.
<cyphermox> yeah
<cyphermox> so my also suboptimal solution for now was in u-r-u
<cyphermox> except I can't seem to build it ;)
<infinity> I'm less than pleased with it being hacked around in u-r-u. :/
<cyphermox> suggestions?
<cyphermox> this may be a dpkg bug if statoverride isn't happening at the right time
<cyphermox> maybe for our interest preinst would be sufficient
<infinity> It's definitely a dpkg bug, but I can understand exactly why.
<infinity> statoverride should be loaded/parsed on each unpack, to get the expected behaviour, but it's obviously easier and more efficient to load it once at startup.
 * infinity ponders.
<infinity> A purely dpkg/deb workaround would be to divert --copy the helper binary in preinst and put it back in postinst.  But that only works if the old helper works with the newly-unpacked dbus.
<infinity> Or a more gross hack would be to divert it and replace it with a shell script that does a chmod && exec helper.real. :P
<infinity> (And then undo that in postinst)
<infinity> Obviously, version-guarded, so we only do that insanity on upgrade to xenial.
<infinity> Oh, but the helper is called by users, hence suid, so shell script no workie.
<infinity> Derp.
<infinity> Derpity derp.
<infinity> cyphermox: I'm not against throwing the statoverride in u-r-u (I assume that was the intended hack) as a "fix it today" plan, but if we can fix the apt-get dist-upgrade scenario too, that would be nice.
<infinity> I'll think about it some more.
<cyphermox> I kind of expected the issue with u-r-u to be that it unpacks nearly everything and then runs all the postinsts later, in a very different order than dist-upgrade
<cyphermox> or at least, different enough that it's annoying
<infinity> Oh, as in maybe people don't hit this bug at all with apt-get?
<infinity> That would be a pleasant discovery.
<cyphermox> I don't think they do, but I'll re-test
<rick_h_> slangasek: howdy, is there a list of the team's concerns with the juju packages I can go through and make calls on if we can pull/reduce risk there? I'm looking for the list of things to address in #1545913 that I can either put the team on to remove any remaining blocks.
<stgraber> rick_h_: so the bug now claims that we will have a Juju 2.0 final ready before 16.04 ships, is that correct? That's now what I was told before so that kinda surprises me.
<rick_h_> stgraber: yes, we're cutting an RC1 in the next week and solidifying to have juju 2.0 available to users on release day for 16.04.
<rick_h_> stgraber: juju 2.0 has to go with maas 2.0, lxd 2.0 as it's built on top of both of those
<stgraber> both maas and lxd have betas or rcs in the archive right now, so presumably you're not blocked on those
<rick_h_> stgraber: no, we're not blocked on that at this time. We didn't put our alpha in because there was some confusion in the 'best path' to get juju2 in and allow side by side installs in trusty/xenial.
<rick_h_> stgraber: we've engaged with folks on your team to iron out that upgrade/side by side install process as we try to get juju 2.0 in
<rick_h_> stgraber: and my understanding is the team has addressed that path and made changes to the packages to make sure it works smoothly
<stgraber> so if I read the FFe right, you're basically saying that all existing juju users will be broken by the upgrade as juju will now point to juju2 and juju2 can't talk to juju1
<rick_h_> stgraber: no, when a user upgrades they'll keep juju 1, juju 2 will be installed along side, and juju will be update-alternatives pointed to juju 2
<rick_h_> stgraber: it's all supported in update-alternatives and juju 2 is the higher priority
<rick_h_> stgraber: so I don't think they're 'broken'
<rick_h_> stgraber: that was some of the good feedback my team got and addressed
<stgraber> """
<stgraber> Users upgrading from trusty will find their juju version updated. The current juju-core package will be provided as juju-1.25. Update-alternatives will provide support for toggling /usr/bin/juju between juju-1.25 and juju-2.0 binaries.
<stgraber> """
<stgraber> I read this as, "juju" will point to version 2 after upgrade.
<stgraber> and user can change it back to version 1 with update-alternatives
<rick_h_> stgraber: yes, it's the higher priority.
<stgraber> ok, so someone using the juju command will be broken then
<stgraber> or does juju2 somehow know to call juju1 instead in such case
<stgraber> oh, I meant to quote:
<stgraber> """
<stgraber> Upgrading Trusty/Wily/old Xenial:
<stgraber> Already installed juju 1.X, upgraded to latest 1.25.4, 2.0 also installed and is the default juju, update-alternatives used to switch between the two.
<stgraber> """
<rick_h_> stgraber: what we've talked about doing in response to this is having juju 2.0 detect that you have a juju 1 config directory w/o a juju 2 directory and messaging the update-alternatives command
<rick_h_> stgraber: would that be an ok path? Or I can investigate what impact having juju 1 the higher prority would be?
<stgraber> but juju doesn't run as root so it can't call update-alternatives and changing symlinks under the user like that isn't too good.
<rick_h_> stgraber: well we can give the user the copy/paste command to swich if they desire?
<stgraber> You could probably have your postinst set the alternative to juju1 if it's installed though but then users will still be confused, just the other way around.
<rick_h_> stgraber: or we can go the juju 1 higher priority
<stgraber> I think the best as far as user experience goes would be:
<stgraber>  - If juju1 is detected on installation of juju2, set the alternative to juju1
<stgraber>  - Patch juju1 to show a one-time message to the user saying something along the lines of "we've noticed you were using juju1, juju1 is incompatible with juju2, when you're ready to switch, run: sudo update-alternatives --config juju"
<stgraber> or something along those lines
<rick_h_> when would that message show to a juju 1 user?
<stgraber> so don't break folks on upgrade, don't have an unprivileged process mess with systemd-wide settings but still make it easy for the user to figure out how to switch
 * rick_h_ is thinking of the preferred injection point for a thing
<stgraber> first run of the juju command I'd guess, then touch a stamp file and don't show it again
<rick_h_> stgraber: ok
<rick_h_> stgraber: is that the only remaining concern or are there other ones we can/should address?
<stgraber> not quite
<stgraber> I see you list 3 packages that are needed for juju, juju-mongodb3.2, juju-mongodb2.6 and juju-mongo-tools3.2
<stgraber> none of which are in the archive yet and I believe all of which received some kind of negative review feedback
<rick_h_> stgraber: yes, so the current juju-mongodb in trusty/xenial to date is an old version that is out of support from mongodb. We'd like to get a supported mongodb in and have juju use that.
<stgraber> before we really consider the juju FFe, we need to have any required dependencies in the archive and if needed, promoted to main. Then we can see how much time we have left after that and consider the risks that come with the new juju.
<rick_h_> stgraber: the team's writing up the reply to that negative feedback and filling in the details on the decisions there.
<rick_h_> stgraber: so juju can work with the mongodb that's there currently, but it's less than ideal as it's not supported upstream any more.
<stgraber> I also see in one of those linked bugs a mention that juju 2.0 will be 64-bit only, yet I'm not seeing any mention of that in the Juju FFe
<rick_h_> stgraber: so we feel we can go whichever path forward your team would prefer.
<stgraber> this seems like a rather big change that should have been mentioned with details on your upgrade path for 32bit users going to 16.04 (getting them to juju1 only with some kind of notification I guess)
<rick_h_> stgraber: the client tools build on all architectures. THe mongodb case is juju remote's server which is not a package in qustion
<stgraber> ok
<rick_h_> stgraber: so this is something that's a bit of a line in that the juju client does not need mongodb, so it's all archs including 32bit
<stgraber> ok, so those 3 packages are only needed for the juju server
<stgraber> might be worth clarifying in the FFe
<rick_h_> stgraber: sure thing
<infinity> stgraber: No need for juju2 to mangle the alternative conditionally, if juju1 is the higher priority it "just works" for upgrades.
<infinity> (Well, assuming there's also a plan that keeps both packages around.... The last upload I saw was replacing 1 with 2...)
<stgraber> infinity: true but what happens if someone apt-get install juju1 after the fact?
<infinity> stgraber: Then juju1 would take priority.  *shrug*
<rick_h_> infinity: right now we will have juju 1 until trusty EOL's and then we'll remove it from xenial
<infinity> rick_h_: Err, no you won't.
<infinity> rick_h_: We don't remove things from xenial.
<infinity> Not after it's released.
<rick_h_> infinity: no? my understanding is that since 1.25 is in universe it can be removed?
<infinity> Your understanding was incorrect.
<stgraber> it's impossible to remove a package from the release pocket
<stgraber> you can SRU an empty one though
<rick_h_> stgraber: infinity ok, folks are clarifying me that the package is still there but we can say "it's no longer supported' which is what I was asking them about
<infinity> We could, in theory, 0-day SRU it to xenial-updates and not actually ship a copy in the release pocket at all.
<rick_h_> my apologies for the confusion there
<infinity> But that would take some fun coordination.
<stgraber> but then your users may be a bit surprised that a package in main with a 5 years support commitment from Canonical is removed
<rick_h_> stgraber: infinity we have a support window that's documented for 1.25 until trusty EOL but it's support specific
<infinity> rick_h_: So, how does the upgrade get people both versions?
<rick_h_> infinity: that's in the juju ffe #1545913 under upgrades and we've tested this as the feedback
<rick_h_> we got around those issues
<rick_h_> infinity: so there's some metapackage foo that makes it 'just work' and tests well
<infinity> rick_h_: The upgrade scenario I saw assume the metapackage is installed.
<infinity> rick_h_: Users with juju-core installed get no upgrade, then?
<rick_h_> infinity: yes, all users have the juju metapackage currently
<infinity> That's a bold statement.
<infinity> There's nothing requiring them to.
<rick_h_> infinity: true, but all of our documentation and practices going back pre-trusty has the juju metapackage.
<infinity> Also, that package was never actually a metapackage (ie: in section: metapackages) which means its deps are marked auto-installed.
<rick_h_> infinity: worst case, if they don't have the metapackage they end up with just juju 1 they were using, and have the option of installing juju2 by installing the metapackage or the juju-2 package
<infinity> So, assuming they have it installed "apt-get dist-upgrade && apt-get autoremove" will remove juju-core.
<infinity> And we're enabling autoremove by default.
<infinity> In unattended-upgrades.
<infinity> So, you still have a bit of a problem there.
<rick_h_> infinity: ok, that's good to know. We weren't aware.
<infinity> rick_h_: Of which part?  Your pastebin clearly shows juju-core as an autoremove candidate.
<mgz> infinity: I have slightly changed the packaging since then, but am interested if there's a neat way of avoiding that problem
<rick_h_> infinity: that we either update the current trusty package and try to fix the section metapackages?
<rick_h_> or something else?
<infinity> It's too late to fix it in trusty.
<infinity> You can't guarantee all users will be fully-upgraded to trusty-updates before upgrading.
<rick_h_> infinity: agreed, hoping that we might not be alone in this and there's a known path that makes it non-fugly for users?
<infinity> mgz: My best recommendation would be to have the metapackage depend on both until juju-core is EOL.
<infinity> Unfortunately, you can't write to the apt autoremove database while apt is running, so you can't fix it up in a maintainer script.
<mgz> infinity: okay, so, for instance, the initial version of the juju 2.0 source package can say, have juju depend on juju-2.0 and recommend juju-1.25 maybe?
<rick_h_> infinity: can it depend on both though as one is meant for main and one for universe?
 * infinity thinks a bit about how best to solve this.
<infinity> rick_h_: Oh, nope.  Not if the meta is in main.
<mgz> you can recommend into universe right?
<infinity> Nope.
<infinity> Only Suggests.
<infinity> Which might not be enough to pin it in, I can't recall the mechanics there.
<mgz> meph, which isn't enough to prevent the autoremove
<mgz> ...I think
<mgz> infinity: I'm open to cunning plans
<infinity> mgz: Suggests is enough to keep it in.
<mgz> infinity: okay, that is excellent. I can do that.
<infinity> http://paste.ubuntu.com/15570328/
<infinity> ^-- example/proof.
<mgz> infinity: thank you very much
<doko> infinity, did you find out more about glibc2.0 on s390x? If not, I'd like to upload a build which doesn't run the tests, so that we can get the package into the release pocket for the test rebuild
<infinity> mgz: And that's actually appropriate anyway, as a Suggests implies the need for juju1 for transition/upgrade purposes.  So, yay for that.
<mgz> yeah, it's great that it makes sense and actually does what we want :)
<rick_h_> stgraber: infinity ok, so we're adding a comment to the FFe on the 32bit question and moving to suggest, and making juju1 the higher update-alternatives priority.
<infinity> doko: Not yet, no.  But if you want to disable for a build, I can revert when I've found something.
<doko> ok
<rick_h_> stgraber: infinity are there other concerns/issues the team needs to address? If not, can I put those notes into the FFe that based on our conversation those are the conditions and upon meeting those it will be acceptable?
<infinity> doko: (Alternately, disable for a PPA build and make your test depend on that PPA, but I think a bunch of other stuff is also blocked on glib, like gtk...)
<doko> right
<infinity> rick_h_: To me, the key points are that juju2 be considered feature-complete and fully-functional by release, because that's the thing you're telling users is the Way and the Light, and that upgrade scenarios don't leave users busted on upgrade.
<rick_h_> infinity: understand, we're moving the one feature not complete behind a feature flag that is not enabled by default for release
<rick_h_> infinity: juju 2.0 is fully functional, our next release is RC1 with bugfixes from then on.
<infinity> rick_h_: I haven't reviewed the actual package yet, but apw had some concerns there too, like why is it shipping 250MB of binaries, much of which seem to be duplicated code? (could it be a single binary that switches on argv[0] and cut the install-size in 1/4?)
<rick_h_> mgz: do you know the background there? ^
<infinity> Given that there are powers that be that want to see juju eventually installed by default on every Ubuntu device, 250MB is pretty huge.
<infinity> Like, very huge.
<infinity> Guessing there may also be a lack of stripping.  A combination of argv-switching and stripping would help a lot. :P
<infinity> (If that 250MB is stripped, I'll be both surprised and even more annoyed at Go than before)
<rick_h_> infinity: mgz is pulling up the bug on this for reference. one sec
<mgz> infinity: see https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255/comments/8
<ubot5`> Launchpad bug 1200255 in golang (Ubuntu) "go get ... fails with SIGILL on armhf" [Undecided,Fix released]
<mgz> infinity: tldr, upstream golang doesn't support stripped binaries, things break when you do it
<stgraber> hmm, pretty sure mwhudson said it's all fine and supported now
<stgraber> except for binaries built with gccgo, those are still busted
<mgz> it may be something we've made progress on upstream, but it's not been tested by us
<mgz> I shall ask mwhudson later.
<infinity> Yeah, I've heard that was sorted, or at least there was a workaround where you could strip mostly, but leave a section intact.
<infinity> mgz: stripping aside, the 4 binaries that mostly link the same objects thing seems like it would be served better with one binary and 3 hardlinks and argv[0] switching.
<mgz> infinity: I'm open to filing a bug on that, but thought the way forward was more likely to be shared objects for go
<infinity> mgz: Sure, libraries would be wonderful, but we're not there yet.
<infinity> mgz: When most of your binaries are 90% shared static objects, though, the busybox approach makes some sense.
<rick_h_> infinity: so to my list you'd like us to add that we argv switch in there as a gate to get the acceptance?
<infinity> rick_h_: Well, reduce the package size considerably.  How that happens is an implementation detail, I'm just suggesting an option. :P
<infinity> rick_h_: Obviously, sorting out the stripping situation will also help a lot.  But even then, you'll still have 4 giant almost-identical binaries.
<infinity> Just slightly less giant.
<rick_h_> infinity: understand
<rick_h_> infinity: I'm working to get a list of things that are preventing this so I can get the team to address them and hopefully have a complete action plan
<rick_h_> infinity: to date I feel like we've gone back/forth and the lovely manager in me is wanting to get a plan in place
<infinity> rick_h_: Well, it's not helping that this is all landing very late and (frankly) the default answer from both the Release Team and the Tech Board (if escalated) should be "no".
<stgraber> rick_h_: would also be useful to have a section in that FFe which highlights how that mess happened in the first place and explaining how you intend to deal with pushing juju to the Ubuntu archive in future releases so that kind of situation doesn't happen again
<infinity> rick_h_: So, working towards a slightly less violent "no" is a good first step, but it may still warrant a sabdfling if we can't dot every i and cross every t.
<rick_h_> infinity: ok, I can add that section and the plan we've put together on our end.
<infinity> rick_h_: And I understand that there was a belief that the standing SRU exception would let this slide right in, but the SRU exception is predicated on intense regression testing and sane upgrade paths, so that certainly hadn't been met the last time I looked at this.
<rick_h_> infinity: understand, we had the mandate that there's not a current upgrade path from a juju1 environment to a juju2 one. However, that's the remote end vs the client that this is about.
<rick_h_> infinity: and I think that confused the issue a bit
<rick_h_> infinity: which is why the feedback from your end on the upgrades with the packages is <3 and I'm happier we did those updates
<infinity> rick_h_: Right, the client upgrade path is what's of concern for the distro.  ie: I can't upgrade my distro and break my client.
<infinity> rick_h_: The network upgrade path is something apt obviously can't fix, so that's up to good documentation of migration strategies for the server side.
<rick_h_> infinity: definitely
<rick_h_> infinity: stgraber so we'll process these items per https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913/comments/14
<ubot5`> Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed]
<rick_h_> infinity: stgraber if there are any other items to add to that list please let me know so I can make sure I'm aware and handling them
<stgraber> rick_h_: document your plan for the next ubuntu release on how you'll adapt your process so we don't end up in the same situation again
<rick_h_> stgraber: right +1
<stgraber> rick_h_: we really should have had juju2 alphas or something in xenial way before feature freeze, incremental changes and FFes are far easier for us to review and way easier to get
<stgraber> most of our other upstreams have figured it out and maas and lxd within Canonical also managed it, so surely Juju could have done it too
<rick_h_> stgraber: understand, I think this was a miscommunciation in that we had the feeling an alpha should not go in
<stgraber> if you intend for the final version to go in, an alpha can absolutely go in
<infinity> rick_h_: It's a development release, all bets are off.  The key is to have something decently final by release.
<rick_h_> stgraber: we've had packages and been delivering to stakeholders alphas and betas for months
<stgraber> rick_h_: right, just not in the Ubuntu archive, which is what matters to us :)
<rick_h_> infinity: yes, agree. We've got commercial engagments where my head's on the line so a final will be in for release
 * rick_h_ steps away for lunch and to assign folks to tasks
<infinity> rick_h_: Threat of decapitation isn't my ideal motivator, but whatever works for you.
 * rick_h_ tosses the obligatory "I'm rather attached to my head" joke
<stgraber> speaking of golang stuff, I don't suppose any archive admin is willing to look at those 3 golang-XYZ packages I uploaded back in December?
<stgraber> they are the only bits left (well, once promoted to main) which we'd need for LXD not to use any bundled sources, so that would make the security team happy (apparently)
<stgraber> it's not blocking us since we just use the bundled copies when we can't find the source in the archive but it's something we've been asked to do as part of being in main
<stgraber> a couple of those I uploaded before have since landed in Debian so I've synced them from there instead, but those 3 aren't in Debian and won't be before release (no ITP for them even)
<infinity> superm1: Why is fwupd arch:any?
<superm1> infinity: linux-any IIRC
<infinity> superm1: Oh, I see.  The intent is to someday extend it for non-EFI systems?
<superm1> it can support all sorts of firmware flashing types
<infinity> (Though, that doesn't seem to be the case right now)
<superm1> raspberrypi, DFU, colorhug
<infinity> Hrm.  Kay.
<superm1> of course the main one I care about is EFI, but i'm also hoping to get other interesting pieces of firmware pushed that route too
<infinity> GPGME needs this for proper building on i386, armhf, powerpc
<infinity> ifeq "$(DEB_BUILD_ARCH)" "i386"
<infinity>         export DEB_CFLAGS_MAINT_APPEND = -D_FILE_OFFSET_BITS=64
<infinity> superm1: Is "dpkg-architecture -qDEB_HOST_ARCH_BITS" what you're looking for?
<superm1> infinity: possibly
<infinity> superm1: Also, you've confused HOST and BUILD there.  HOST is the one you're building *for*, BUILD is the one you're building *on*.
<ginggs> is there anything wrong with just adding -D_FILE_OFFSET_BITS=64 for all arches?
<slangasek> mgz, rick_h_: yes, per mwhudson, stripping of go binaries is now supported; we should ASAP start stripping juju binaries to get the install size under control
<slangasek> ginggs: there is not, it's just superfluous on some archs
<ginggs> slangasek: thanks, i was pretty sure i've done that in a couple of my packages
<slangasek> so the usual approach for this is $(shell getconf LFS_CFLAGS)
<slangasek> but of course that's not cross-friendly, so ymmw
<slangasek> v
<superm1> infinity: dpkg-architecture -qDEB_HOST_ARCH_BITS should return 32 on the ones I was adding the flags?
<infinity> superm1: Yes.
<infinity> superm1: And many more, in the case of Debian.
<infinity> You probably also want -D_LARGEFILE_SOURCE
<infinity> And, as mentioned, it's not harmful to just unconditionally add both, even on 64-bit arches.
<infinity> But if you want to conditionalise it, -qDEB_HOST_ARCH_BITS is the way to go.
<superm1> ok thanks
<infinity> superm1: I look forward to your engagement with IBM (if they don't blackhole @dell.com) on making this work for PPC systems too. :)
<infinity> (They have live firmware updating tools, it would just need to be hooked in and prettified)
<infinity> superm1: Mostly sarcasm, FWIW.  But I might suggest they look at the project and contribute.
<superm1> Heh, well if they have specs that are open on this stuff they should definitely participate
<infinity> superm1: Their firmware updating (and firmware itself) are open, the problem they need to fix is sane distribution channels for their signed firmware images.
<infinity> superm1: If they can plug that all in reasonably, so there's no manual click-wrapping and shuffling of files, this would all be quite slick.
<infinity> superm1: I assume fwupd supports the concept of A-side/B-side/Commit somehow?
 * infinity puts it on his list of things to learn about $later.
<superm1> Anything is possible with the plugin architecture. Even if their stuff doesn't follow standards, it can fit into fwup-provider-ibm or something like that that does any crazy stuff
<infinity> superm1: Shiny.
<infinity> superm1: I'll bring it up with Jeremy Kerr when I have a spare few minutes.  I'd love to see the fwupd story improve on those machines, given the open nature of both the tools and the firmware.  It's a shame they haven't glued the last little bit together to make it stupid-proof.
<superm1> And LVFS is open to any OEM. If they would distribute their firmware images though that, it solves a lot of mess too
<superm1> Cool
<Beret> infinity, haha
<Beret> "Threat of decapitation isn't my ideal motivator, but whatever works for you."
<mwhudson> mgz: strip go pls
<mwhudson> mgz: not gccgo tho
<rick_h_> mwhudson: how confident are we on that? I'm concernede about sneaky issues that it might expose.
<infinity> mwhudson: golang vs gccgo, does dh_strip DTRT, or does one need to do conscious debian/rules hackery?
<infinity> mwhudson: (I assume you meant "strip binaries produced by golang, but not binaries produced by gccgo")
<mwhudson> rick_h_: the failures we've seen before are of the "process crashes instantly on startup"
<rick_h_> mwhudson: ok
<mwhudson> variety
<mwhudson> i can't see the scope for subtle breakage
<mwhudson> infinity: no, no smarts in dh_strip
<infinity> So some icky ifeq magic on dpkg -S $(readlink /usr/bin/go)?
<infinity> That might want dh_strip involvement. :P
<rick_h_> mgz: ^ for the bug
<mwhudson> yeah
<infinity> Can we tell by examining a binary if it's produced by one or the other?
<mwhudson> probably not stripping binaries linked to libgo.so.X is the right heuristic
<doko> one has a proper shared lib
<mwhudson> although there are some gccgo-compiled static things too
<doko> infinity, depends on libgoN
<mwhudson> (jujud, dockerinit)
<infinity> That seems odly backwards that a GCC-produced binary can't be stripped.
<mwhudson> i've been meaning to pester ian about this for ages
<doko> infinity, fix libbacktrace
<mwhudson> it would still seem better to get no tracebacks if there is no debug data
<infinity> doko: No thanks.  It was an observation, not a demand for work. ;)
<mwhudson> rather than fall over on startup
<slangasek> mwhudson: in the past, I thought stripped binaries would crash at the first use of go reflection, which is not necessarily at startup
<mwhudson> slangasek: don't think so?
<slangasek> mwhudson: hmm, well, at least in one iteration of the bug, it was the reflection info that was disappearing when stripping :)
<mwhudson> oh maybe you're right
<mwhudson> uhh
 * mwhudson is stripping gccgo binaries on his system and things are working
<rick_h_> mwhudson: yea, the big thing is that juju seems to push things a bit and making that change at this point seems potentially risky.
<slangasek> anyway, at this point we *ought* to be using golang consistently across all architectures in xenial, which means no reason to special-case in the packaging
<mwhudson> slangasek: except powerpc
<slangasek> rick_h_: whether or not it fails at startup, it should be the sort of breakage that's easy to regression-test
<slangasek> mwhudson: oh that old thing
<infinity> Yeah, except powerpc.  But the right answer is special-casing in dh_strip, not in individual packages.
<infinity> Just as we special-cased golang-go in a metapackage, not in package build-deps.
<infinity> Packages should be blissfully unaware of their toolchain.
<slangasek> mwhudson: apt-get install qemu-user-static; apt-get install juju-core:amd64; done
<slangasek> running amd64 go binaries under qemu-user-x86, should work GREAT
<mwhudson> slangasek: i bet juju tickles no bugs in qemu-user-static at all
<slangasek> mwhudson: last time I tried qemu-user-x86, it didn't do nptl
<slangasek> so
<infinity> qemu-user-static is notoriously crap at all things threaded.  Good thing Go doesn't ever do anything in paralle.
<infinity> l
<mwhudson> rick_h_: i can understand the reticence, but i reallllllyyyyy think the scope for subtle breakage is v minro
<infinity> Surely there's a testsuite we can exercise to see if it breaks.
<rick_h_> mwhudson: ok, I'm not familiar enough to help but just wanted to make sure.
<rick_h_> infinity: yes, but if it's subtle there's risk it's something that would be provider specific/etc that scares me.
<infinity> If the entire juju testsuite is "run the binary to see if it crashes", we have much bigger problems than stripping. :P
<rick_h_> lol
<mwhudson> oh good juju doesn't build with gccgo on my system?
<mwhudson> juju tip
<mwhudson> i'm on wily thouhg
<stgraber> +1 on having dh_strip DTRT
<infinity> The 2.0 test PPA was only x86 too.
<stgraber> FWIW, lxd doesn't override dh_strip, so I guess it means it's getting called and AFAICT our powerpc binary still works :)
<infinity> stgraber: Do you have stripping logic in lxd you'd like to move to dh_strip? :)
<infinity> Ahh.
<infinity> Neat.
<stgraber> that or dh_strip is skipping all go binaries which would be kinda bad :)
<infinity> stgraber: Are your binaries a bazillion whosibytes?
<infinity> stgraber: Cause if not, they're probably stripped.
<stgraber> we have a powerpc box I use quite a bit for testing and to build various images, haven't had any problem on it
<infinity> stgraber: powerpc or ppc64el?
<infinity> I mean, I know you know the difference, but... Why would you have the former?
<stgraber> we've got both
<infinity> (says the man with several powerpc boxes...)
<stgraber> because powerpc keeps breaking and I wanted to be able to test things before they break :)
<infinity> Heh.  Fair.
<infinity> Do you use this reflection thingee vorlon speaks of?
<stgraber> /usr/bin/lxd: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=923cbfc4794ecc86c35469418558d3146718e68c, stripped
<stgraber> yup, we use reflection in a few code paths
<infinity> mwhudson: So, maybe it all works now?  Somehow?
<stgraber> our biggest user of reflect appears to be our /dev/lxd interface, let me poke at it a bit to make sure it works as expected
<mwhudson> infinity: maybe!
<mwhudson> infinity: i'll ask upstream
<infinity> Can the next new language we adopt have THREE differently-broken toolchains?  Two isn't enough hassle.
<mwhudson> infinity: i'll use common lisp for my next r
<mwhudson> infinity: i'll use common lisp for my next project
<mwhudson> ah stripping gccgo-built juju still breaks
<slangasek> mwhudson: I thought the traditional exit strategy was haskell
<stgraber> root@test:~# curl --unix-socket /dev/lxd/sock http://a/1.0/config
<stgraber> ["/1.0/config/user.this-works"]
<stgraber> this particular code path definitely runs through reflect.Indirect and a bunch of similar fun code
<mwhudson> slangasek: but that only has one toolchain? (that anyone actually uses)
<infinity> Curious.  So something different breaks for juju.  Good(?) to know.
<slangasek> right :)
<stgraber> as far as numbers, unstripped lxd is 21M, stripped lxd is 13M. That's the golang numbers.
<stgraber> gccgo is smaller at just 6.2MB stripped
<infinity> mwhudson: I'm kinda curious what breaks for juju and why it doesn't for lxd, but not curious enough to skip lunch any longer.
 * infinity lunches.
<mwhudson> yeah, me too, except for the time of day
<infinity> mwhudson: Although, stgraber's builds are on up-to-date xenial, you implied you were wilyish.
<rick_h_> mwhudson: all good, it's good to know we should look into it and explore it on our end
<rick_h_> mwhudson: everyone still thought it was a 'thou shalt not do'
<mwhudson> infinity: i was trying juju in a xenial lxd
<mwhudson> rick_h_: one myth at a time :-)
<infinity> There was an LP bug about this a long time back that implied a less aggressive strip would work too.
<infinity> Maybe that could be built into dh_strip, if I can figure out how to identify that a binary is Go.
<infinity> And if I can remember the bug report. :P
<infinity> But yes, lunch.  Hungry, hungry hippo.
<slangasek> rharper: so I'm taking a closer look at squid3 now; I do not like what I am seeing, and I'm not sure how much of it is Debian vs. Ubuntu delta.  Do you know why we have extensive maintainer scripts for both the squid3 and squid binary packages?  Do you know why the squid3 dummy package declares a pre-depends on squid instead of depends?  Are you the right person for me to be pestering about these
<slangasek>  things?
<rharper> slangasek: rbasak did the merge; so he's most intimate with the details
<slangasek> ok
<rharper> slangasek: if you put the questions in the FFE bug, rbasak will see them and can reply as he sees; I'll actively research and help until he's online tomorrow
<slangasek> rharper: yeah, if you don't have the answers to hand, given the tz difference this is going to end up being a matter of me taking a machete to the packaging
<slangasek> thanks, though :)
<rharper> slangasek: my gut feeling is that most of the package stuff is from debian as our goal has been to drop delta
<slangasek> yeah, it is
<slangasek> there's some delta to each of the scripts from Ubuntu, but the fact that there are two sets of maintainer scripts is Debian-induced braindamage
<rharper> yuck
<mwhudson> AND the package uses cdbs!
<rharper> and folks ask why we've not merged in so long
<slangasek> yes
<slangasek> and now is the time to fix up these maintainer scripts, *before* they dump a pile of orphaned config files onto users' systems in the LTS
<doko> promoted libdata-alias-perl, blocking lintian migration
<infinity> doko: It was already promoted once (by you).  I guess someone demoted it again? :P
<doko> yeah, not me ...
<doko> foundations was also subscribed
<rbasak> slangasek: the Debian situation isn't great. The Ubuntu delta isn't that large.
<slangasek> doko: is that a new dep, then?
<infinity> Oh well.  My kingdom for auditing, so I can see who demotes without checking proposed.
<rbasak> slangasek: it's complicated by the fact that Ubuntu carried a delta from Trusty from squid -> squid3, and Debian is going the other way now.
<doko> how much do we care about mariadb-10.0 ?
<slangasek> rbasak: yeah, I'm seeing that.  Nothing I fault you for as part of the merge, but I'm reaching for increasingly large bladed weapons now ;)
<rbasak> So there are various use cases such as Trusty -> apt-get install squid -> do-release-upgrade to Xenial being different from Trusty -> apt-get install squid3 -> do-release-upgrade to Xenial.
<infinity> slangasek: Was a new dep, yeah: https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082
<ubot5`> Launchpad bug 1564082 in libdata-alias-perl (Ubuntu) "[MIR] libdata-alias-perl" [Undecided,Fix released]
<slangasek> k
<rbasak> Stuff breaks in strange ways because the dpkg-maintscript-helper calls are essentially a hack.
<rbasak> The duplicate calls from both squid and squid3 maintainer scripts work around it.
<rbasak> I'm not sure if that's what Debian intended, but it seems to work for us.
<slangasek> infinity: without checking -proposed> well, I *did* point out that having one c-m report would be cleaner, but I got voted down.  I didn't do the demotion though :)
<doko> slangasek, https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082
<rbasak> (hack as in more of a hack than usual, since sometimes the prerm in squid might never run, etc)
<rbasak> slangasek: if it helps, https://git.launchpad.net/~racb/ubuntu/+source/squid3/log/?h=merge breaks down the current Ubuntu delta (my merge)
<slangasek> rbasak: at this point I assume the last time the squid3 maintainer looked at a package was 2003
<rbasak> slangasek: upstream have been quite involved recently, and he doesn't have much packaging experience I don't think.
<doko> rbasak, are all those block-proposed tags really helpful? these prevent testing by a much larger community
<rbasak> slangasek: his sponsor seems to be less involved nowadays, AFAICT.
<infinity> slangasek: Other than the Debian packaging being insane, there's the added bonus that we and Debian were inverted on package names for a while, which makes it even more fun.
<rbasak> doko: mysql-5.7 block-proposed was to prevent breaking mythtv during beta week. I guess that can be removed now, though I think there's still a dep8 fix to upload so it wouldn't migrate yet anyway.
<slangasek> infinity: I know, I know
<infinity> So, crazy on top of crazy.
<infinity> With a side of delicious crazy.
<rbasak> doko: squid's tag was suggested to me I think. I'd be fine to remove that now, but no need to break users until the current known bug is fixed I think.
<doko> k, thanks
<slangasek> oh good, adduser in the preinst without a pre-dep
<slangasek> not like the maintainer had never heard of a pre-dep, he just apparently has no idea what they're fore
<slangasek> -e
<slangasek>         adduser --system --home /var/spool/squid --group proxy
<slangasek>         chsh -s /bin/sh proxy
<slangasek> >_<
<teward> infinity: any chance you or someone else on the release team can review the nginx freeze exception request bug before tuesday?  happy to give specifics as to why i say tuesday off-channel but...
<slangasek> rbasak, rharper: looks like the upgrade also doesn't migrate /var/spool/squid3 to /var/spool/squid; do you know if there was a specific reason this wasn't done?
<rharper> slangasek: no, guessing it was missed;  I assume we want to move all squid3 -> squid where ever ?
<rharper> slangasek: rbasak may know of a specific case; but I;m not aware of one
<slangasek> rharper: well, the maintainer talks in NEWS.Debian about it not being automatically moved, which seems strange to me
<rharper> maybe they didn't want to test it out
<doko> afk now
<mwhudson> slangasek, infinity: https://groups.google.com/d/msg/gofrontend-dev/WAl16EmuxyE/WXktcXJ8CAAJ re gccgo stripping
<mwhudson> so it's not reflection per say, but other introspectiony thing
<slangasek> ah, k
<slangasek> superm1: is there an FFe bug for gnupg2 2.11-6ubuntu1 (not listed in the changelog)?
<doko> slangasek, I discussed this today with him, including the MIR report for fwupd
<slangasek> doko: what does that mean, you discussed it?  I don't see an FFe bug
<stgraber> that lxd upload should be trivial to review ^ it's just using the now promoted archive copy of go-colorable instead the embedded copy
<slangasek> ah, now I get to the unnoticed bit where we're both removing and migrating /etc/init.d/squid3, heh ;)
<superm1> slangasek: no an FFe bug was not created, based on the conversation that happened in -devel and that MIR bug I was under the impression it wouldn't be necessary
<superm1> if it is, I can file one now
<doko> slangasek, the MIR issue is https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1536871, the discussion was today on #ubuntu-devel, and the update fixed an issue in gpgme1.0 which was already in the release pocket
<ubot5`> Launchpad bug 1536871 in npth (Ubuntu) "[MIR] fwupd" [Undecided,Fix released]
<slangasek> superm1: what MIR bug are you referring to?
<slangasek> ok
<slangasek> doko: none of which excuses bypassing the release team and FFe review
<doko> the gnupg1.0 issue is LP: #1564234
<ubot5`> Launchpad bug 1564234 in gnupg2 (Ubuntu) "gpgme1.0 doesn't work properly with gnupg 2.0" [Undecided,Fix released] https://launchpad.net/bugs/1564234
<slangasek> superm1: please do - from previous proposed-migration investigations, I understand that the behavior of the newer gnupg2 differs from the previous one in various ways that may or may not impact other things up the stack
<doko> pretty please can we have a FFe for https://mail.python.org/pipermail/python-dev/2016-March/143603.html ?
<slangasek> doko: I suppose you want this in for the next rebuild test?
<doko> slangasek, I didn't expect you would volunteer for the packaging ...
#ubuntu-release 2016-04-01
<slangasek> do not meddle in the affairs of dpkg-maintscript-helper; for its bugs are subtle, and life's too short.
<mwhudson> infinity: oops, i forgot to update Maintainer when i added ubuntu delta to dh-golang
<infinity> mwhudson: Naughty.
<infinity> mwhudson: You can go sit on the bench of shame with doko -- he never updates the maintainer. :/
<mwhudson> heh
<slangasek> mwhudson: set DEBEMAIL to something appropriately Ubuntuish and dpkg-buildpackage will remind you of this
<slangasek> and yeah, I hate doing an ubuntu2 upload behind doko ;)
<mwhudson> oh right i guess i should use ubuntu.com for packaging now
<stgraber> can someone review lxc and lxd in the queue? lxd is trivial, lxc is a bit bigger what with being an upstream rc release and all
<stgraber> I have some hope of tagging final lxc 2.0 tomorrow but that kind of depends on users being exposed to that last rc first :)
<infinity> stgraber: Looking.
<infinity> stgraber: Oh look, ports support!
<stgraber> it was there already as a cherry-picked fix in the previous upload :)
<stgraber> but yeah, the Debian maintainer didn't know that archive and ports are separate in Ubuntu so when fixing the ubuntu template on Debian he kinda broke it for everything but amd64 and i386 :)
<stgraber> yay, now to tag another lxd rc, hoping that's the last one but as can be seen by the absurd number of rcs we've gone through already, I'm not gonna bet on it :)
<stgraber> at least we're done with lxcfs, that's one less thing to worry about
<infinity> stgraber: Meh, keep on RCing until release week, as long as the bugfixes are tiny and auditable.
<infinity> stgraber: Just gimme a shiny round number before we close the archive. :P
 * infinity isn't sure if he'd have more confidence in 2.0rc1 or 2.0rc30, but 2.0 is always prettier)
<stgraber> well, our plan was to land the first upstream bugfix release of all 3 before 16.04 releases but for that to work we need to release the actual thing first and for that to happen people should stop reporting rc bugs :)
<infinity> rc30 is either a sign of an anal-retentive perfectionist upstream release manager, or people who Really Can't Get It Right, Ever.
<infinity> stgraber: Knowing you, I'm sure it's the former, but if it was just some random, I might start thinking it was the latter. :P
<infinity> Tag, "crap, it's broken", tag, "crap, it's broken", ad infinitum.
<stgraber> :)
<stgraber> I thing we had one lxc tag where I had to tag again 10min later because someone landed a change which introduced a new file but which wasn't included in the dist tarball... turns out things don't build when files are missing.
<infinity> Picky, picky.
<infinity> Also, never push a tag until you've tested.
<stgraber> but that was at at the time where the kernel was busted so jenkins was lying to us, otherwise we'd have caught it way earlier (as our jenkins job does a make dist + build + package on all arches we care about and even on Android)
<infinity> They're super easy to delete locally.  Super hard to delete from everyone else's computer. :P
<slangasek> infinity: you're going to love reviewing this one.  A taste of things to come: http://paste.ubuntu.com/15572738/
<stgraber> "./configure && make && make install" worked great locally :)
<infinity> slangasek: Dude.
<infinity> slangasek: How's the ganja over there?
<slangasek> infinity: 100% legal
<stgraber> slangasek: you forgot to throw some messing with IFS in there
<slangasek> stgraber: haha
<stgraber> assuming your goal was to give a headache to whoever reviews it
<infinity> I'm already a bit headachey trying to figure out *which* maintscript he feels needs that abuse.
<slangasek> stgraber: this is a very parsimonious implementation ;)
<infinity> But I'll wait for the glorious finished product before I string the rope.
<slangasek> infinity: the preinst and postinst of squid.  The existing Debian package calls dpkg-maintscript-helper in both the squid and squid3 packages, for conffiles previously owned by squid3.  The 'squid' copy of these DTRT *if* you previously had the squid dummy package installed, otherwise it's a complete no-op.  The squid3 copy does the right thing *only if you haven't modified any of the conffiles*;
<slangasek>  otherwise it overwrites the squid package's ...
<slangasek> ... conffiles with your modified squid3 version with no conffile prompt
<slangasek> because dpkg-maintscript-helper looks at the args and says "oh, you have no previous version? jollygood, I'll just noop all this code"
<slangasek> so the only way to dtrt is to trick it, in the squid maintscripts, to not no-op
<infinity> Gross.
<infinity> slangasek: Oh well, to be fair, I pointed someone to the pkgbinarymangler preinst as a "useful example" today, so we all have blood on our hands.
<infinity> Speak of the devil.
<cyphermox> haha, yeah
<cyphermox> now I have bloody hands too, good job
<cyphermox> oh wait, there once was usb-modeswitch too.
<infinity> cyphermox: Oh, hrm.  I might make you reupload that, even after I pre-reviewed it. :/
<infinity> cyphermox: The postinst bit could concievably break if an upgrade breaks for other reasons and then someone does "dpkg -i dbus.deb" over the half-installed dbus.
<infinity> cyphermox: ie: instead of the version check in postinst, it should be a check for the diversion, probably.
<slangasek> infinity: wow. ok, no, when all is said and done, mv_conffile does entirely the wrong thing for a modified conffile, no matter what... it just moves the new conffile aside and drops the old one in its place, in the postinst, when it's too late to get any conffile prompts.
<slangasek> why did we ever stop using Keybuk's cargo culted code snippets again?
<infinity> slangasek: Because a single, central copy is better.  If anyone bothers to improve it. :P
<slangasek> it wasn't supposed to need improving :P
<slangasek> it was supposed to have gotten all this stuff right on the first go!
<slangasek> infinity: alright, so it's possible some of the work I did here didn't make a darn bit of difference anyway.  Except that it does simplify the maintscript code quite a bit overall, so probably still worth doing; and it's as good as it's going to get.  So I'll upload and if you balk at the diff I can trim things down
<infinity> slangasek: Heh.  Does it upgrade from old versions?  That's sort of the bit that matters.
<slangasek> infinity: it does, and it does as well a job of handling modified conffiles as dpkg-maintscript-helper allows it to
 * infinity is filing github pull requests in anger over his upstream not understand what an ABI is.
<infinity> Or, rather, what an SOVER is for.
<infinity> I suppose both.
<infinity> (No, not *that* upstream, we don't have libc7 on the horizon)
<infinity> Though, man, if we were collectively prepared to go through the pain of another libc transition, we could clean up SO MUCH CRUFT.
<infinity> There's a metric whackton of stuff we've removed from the API, but not the ABI.
<slangasek> infinity: 2038 man, just drop all entry points that predate 64-bit time_t
<rharper> slangasek: \o/
<infinity> slangasek: That date is way less scary-far-off-futuristic than it used to be...
<slangasek> infinity: we could avoid the transition pain by moving all the computers to within 10 feet of sealevel?
<infinity> slangasek: To be fair, that's where an awful lot of them are already.
<slangasek> rharper: yeah, squid3 uploaded, it should upgrade everywhere, I'm looking for whiskey now
<infinity> slangasek: And it occurs to me that the reason Republicans outwardly appear to be climate change deniers is simply because if they continue to do nothing about it, a large portion of the Democrat voting base will be floating.
<infinity> (Along with their fancy datacenters)
<slangasek> infinity: PJ O'Rourke: "well sure, we *say* it's not happening, meanwhile we're buying a lot of inland real estate"
<infinity> Man, when did 8 o'clock happen?
 * infinity goes to find a pizza and take a TV break.
<infinity> slangasek: If you had an upstream that bundles multiple libs in the same source, versions them based on source version, and one of them broke ABI, would you be more inclined to recommend decoupling the versioning, or just bump them both in lockstep, even though it's a lie for the unchanged one?
<infinity> Guessing the latter is easier to explain.  And it's definitely a simpler patch.
<slangasek> infinity: generally, decoupling
<slangasek> but yeah
<infinity> slangasek: Ain't no autotools or other magic in play, they literally parse the RPM specfile (lolz) for the version, and slap that on the library.  Which works well enough, but isn't amazingly flexible.
<slangasek> infinity: software is horrible, where's that bottle of whiskey
 * infinity will see if he can catch up with Nate and converse realtime.
<bluesabre> Please accept the above mugshot package. Resolves several issues and has been tested by Xubuntu QA
<bluesabre> yay!
<bluesabre> Please accept the above catfish package. Fixes an issue with displayed timestamps and brings more complete translations.
<bluesabre> (sorry for the redundant looking messages, but the first few seem to have worked well, and somebody seems to be seeing them :))
<knome> hello release team! the xubuntu team will be doing an upload to our community wallpapers package; this upload doesn't change the default wallpaper, only the some of the wallpapers available by default. would you like some kind of freeze exception paperwork done whatsoever, or can we just upload that once we have picked our winners?
<infinity> knome: No exception needed, if the defaults are all the same, IMO.
<knome> infinity, ok, cheerio
<knome> we'll make sure it lands before the final freeze then :)
<infinity> Ta.
<teward> can I get the nginx 1.9.13 upload at bug 1563393 reviewed for an FFe?  I'd like to get this reviewed now, and included, and then the next version (to also need review, it'll be before FinalFreeze) will have additional changes - but for that next upload to go in, I'd like 1.9.13 to land first.
<ubot5`> bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed] https://launchpad.net/bugs/1563393
<teward> it's not in the upload queue yet, i was waiting for the review before i pushed it up
<ogra_> can someone let livecd-rootfs in (i'd like to build a test image before EOD)
<infinity> superm1: Unless those symbols really were added with an Ubuntu patch (man, I hope not), you should s/0.7.0-0ubuntu1/0.7.0/ in the symbols file to get sane deps against the upstream version rather than the package version.
<infinity> superm1: Also, is there an FFe for this?  It's pretty clearly not just bugfixes.
<infinity> xnox: What's the point of differing from upstream on the location of cpuplugd's config file?
<infinity> xnox: Seems like a pretty large delta for no good reason.
<infinity> xnox: Oh, I see, it's IBM that fed you that patch.  Weird.  Does that mean they intend to move it in the upstream packaging too?
<infinity> xnox: Also, shipping a service disabled by default is both un-Ubuntu and un-Debian.
<teward> infinity: given the final stretch before Final Freeze, any chance you can look at the nginx FFe for 1.9.13?  I haven't uploaded yet, was waiting on the 'all clear' - bug 1563393.  Tuesday's my deadline on getting 1.9.13 uploaded...
<ubot5`> bug 1563393 in nginx (Ubuntu) "[FreezeException Needed] Update nginx to 1.9.13." [Wishlist,Confirmed] https://launchpad.net/bugs/1563393
<infinity> teward: Looking.
<teward> infinity: thank you kindly, sorry to be a nag :)
<infinity> teward: Make it happen.
<teward> infinity: thank you kindly!
<xnox> infinity, i will not ship a brand new config file in /etc/sysconfig/cpuplugd that it too much redhadish
<xnox> infinity, the daemon is weird, i believe default config will make one not use 100% of available resources and scale one back.
<xnox> which imho is wrong to be enabled by default, and hence needs user to provide/update config before enabling.
<superm1> infinity: ack, reject it and I'll make sure the features are documented in ffe
<xnox> infinity, and hence whilst that is undebian and unubuntu, it's least surprise.
<xnox> and hence does not warrant to be in a standalone package
<superm1> They're used only with new software not in archive but yes technically new features included
<teward> infinity: it's waiting approval, can you ACK it?
<infinity> xnox: I was with you right up until the last sentence. :P
<xnox> infinity, however the osnmp thing adds dependency on three more shared libraries, maybe that should be split into stand alone package
<infinity> teward: I did.
<teward> ah, email is slow :)
<xnox> infinity, so would you rather see cpuplug thing into standalone package, and enabled service by default instead?
<xnox> i'm happy to upload that.
<xnox> infinity, also what's your opinion on growing three more shared libraries deps for osnmp thing?
<infinity> xnox: It's generally more the Debian Way to have services start when installed.  It's the element of least surprise.
<xnox> ok.
<infinity> xnox: As for the conffile, I'm not fundamentally opposed to it moving, I'd just like to see the movement mirrored upstream.  It's a silly delta to carry forever.
<xnox> i think i would want to split the osnmpd into separate package too
<xnox> because of the deps, and not eveyone carrying about snmp
<xnox> (and for snmp to be worthwhile one needs an extra furtune, to have more than one mainframe....)
<infinity> xnox: Yeah, no huge opinion there from me, but not dragging more deps into the base install is nice.
<infinity> xnox: Can you name the extra packages "s390-tools-$binary", so they're obviously parts of s390-tools split out (and not pulluting namespace with the super generic names)?
<infinity> xnox: And probably add both to s390-tools' Suggests, so they're vaguely discoverable.
<xnox> yes and yes
<infinity> xnox: Oh, and if that current conffile move is a copy or symlink (sadly, debdiff presents both the same), a debian/rules hack to mv tmp/etc/sysconfig/foo to tmp/etc/foo.conf would be a much less ugly delta until upstream moves it for realz.
<xnox> infinity, i did mv in debian/rules
<xnox> then went with a patch
<xnox> it is identical / rename
<infinity> Yeah, I'd go for the rules mv then.
<xnox> i might go fancy and use dh-exec to rename it in debian/*.install file =)
<infinity> 1 line instead of hundreds. :P
<infinity> Or dh-exec, sure.
<xnox> ok.
<xnox> so i take it you have rejected this upload by now, right?
<xnox> =)
<infinity> Yeah, I did.
<infinity> You didn't respond on IRC in time, so I rejected it to prevent someone else accepting before we talked. :P
<infinity> superm1: And fix your symbols too, if you missed that nag. ;)
<infinity> teward: OOI, where do your nginx orig tarballs come from?  Are they guaranteed to be the same ones Debian will pick/use?
<teward> infinity: upstream directly
<infinity> teward: (Having weird deltas due to mismatched tarballs makes future maintenance suck)
<teward> Debian grabs the pristine tarballs and uses them as their base
<teward> most of their changes are done internal to debian/*
<teward> including third party modules
<infinity> teward: So, same tarballs as Debian is what I'm hearing?
<teward> correct
<infinity> Kay, good.
<infinity> Thanks.
<teward> I personally pull them right from nginx's site
<teward> I think Debian grabs them then adds them to alioth/git
<infinity> But with pristine-tar, I'd assume, so they reconstruct same as uptream.
<teward> right
<teward> the biggest hurdle going into Y-series is that Debian is, IIRC, planning on releasing their experimental module support "soon"
<teward> as in before FinalFreeze
<teward> Xenial FinalFreeze*
<teward> rbasak and I discussed, so from here until Xenial release there's not going to be a merge
 * infinity nods.
<teward> then comes Y-series, which will be the hellish time - many more things to determine - what goes in what pocket, Security review, etc.
 * teward shivers
<infinity> teward: No merge with Debian (cherrypicks for bugfixes, though, please) is fine, but having the same tarball still makes it much simpler to check what the delta is.
<teward> infinity: indeed.
<teward> though, consider Debian's, what, at least 3 revisions behind now
<teward> so a merge will need some finesse to make sure it works right
<teward> last I saw, Debian's on 1.9.10
<teward> and 'cause they never moved i've been doing direct-upload
<teward> (Debian's aware we're gunning for 1.10.0)
<teward> s/gunning/going/
<teward> i hate IRC over phone >.>
<infinity> gunning works in that context too....
<teward> true, though i didn't type it
<infinity> I would never have known it was a typo if you hadn't mentioned it.
<teward> infinity: so far, though, there's not been any real bugfixes in Debian, just some feature changes to what gets HTTP/2, some third party modules that got updated to work around 1.9.11 FTBFS (we nitpicked the fix, the update to an RC version was a "yeah, no" moment)...
<teward> i think maybe some core config changes given dynamic modules, but they're not landing in Xenial
<teward> (Not Released, yet, in Debian, for the feature changes parts)
<teward> infinity: I also track upstream, so when an issue happens here, and upstream has fixes, I nitpick there :)
<infinity> superm1: Remind me to un-reject gnome-software after your new fwupd is a thing.
<infinity> slangasek: Running out of things in the queue to use as a delay tactic.  Looks like squid3's up.  Can I trade you appstream-glib as penance?
<teward> infinity: also, for the record, perfect example of this happened in 1.9.10 - https://launchpad.net/ubuntu/+source/nginx/1.9.10-0ubuntu1 was direct-uploaded ahead of a Debian merge for the CVE, to make sure it lands in Xenial; https://launchpad.net/ubuntu/+source/nginx/1.9.10-1ubuntu1 uploaded the next day with the Debian merge
<teward> with no merge/tarball oddities, that almost reinforces the tarballs are both pristine
<infinity> ogra_: [ -d /etc/cloud/cloud.cfg.d ] || mkdir -p /etc/cloud/cloud.cfg.d
<infinity> ogra_: That test is pointless, mkdir -p is idempotent.
<infinity> ogra_: (Not worth a reject, just pointing it out so you can make a mental note for future shell abuse)
<infinity> slangasek: Sweet mother of holy changelogs.  I guess I can't fault you for your documentation.
<infinity> slangasek: Why the choice to mv squid3 squid instead of moving the contents?  Concern that if it's a mountpoint you'll ENOSPC their root partition?
<slangasek> infinity: that, plus not having to deal with dotfiles
<mgz> slangasek: can I bug you about the suggestion to not do update-alternatives and just make a juju-1.25 binary
<slangasek> infinity: and yeah, I'll look at appstream-glib
<slangasek> mgz: sure
<mgz> slangasek: the reason that I didn't do that is the way juju plugins work is they select sibiling or path binaries named juju-$PLUGIN
<mgz> so, if we just have a juju-1.25, that breaks all juju 1.X plugins, because it will find and try to use the juju 2 plugins
<slangasek> mgz: where do these plugins come from?
<infinity> slangasek: The dotfile argument could surely be sorted with "for i in `ls -A1`", but the mountpoint argument is probably still valid.
<mgz> whereas when you run `/usr/lib/juju-1.25/juju` it works, and is also unambiguous
<mgz> slangasek: they're built from the same source
<slangasek> mgz: /usr/bin/juju-1.25 doesn't have to be a binary, just an executable; it could be a wrapper that just calls 'exec /usr/lib/juju-1.25/juju "$@"'?
<mgz> but the logic for doing that stuff is in go, not in the packaging
<mgz> let me see
<infinity> slangasek: We don't install anything by default that shows NEWS.Debian, I'm wondering if a debconf note at migration failure (before the daemon is restarted) prompting the admin to shell out, fix the situation, and continue, might not be the worst idea.
<mgz> slangasek: plugins only work when they're on the path, and named 'juju-$NAME'
<slangasek> infinity: I've already burned way more time on this package than it deserves; that seems like a further enhancement above and beyond, rather than a bug I've introduced with my changes?
<superm1> infinity: ^ with the symbols fix and FFe documentation
<infinity> slangasek: Oh, sure, it's not a bug in your bits, which are clearly an improvement over not attempting the migration at all. :P
<infinity> superm1: Ta.
<slangasek> mgz: isn't that a problem with the update-alternatives approach too?
<slangasek> mgz: or, should your /usr/bin/juju-1.25 wrapper just prepend /usr/lib/juju-1.25 to the path (also trivial)?
<mgz> slangasek: that's an idea. it's not a problem with update-alternatives when we do switching, because the plugins get symlinked into /usr/bin
<slangasek> mgz: ok. but then that means the update-alternatives approach really doesn't support the user running the non-default alternative at all, despite it being installed
<slangasek> I think a wrapper script makes more sense there
<infinity> Indeed, the wrapper with a PATH modification seems much cleaner.
<mgz> slangasek: `PATH=/usr/lib/juju-1.25/bin:$PATH juju "$@"` works
 * slangasek nods
<infinity> export PATH=...\nexec juju "$@" gets a prettier ps output (and lack of useless long-running shell)
<slangasek> +#define AS_TEST_WILDCARD_MD5   "\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?\?"
<slangasek> hahahahaha
<infinity> Wat.
<infinity> slangasek: "It's an MD5 if it's a string of the right length" is the test here?
<slangasek> infinity: this complements AS_TEST_WILDCARD_SHA1 on the preceding line
<slangasek> infinity: yes!
<infinity> Oh dear.  Same thing for SHA1?
<infinity> But, well, longer?
<slangasek> yes! :)
<infinity> Brilliant.
<mgz> slangasek, infinity: so, I propose leaving the update-alternatives machinery in place (I want it for a safe way of putting alphas in the next dev release), and adding a /usr/bin/juju1 that's a script wrapper
<infinity> mgz: Given the plugins argument, I don't see much use for the update-alteratives at all.  The safe way to do alphas would be to have a similar /usr/bin/juju3 wrapper, and then drop it when the default flips.
<infinity> Or /usr/bin/juju-alpha, so it's not ever-changing.
<slangasek> mgz: I am unconvinced that update-alternatives is the right tool for any of this.  The only legitimate way to change which alternative is the "default" on a system is by juggling priorities; I don't think you want to have to upload old versions of juju multiple times in a release cycle for this
<slangasek> I also don't see that alphas warrant co-installability
<mgz> I have had conflicting feedback on putting alphas into the distro
<slangasek> in a dev release, standard procedure is that you upload to the archive the package that's on track to be released, and it just owns that name, and you deal with bugs
<infinity> YOu could make all versions co-installable if they *all* used a /usr/bin/juju-$ver path wrapper and introduced a juju-defaults that ships the /usr/bin/juju symlink to the right default (Cause, hey, if it's good enough for compilers, why not replicate it everywhere!)
<mgz> distro says go do that... everyone else doesn't want it
<mgz> I can do the path wrapper thing in replacement
<slangasek> who is this "everyone else" that has opinions on what should be in the dev release that AFAIK they aren't using?
<slangasek> anyway, from a ux pov, you don't want to have to 'sudo update-alternatives fwibble' every time you switch between coinstalled versions
<slangasek> you want to be able to run any of the installed versions of juju as a user without doing that; in which case the alternative is of marginal value but high overhead
<mgz> it seemed like a nice way of having people who need to remain on 1.X have all their scripts still work
<mgz> but I'm fine with doing what's suggested now
<slangasek> sure; but the fact that juju-1.25 /won't/ be the default means the user has to do $something to keep their script working, and that something might as well be editing the script (or adding /usr/lib/juju-1.25 to their system path?) rather than managing an alternative
<infinity> slangasek: The plan was for juju-1 to be the default, actually, to avoid breaking upgrades.
<infinity> (But maybe that plan changed again)
<slangasek> infinity: that plan was nacked by sabdfl
<infinity> Ah.
<slangasek> and I signed off on this
<infinity> Yeah, then alternatives are pointless in this context.
<slangasek> things don't always work without interruption on LTS upgrade
 * slangasek nods
<mgz> okay, so I'll switch to wrapping scripts named juju-$VERSION that add /usr/lib/juju-$VERSION/bin to the path
<slangasek> by which I mean: the distro should work without interruption on LTS upgrade, but things external to our packages that make assumptions are not guaranteed to work without modification
<slangasek> mgz: +1, thanks
<infinity> There's no real difference between saying "you must run update-alternatives" or "you must sed s/juju/juju-1.25/ in all your scripts", except that the latter is a much saner explicit choice that works everywhere and isn't dependent on some obscure system config.
<mgz> thanks for the explanations guys
<infinity> And, indeed, if the version wrappers persist forever, people can keep that explicit choice motif going forward and be less surprised on the next upgrade.
<infinity> (ie: they can move to 2, and then when 3 happens, their 2 scripts won't be broken and they can test and move)
<mgz> I have some fiddly bits with man pages and bash completion to work out, but am just removing scripts for now
<mgz> slangasek: can the FFE bug be accepted as it stands? I'm doing the changes for name-version linking, were there other concerns to address?
<infinity> doko: Why does --with-milestone differ between EFAULT_CONFIGURE_ARGS and COMMON_CONFIGURE_ARGS?
<infinity> s/EFAULT/DEFAULT/
<slangasek> mgz: the packages to be accepted will need to meet the outlined conditions; are you asking for the bug to be marked 'Confirmed'?
<infinity> doko: re: openjdk-8, if that wasn't clear.
<slangasek> infinity: ok so I've reviewed appstream-glib and this looks to me like a featureful upload with no FFe bug, no upstream changelog, and no assurance of upstream QA (git snapshot); unless you had some other context, this looks like a nack to me
<mgz> slangasek: do you/release team need to review the debian/rules once I've uploaded to unblock this process? or are we good to propose with these changes?
<infinity> slangasek: I had zero context outside the diff being something I didn't want to read.  All you.
<slangasek> mgz: there will be a post-upload review
<mgz> slangasek: so, do I have the sign-off to upload? that's not reflected in the bug at present.
<slangasek> mgz: you unblock the process by getting something uploaded
<infinity> slangasek: "rm -f || true"?  You don't trust the effiness of -f?
<slangasek> infinity: hum.  Did I write that? or did I copy it from somewhere
<slangasek> (what did I rm -f and why?)
<infinity> slangasek: I dunno.  If you copied it, it's not from anywhere in context. :P
<slangasek> infinity: ah, I copied it from dh_apparmor's maintscript snippet :-)
<infinity> slangasek: Oh, also, that squid3->Pre-Dep: squid, squid->Conflicts: squid3 combo kinda buggers the world a tiny bit.  That Conflict should surely be a Breaks.
<slangasek> infinity: it was like that when I got there.  I at one point iterated and dropped it to Breaks, then reverted because of the horror of dpkg-maintscript-helper being called in both packages. Let me think
<infinity> The conflict forces a total removal before we even start, which messes up any attempts to stop the old daemon, and also busts your mv_conffile attempts, if we're doing the upgrade with --purge.
<slangasek> the old daemon is stopped by the old package's prerm
<slangasek> ... who does an upgrade with --purge?
<infinity> I do. :P
<infinity> Pretty much always.
<slangasek> right, well
<slangasek> yes, I think the Conflicts can and should be dropped to Breaks now that the maintscripts are confined to a single package
<slangasek> but I'll need to re-test that
<infinity> slangasek: The rest looks vaguely reasonable in that "I'd really have to build it and test to be sure" sort of way.
<infinity> tjaalton: Where's the FFe for this major version bump to wayland?
 * infinity said, while clicking reject.
 * mdeslaur chuckles at commentary
<slangasek> infinity: ok, so I'll downgrade Conflicts to Breaks, retest the upgrades, and reupload.  Do you want the current one accepted or rejected in the meantime?  Note that while I versioned the Conflicts in this upload, it's there in the one currently in -proposed already
<infinity> slangasek: Yeah, I'd rather we just leave this in the queue while we test.  Then we can accept whichever turns out to be more correct.
<slangasek> infinity: but block the server team from doing any more Real Testing in the meantime.  My turnaround on this is probably going to be about 2 hours
<infinity> slangasek: And +1 from me on this, other than that one sticking point, so if you either come to the conclusion that the Conflict is necessary or reupload with Breaks and that's the only diff, feel free to self-accept.
<infinity> slangasek: To be fair, it's EOD for most people by now anyway.
<infinity> (or close to it)
<infinity> EOW, even.
<infinity> slangasek: But I suppose you're right that it does no harm to upload twice.  I can accept this one, and you can self-accept the 1-liner if it's gooder.
 * infinity won't be testing upgrades on his production kit until the second upload happens. :P
<infinity> superm1: You appear to have an endian bug in fwupd which, based on the build logs, might actually be a singed-comparison bug that is exacerbated by your ints being backwards. :P
<tjaalton> infinity: gnome folks asked for it, i don't care
<infinity> tjaalton: Well, you uploaded, you get to be the one who cares.
<tjaalton> heh
<infinity> tjaalton: Alternately, get the "GNOME folks" to file an FFe and sync in their name. :P
<superm1> infinity: sigh, and it looks like it's only encountered from actually running the test suite on all the other archs now :)
<infinity> superm1: Well, good.  That's what testsuites are for.
<tjaalton> it's a build dep for mesa & xserver, only reaaon why it's in main
<tjaalton> iirc
<infinity> tjaalton: And gtk, and a few others.  But it still has the ability to destabilise the world.
<infinity> (it's a runtime dep too, obviously)
<superm1> infinity: can you let it through proposed for now and this can be investigated more closely at a lower priority?  the more interesting part today really is x86
<infinity> superm1: No.
<infinity> superm1: It's regressed on two arches.
<superm1> okay.
<infinity> superm1: If what you're saying is "this was always broken on BE, apparently", you can reupload with the tests disabled on BE, so it can build everywhere, and thus things can link to it.
<infinity> superm1: But I'd want a pretty firm commitment to actually fix the bug.  Since endian and singed-compare bugs are often lurking evil on other arches too that your testsuite just happens not to notice (or that other code could perturb into a bug)
<superm1> infinity: yeah i'll need to get some BE emulation set up to investigate further, but yes likely this was broken everywhere BE most likely all along
<infinity> superm1: Without looking at the code, I'm betting it's a signed-char versus unsigned-int comparison, where you just happen to not be comparing the top bit, so it works by accident on some arches, but explodes on big-endian because the ints also happen to be flippity whee.
<infinity> superm1: Based on that, and a build log, you might be able to fix it blind (happy to test).  But I can hook you up with BE hardware if blind is a no-go.
<infinity> superm1: Oh, or actually, it's the length mismatch that's probably the endian bug.  I missed that one.
<infinity> superm1: (You'd end up comparing the wrong half of your long)
<infinity> superm1: But you should fix the singed-compare bug too. :P
<infinity> superm1: Anyhow, both are staring at you angrily in the build log.
<infinity> superm1: FWIW, both those compiler warnings were there in the previous version, so I'd be okay with an upload to disable the testsuite on big-endian and a commitment to fix and reenable "soon".
<superm1> infinity: OK well i'll take a stab at a fix and make the test suite failing non-critical on those archs in case it's not adequate
<infinity> superm1: ifeq($(shell dpkg-architecture -qDEB_HOST_ARCH_ENDIAN),big) for the workaround
<superm1> infinity: can i have my PPA turned on for one of those archs?
<infinity> Sadly not yet. :(
<superm1> that way i don't need to waste more of your time trying to fix it
<superm1> oh
<superm1> okay
<infinity> We're almost there for powerpc.
 * infinity notes that he failed to lunch again, and goes to find a snack.
<slangasek> infinity: yeah, I'm good with the Breaks/Replaces behavior; uploaded
<infinity> slangasek: Ta.
<infinity> Okay, now lunch for realz.  I mean it.
<infinity> Back later.
<superm1> infinity: it looked like an easy rabbit hole, but alas it's deeper than it appears , test suite off for now on those archs but i'll work with upstream to get this fixed
<slangasek> infinity: "failure to lunch", a common problem for the younger generation
<superm1> blah, s390x is failing harder than powerpc was
<superm1> xnox: although the s390x failure was with launching valgrind, is that itself working on s390x?
<superm1> i see the build used 1:3.11.0-1ubuntu2, but 1:3.11.0-1ubuntu3 was just uploaded to proposed.  probably should retry with that
<slangasek> superm1: "illegal instruction"?
<slangasek> (cf https://launchpadlibrarian.net/249873837/buildlog_ubuntu-xenial-s390x.colorhug-client_0.2.8-1_BUILDING.txt.gz which I knew was another package using valgrind at build-time)
<superm1> looks pretty similar  failure
<superm1> looks like trying with new valgrind did resolve it
<slangasek> and it looks like -1ubuntu3 is a fix specifically for s390x issues, so \o/
<slangasek> superm1: ah, you did a rebuild and already picked up -1ubuntu3? I was waiting for it to show up in rmadison before retriggering things
<superm1> yeah
<slangasek> spiff
<superm1> talk about convenient timing
<slangasek> clearly dannf was sent back in time from the future to fix all our s390x bugs
<dannf> but not in a nude terminatory way, i promise
<slangasek> "come with me if you want to virtualize"
<flocculant> cyphermox: you might like to know that I have now got an upgraded xubuntu 16.04 from 14.04.4
<flocculant> I know I did ;)
<flocculant> restart appeared to not - but in the context I still think it's a win :)
<infinity> flocculant: Restart should work, so still some bugs to squish, but yay progress.
<flocculant> yea - I realise it *should* but given I was wiki warning last week - definitely progress :)
<flocculant> infinity: also, your throw away comment last week re flavours and release notes - made me stop and think a bit - so if I save time next cycle- thanks :D
<superm1> infinity: I recall you told me to remind you to unreject gnome software earlier
<infinity> superm1: Yup, already have the tab open.  Was just waiting for those binaries to publish in the release pocket, for reasons unexplained.
<superm1> Kk
#ubuntu-release 2016-04-02
<doko> infinity, there's one more typo ... the setting in COMMON_CONFIGURE_ARGS is ignored
<doko> will look at it tomorrow
<stokachu> slangasek: fyi ^
<phillw> Hi folks, will bug 1555237 be in tomorrow's cron respins (i.e. dated 3rd April) ?
<ubot5`> bug 1555237 in systemd (Ubuntu) "Upgrade from 14.04.4â 16.04 dies midway taking out the session." [Critical,Fix released] https://launchpad.net/bugs/1555237
<infinity> Why did the bot just randomly barf a bug ref?
<phillw> infinity: it did not, I asked if the fix released"
<phillw> infinity: would be in 3rd April cron jobs
<cyphermox> phillw: not really affecting the images so much, i suppose
<cyphermox> oh, unless you were to try to upgrade from the CD, which probably needs some extra other bug fixes
<cyphermox> in any case, it should all be in the next image, yes
<phillw> cyphermox: thanks, I like to cover both bases as they are in the iso tracker for bug reporting and one tester has said it all failed... I asked him to re-try after the fix filtered down.
<cyphermox> phillw: sure. like I said, I can see why upgrading from the CD might break in other fun ways, it needs testing
<cyphermox> but at least the ugly bad failures should already be covered
<phillw> cyphermox: no, he did the CLI command, and it failed
<cyphermox> phillw: the issue is that this bug is too generic
<cyphermox> we fixed one issue in dbus, and another completely unrelated issue in systemd
<cyphermox> if there's more, we should have new bugs
<phillw> cyphermox: indeed.. the guy is  a good tester, when he awakens, he will crawl all over it like a rash ,,, he is tsimonq2 and is pretty determined when you point him the right direction. He had various error messages, and synaptic package manger (GUI) failed to fix broken... So, I said I'd ask on here as to if things should be working okay. Should he tag onto the existing bug, or file a new one and have it brought to your guys' and gals' a
<cyphermox> phillw: my preference is always a new bug, we can easily mark duplicates later, but it's hard to split things up after the fact
<cyphermox> usually one bug per error message is a good plan; and one bug for synaptic not being able to fix broken packages
<phillw> cyphermox: I concur, but it is always best to ask. Thank you for your time, and as this is logged channel, do you have any objection to my just copying and pasting our chat to him instead of him going through the logs?
<cyphermox> not at all
<cyphermox> I know tsimonq2
<cyphermox> and on that, I log off now since it's very late :)
<phillw> I gave him a VM for his 14th b/day present as part of apology for me going 'off topic'. He's doing well, only destryed it once :)
<infinity> superm1: Bah.  I fixed the crc32 failure only to hit another failure in the testsuite afterward.  Done with my bored hacking for the night. :P
<mapreri> can I poke for 2 RMs?  #1556226 #1556229
<ginggs> mapreri: if no response, try on Monday
<darkxst> infinity, still around? where does DistUpgradeQuirks get pulled from on a trusty upgrade, doesnt seem to use local copy?
<darkxst> see bug 1565177
<ubot5`> bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177
<mapreri> ginggs: Ok.
<ginggs> mapreri: instead of hoping there are no rdeps, please include the output of 'reverse-depends src:scribus-ng' in the bug
<ginggs> and the same for scribus-ng-doc
<tsimonq2> cyphermox: hi, so I used gparted to partition my hard drive, so /dev/sda2 could be used, then I used https://help.ubuntu.com/lts/installation-guide/i386/apds04.html to install Trusty onto the system, along with lubuntu-desktop.
<tsimonq2> cyphermox: booted into /dev/sda2 and tried a do-release-upgrade -d. It did not work as expected. It threw some dep errors that I have to Phill in a pastebin. Do I file the build-dep errors as a bug in each of the affected packages? Where do I file the bug?
<tsimonq2> cyphermox: and yes, Phill made me try Synaptic (I hate GUI when it comes to package management) and it was not able to fix it, bug against that as well?
<phillw> infinity: can you give me a ping, thanks.
<superm1> infinity: yup rabbit hole ð
<phillw> superm1: as alice, or the mad hatter ?
<superm1> Definitely mad hatter
<infinity> darkxst: The dist-upgrader comes from the target release, not the one you're starting from.
<infinity> superm1: It wouldn't be a rabbit hole if the testsuite wasn't a single C file with assetions. :/
<infinity> superm1: Breaking out all the tests would let me see them all broken at once instead of "yay, I fixed it, oh nevermind, yay I fixed it, oh nevermind".
<infinity> superm1: Anyhow, the crc failure is a simple one-liner.  The compiler warnings are a red herring and don't relate (though would be nice to get fixed some day).
<infinity> superm1: Now that I'm awake again, I might look at the new failure that fixing the crc failure exposed. :P
<superm1> infinity: if you can run interactivity, launching libdfu/dfu-self-test --debug-log --verbose should hopefully get more information about what what was happening since the next thing after CRC doesn't look as straightforward
#ubuntu-release 2016-04-03
<infinity> Thanks, queue fairy.
<stgraber> :)
<stgraber> guess i should get some sleep...
<infinity> My clock says I should too.
<superm1> infinity: https://github.com/superm1/fwupd/commit/2056ddb50b4257936ef1bee89ab4442e8e4fe9c6 should do the trick but can you build it in a powerpc enabled PPA to confirm that's everything?
<infinity> superm1: Can do.
<infinity> superm1: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages
<infinity> superm1: Looks like that passed the testsuite on all arches.
<superm1> infinity: awesome thanks.
 * infinity waits patiently for the upload.
<infinity> superm1: You could just take that one and fix the changelog. :P
<infinity> superm1: ^-- Your changelog makes no mention of the gobs of new python added to mythbuntu-common or what it's there for. :P
<superm1> new python?  you mean dropping old stuff
<infinity> superm1: No, I mean the addition of d3des.py, vnc.py, dictionaries.py ...
<infinity> http://launchpadlibrarian.net/251560479/mythbuntu-common_0.76.1_0.77.diff.gz
<superm1> i'm suspecting tgm4883 might have done the last upload wrong if that stuff is showing up new
 * superm1 investigates
<infinity> In other news, this upload highlights that your postinst is evil.
<infinity> Maybe.  I guess I should look at the debconf templates.
<infinity> Oh, I guess not that evil.   mythbuntu/repos defaults to false.
<superm1> oh i think the evil part is that clean didn't remove build/
<superm1> so stuff looks all new because i had done a local build
<infinity> Oops.
<infinity> Plz fix? :)
<superm1> Yep
<superm1> thank for seeing that
<superm1> axe away and i'll sort it after i fix the crying baby
<lamont> infinity: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1565567 for your RC fun
<ubot5`> Launchpad bug 1565567 in sudo (Ubuntu) "segv in sudo_getgrgid" [Undecided,New]
#ubuntu-release 2017-03-27
-queuebot:#ubuntu-release- Unapproved: python-fitsio (zesty-proposed/universe) [0.9.10+dfsg-1build1 => 0.9.10+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-fitsio [source] (zesty-proposed) [0.9.10+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: blacs-mpi (zesty-proposed/universe) [1.1-37ubuntu3 => 1.1-38] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted blacs-mpi [sync] (zesty-proposed) [1.1-38]
-queuebot:#ubuntu-release- Unapproved: xbase64 (zesty-proposed/universe) [3.1.2-11 => 3.1.2-12] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xbase64 [sync] (zesty-proposed) [3.1.2-12]
-queuebot:#ubuntu-release- Unapproved: node-mocha (zesty-proposed/universe) [1.20.1-2 => 1.20.1-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-mocha [sync] (zesty-proposed) [1.20.1-7]
<rbasak> o/
<rbasak> I'm going to swap my SRU day to today as I'll be busy with the sponsorship party on Wednesday
<rbasak> infinity: ^
<rbasak> apw: when you're in, please could you take a look at releasing mysql-5.7 to xenial-updates please? I think it's ready. The dep8 failure looks like it's an intentional environment thing?
-queuebot:#ubuntu-release- Unapproved: accepted makedev [source] (precise-proposed) [2.3.1-89ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted makedev [source] (trusty-proposed) [2.3.1-93ubuntu2~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted makedev [source] (xenial-proposed) [2.3.1-93ubuntu2~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted makedev [source] (yakkety-proposed) [2.3.1-93ubuntu2~ubuntu16.10.1]
<jbicha> rbasak: ostree/yakkety is not an autopkgtest regression: http://autopkgtest.ubuntu.com/packages/f/flatpak/yakkety/s390x http://autopkgtest.ubuntu.com/packages/f/flatpak/yakkety/armhf
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-14.16~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-dvb-daemon (zesty-proposed/universe) [1:0.2.91~git20170110-2 => 1:0.2.91~git20170110-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-dvb-daemon [source] (zesty-proposed) [1:0.2.91~git20170110-2build1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-14.16~16.04.1]
<flexiondotorg> Please unblock mate-desktop/1.18.0-0ubuntu2
<flexiondotorg> Please unblock mate-settings-daemon/1.18.0-0ubuntu2
<flexiondotorg> Please unblock caja-dropbox/1.18.0-0ubuntu2
<Laney> flexiondotorg: There is no block, just a queue freeze which is reviewed regularly. I'm about to do a pass.
<flexiondotorg> Ah, OK. Thanks Laney
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (zesty-proposed) [1.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (zesty-proposed) [1:45.8.0+build1-0ubuntu1]
<rbasak> Laney: are you able to stop phasing of cups 2.1.3-4ubuntu0.2 in xenial-updates please?
<Laney> rbasak: I think you probably need an AA
<rbasak> Looks like there are a ton of reports so the fix to bug 1642966 didn't work.
<ubot5> bug 1642966 in cups (Ubuntu Yakkety) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Fix committed] https://launchpad.net/bugs/1642966
<rbasak> Laney: ah. I thought you were!
<rbasak> apw: ^
<rbasak> xnox: ^
<Laney> assuming that the SRU team can't do it themselves
<Laney> nope!
<rbasak> I believe we can't.
<Laney> When do you unphase vs. removing the package?
<Laney> Just OOI
<rbasak> No sure.
<rbasak> Not sure.
<rbasak> In this case removal might be appropriate I think.
-queuebot:#ubuntu-release- Unapproved: adplug (zesty-proposed/universe) [2.2.1+dfsg3-0.3 => 2.2.1+dfsg3-0.4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted adplug [sync] (zesty-proposed) [2.2.1+dfsg3-0.4]
-queuebot:#ubuntu-release- Unapproved: apt-dpkg-ref (zesty-proposed/universe) [5.3.1+nmu1 => 5.3.1+nmu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted apt-dpkg-ref [sync] (zesty-proposed) [5.3.1+nmu2]
-queuebot:#ubuntu-release- Unapproved: boxer-data (zesty-proposed/universe) [10.5.14 => 10.5.15] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted boxer-data [sync] (zesty-proposed) [10.5.15]
<xnox> rbasak, Laney - removal is still a regression, as people will not get the other fix, which is ultimately causing the upgrade failures......
<rbasak> xnox: I don't follow. The bug that causes the maintainer script failure (a race?) is not fixed. Correct?
<xnox> cups in xenial-release prematurely shutsdown preventing people from accessing the web interface https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1598300
<ubot5> Ubuntu bug 1598300 in cups (Ubuntu Xenial) "CUPS web interface stops responding after a while" [Undecided,Fix committed]
<xnox> when attempting to fix that, it was discovered that upgrade scripts fail because systemd units end up being silly
<xnox> not everyone is affected by either upgrade bug; or the web interface bug.
<xnox> we never got a reliable reproducer for the upgrade failure
-queuebot:#ubuntu-release- Unapproved: accepted gnome-dictionary [source] (zesty-proposed) [3.24.0-0ubuntu1]
<rbasak> xnox: OK, but given the SRU resulted in further reports, the bug still exists, right?
-queuebot:#ubuntu-release- Unapproved: accepted xfdashboard [source] (zesty-proposed) [0.6.1-0ubuntu1]
<rbasak> By "the bug" I mean the systemd problem.
<xnox> correct
<xnox> or at least a similar issue is still manifesting itself elsehow.
<rbasak> By removing the latest SRU we'll stop people hitting the systemd problem, which they are right now.
<xnox> e.g. i still think it's correct to keep what was done in .2 but further fixes are needed.
<rbasak> They then won't get the web interface fix
<xnox> true
<rbasak> But from the point of view of users unaffected by the web interface problem, it's a "regression" they won't hit then.
<rbasak> So IMHO, we should do that pending a full fix for the systemd issue.
<Laney> IIUC you could copy .1 back into -updates
<rbasak> I don't think that'll help.
<xnox> .1 never made into -updates because of failure to upgrade
<Laney> Help whajt?
<Laney> Oh
<rbasak> *Any* update to cups has the race that leads to the maintainer script failure.
<Laney> I thought that one was released
<xnox> nope mark hit upgrade failure and kindly makred it block-proposed =)
<xnox> or some suhc
<Laney> Then I think killing this one is right
-queuebot:#ubuntu-release- Unapproved: accepted mir [source] (zesty-proposed) [0.26.2+17.04.20170322.1-0ubuntu2]
<Laney> flexiondotorg: Could I trouble you to include patch headers please?
<Laney> and the changelog is most uninformative
<flexiondotorg> This is for mate-desktop and mate-settings-daemon right?
<Laney> Yeh
-queuebot:#ubuntu-release- Unapproved: wmaker (zesty-proposed/universe) [0.95.7-7 => 0.95.7-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wmaker [sync] (zesty-proposed) [0.95.7-8]
<Laney> flexiondotorg: and https://launchpadlibrarian.net/312618974/caja-dropbox_1.18.0-0ubuntu1_1.18.0-0ubuntu2.diff.gz <- did you mean to remove 2003_execute_via_dbus_launch.patch?
<Laney> (also, Popen has an env= argument)
<flexiondotorg> Ah, yes. 2003_execute_via_dbus_launch.patch should have been dropped.
 * Laney invokes the reject-o-tron
<flexiondotorg> I'll resubmit mate-desktop, mate-settings-daemon and caja-dropbox later with the changes you've suggested.
<Laney> If you want to fix nautilus-dropbox as well, I wouldn't complain :-)
<flexiondotorg> Laney Can I upload with the same versions, now that are being rejected, or should I bump them to -0ubuntu3?
<Laney> You can re-use
<flexiondotorg> OK, I'll do nautilus-dropbox too.
<Laney> Fanx
-queuebot:#ubuntu-release- Unapproved: rejected caja-dropbox [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected mate-desktop [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected mate-settings-daemon [source] (zesty-proposed) [1.18.0-0ubuntu2]
<Laney> also communicating with Dropbox about their borkedness would be good, but not strictly required
<flexiondotorg> I've tried.
<Laney> (for nautilus-dropbox you would presumably look at XDG_CURRENT_DESKTOP and only do this hack if it is Unity)
<Laney> "Unity" in os.environ.get("XDG_CURRENT_DESKTOP", "").split(":") or something
 * Laney gets hungry
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [sync] (zesty-proposed) [0.4+17.04.20170324-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted youker-assistant [source] (zesty-proposed) [2.2.7-0ubuntu1]
<flexiondotorg> Laney, Yes. For nautilus-dropbox I check it required for Unity.
<Laney> Neato wheetos
-queuebot:#ubuntu-release- Unapproved: rejected indicator-china-weather [source] (zesty-proposed) [2.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lirc [sync] (zesty-proposed) [0.9.4c-8]
<Laney> I left a package in the queue for someone else to enjoy
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (zesty-proposed) [10.2.9-3ubuntu4]
<jibel> could someone review ubuntu-ui-extras in the unapproved queue? it goes with ubuntu-system-settings that has just been approved
<apw> jibel, in zesty ?
<jibel> apw, yes
<apw> jibel, /me hates on syncs
<rbasak> apw: see cups discussion above please. Are you able to do a phasing stop or delete from xenial-updates?
<apw> i can delete that, what version was there before ?
<rbasak> I believe there was nothing in xenial-updates. I'll check.
<apw> jibel, the diff here is vast, ugg
<rbasak> Yeah, AFAICS 2.1.3-4 only in the release pocket.
<apw> rbasak, is there a bug for the regression
<apw> so i can ref it
<rbasak> Yes, one moment
<rbasak> apw: let's use 1676380 to track today's "regression".
<apw> rbasak, gone modulo the publisher
<rbasak> Thank you! I'll sort out the bugs.
<ginggs> anyone know of something that changed in armhf and s390x autopkgtesters between 2017-01-29 and 2017-03-02?  varnish now fails its autopkgtests  - Port "6081" should be listening with tcp
<ginggs> ^ blocks pcre3 migration
<xnox> ginggs, firewall upgrades? =)
<infinity> xnox: I assume that's a local loopback.
<infinity> Certainly looks like it should be.
<infinity> So, something lxc/lxdish is going on there.
<infinity> Laney: ^
<Laney> Yes?
<Laney> Did someone run it locally?
<ginggs> Laney: not on the affected architectures
<xnox> ginggs, locally on amd64 but with e.g. lxd runner
<infinity> Oh.  Or.
<infinity> ginggs: It could be as simple as the test not depending on net-tools, and those chroots being "cleaner"?
<infinity> Since the tests uses 'netstat' to determine if the port is open, and netstat was demoted out of essential.
<ginggs> ah, ok, let me try locally with lxd runner
<infinity> On 2017-01-27
<infinity> Which would sort of match your timeline.
<xnox> oooooh
<infinity> Of course, I'm having a heck of a time finding the string netstat here now. :P
<infinity> Ah-ha.
<infinity> Found it.
<infinity> ginggs: Assuming it's not LXC screwing with you, but just the net-tools demotion, then my ruby-specinfra upload will fix it.
-queuebot:#ubuntu-release- Unapproved: ruby-specinfra (zesty-proposed/universe) [2.66.0-1 => 2.66.0-1ubuntu1] (no packageset)
<infinity> ginggs: https://launchpad.net/ubuntu/+source/ruby-specinfra/2.66.0-1ubuntu1
-queuebot:#ubuntu-release- Unapproved: accepted ruby-specinfra [source] (zesty-proposed) [2.66.0-1ubuntu1]
<ginggs> infinity: ta!
<infinity> (If it is an LXC issue, my upload is still correct, it just might not fix your bug :P)
<Laney> https://paste.ubuntu.com/24260974/
<LocutusOfBorg> hello apw, or any AA, can you please move libboost-filesystem-dev to main?
<LocutusOfBorg> I'm working to remove boost1.61 and mir is unhappy
<infinity> Laney: Kay, so it's LXC not letting us bind to some ports?
<Laney> No
<infinity> Oh, I misread.
<infinity> It's net-tools.  Check.
<infinity> So, we have an inverse bug that some of our testing chroots aren't clean enough.
<infinity> Laney: I somehow read the second run as a failure.  In my defense I just woke up. ;)
<LocutusOfBorg> BTW boost-default is already in main, not sure why it is half in universe
<infinity> LocutusOfBorg: Reference to mir unhappiness?
<LocutusOfBorg> mirtest-dev/amd64 unsatisfiable Depends: libboost-filesystem-dev
<infinity> It being half in universe is correct, as only the bits with deps end up in main.
<LocutusOfBorg> oh indeed
<LocutusOfBorg> my bad, to make mir less pita during boost transitions, we ended up in depending on the -dev package
<LocutusOfBorg> instead of the runtime one
<LocutusOfBorg> http://launchpadlibrarian.net/312291835/mir_0.26.2+17.04.20170322.1-0ubuntu1_0.26.2+17.04.20170322.1-0ubuntu2.diff.gz
<LocutusOfBorg> such stuff -         libboost-filesystem1.61.0 | libboost-filesystem1.58.0 | libboost-filesystem1.55.0,
<LocutusOfBorg> is unmaintainable
<LocutusOfBorg> +         libboost-system-dev, <-- this is really better to me
<LocutusOfBorg> so, at the end just the -dev package needs promoting
<LocutusOfBorg> to make the whole Borg community happy
 * LocutusOfBorg BTW nice article on slashdot wrt Ubuntu Beta!
<infinity> That should show up on component-mismatches-proposed.  Did that change *just* get uploaded?
<infinity> Yeah, it did.
<infinity> So, our reports should yell at us shortly.  I might wait on that to see if they say something else.
<LocutusOfBorg> as you wish :) yes, I'm working on removing boost1.61 from main/archive
<philroche> infinity: RE. gce-compute-image-packages lp:1668327 Patches for all suites in -proposed have been verified. GCE are eager to get this released, would you be able to move these from -proposed to -updates? https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1668327
<ubot5> Ubuntu bug 1668327 in gce-compute-image-packages (Ubuntu Yakkety) "Startup scripts get run when guest packages are updated" [Medium,Fix committed]
<infinity> philroche: Sure thing.
<philroche> infinity: Thanks
<infinity> LocutusOfBorg: Err, that mir upload is still wrong.
<infinity> LocutusOfBorg: If your goal is to remove all boost << 1.62, not removing the versioned deps won't get you far. :P
<infinity> LocutusOfBorg: Oh.  OR I MISSED THE '-' in the diff.
<infinity> Man, I really need to wake up before I type.
<infinity> Nevermind me. :P
<mapreri> man, I was already yelling :|
<mapreri> infinity: don't do it again! :>
<infinity> I think I should find some breakfast and/or coffee before I continue.
<infinity> Two "I can't read" moments within half an hour isn't a good record.
<mapreri> coffee that way -------->
<jbicha> any Archive Admin interested in reviewing switcheroo-control in the Zesty new queue? it's a small pkg required for GNOME 3.24's dual gpu feature
<ginggs> infinity: your ruby-specinfra upload did indeed fix varnish autopkgtests, thanks
<infinity> ginggs: \o/
-queuebot:#ubuntu-release- Unapproved: binutils-m68hc1x (zesty-proposed/universe) [1:2.18-8 => 1:2.18-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted binutils-m68hc1x [sync] (zesty-proposed) [1:2.18-9]
-queuebot:#ubuntu-release- Unapproved: lvm2 (zesty-proposed/main) [2.02.167-1ubuntu2 => 2.02.167-1ubuntu5] (core)
<LocutusOfBorg> lol infinity <3
<LocutusOfBorg> the problem is not ENOCOFFEE
<LocutusOfBorg> but EMONDAY
<LocutusOfBorg> you are not alone
<LocutusOfBorg> in Italy we just had daylight saving time switch, and I did woke up one hour before today, so my body has a two hours "jet lag" right now :)
-queuebot:#ubuntu-release- Unapproved: s390-tools (zesty-proposed/main) [1.37.0-0ubuntu2 => 1.37.0-0ubuntu3] (core)
<xnox> oh we are in the full frozen mode now.... horum.
<infinity> xnox: A cherrypick that adds the new version to the changelog doesn't seem like a cherrypick?  What's the difference between this and just updating to the point release?
<infinity> stgraber: That lvm2 upload is a bit wonky.  It seems to entirely scrub the previous versions from history?
<infinity> stgraber: http://launchpadlibrarian.net/312918372/lvm2_2.02.167-1ubuntu4_2.02.167-1ubuntu5.diff.gz
<xnox> infinity, 342 files changed, 3778 insertions(+), 3688 deletions(-) of refactor; rewriting of argument parsing; whitespace changes; and header includes reordering.
<xnox> https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1671497/comments/4
<ubot5> Ubuntu bug 1671497 in s390-tools (Ubuntu) "[17.04 - FEAT] Upgrade s390tools to version 1.37.1" [Low,In progress]
<xnox> and minor renames of files and/or macros
<infinity> xnox: Ahh, so maybe the bit here that's rubbing me the wrong way is you adding "1.37.1" news items to README, which implies this is 1.37.1
<infinity> xnox: When really, it's 1.37.0 with a couple of upstream cherrypicks.
<xnox> well i've cherrypicked all the worthy fixes.... all of which are described by the changelog entry, hence the pick up of the changelog entry too.
<infinity> xnox: Yeah, but the way you've rewritten the readme says "this is 1.37.1", which it isn't.
<infinity> Not even close.
<xnox> true
<infinity> This is what patch headers are for.  Don't muck with the upstream README, IMO.
<xnox> i could take those changelog entries out of the patch; and stick them into debian/changelog instead?!
<xnox> patch header is not end-user visible....
<infinity> The debian changelog being more verbose also is never a bad idea.
<infinity> Patch headers should record origin (assuming this was from a VCS, not just a diff of a tarball), and debian/changelog can absolutely document the bugs fixed.
<xnox> public VCS :`(
<xnox> there is this java webapp one has to click through to get to the tarball and accept GPL EULA
<infinity> Mucking with the upstream readme would be more acceptable to me if you documneted the changes under "1.37.0 + Ubuntu patches" or something, but it still seems gross to document it there.
<infinity> Hahahaha.  Have you told them that's BS?  We've done so in the past (with IBM even, I think), and won the argument.
<infinity> Since the GPL explicitly places no burden on people downloading, only people redistributing.
<infinity> Thus it's not an EULA at all.
<xnox> i have. and they started to download the tarball and attach it to a launchpad bug reports for me.
<infinity> *cough*
<infinity> I'm laughing too hard to type.
 * xnox now feels for real to be back from vacation
<xnox> There was cause and effect and change of behaviour.... but an enterpice solution with a personal butler service.
<infinity> Wow.  You win the creative spelling of the day award.
<infinity> apw: Sorry, xnox's "enterpice" beats anything you'll come up with today.
<rbalint> hi, who should be pinged for binary package removals? LP: #1671423
<ubot5> Launchpad bug 1671423 in kineticstools (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1671423
<philroche> infinity: Thanks for the gce-compute-image-packages work :)
<infinity> rbalint: A quick investigation looks like that bug should be titled "bcftools is FTBFS on 32-bit arches"?
<xnox> infinity, i have not been typing on a keyboard for a whole week. (there was no wifi at the slope of the resort, where i was staying) my words per minute are way down.
<infinity> Or... Some arches.
<xnox> infinity, i already talked today about the release meetings at bluefun with pat as well.
<rbalint> infinity: well it looks unlikely to be fixed #819617
<rbalint> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819617  FTBFS: any-i386 - floating point idiosyncracies
<ubot5> Debian bug 819617 in src:bcftools "FTBFS: any-i386 - floating point idiosyncracies" [Important,Open]
<rbalint> rbalint: rbalint more patience :-)
<rbalint> rbalint: infinity and kineticstools does not migrate due to the missing build
<infinity> rbalint: Well, that was a long read.  Tempted to go read the upstream report too, but I have better things to do. ;)
<rbalint> infinity: did not want to push you that far :-)
<mapreri> apw: should I suppose you didn't manage to push the armhf timeout change to autopkgtest workers?  (re: diffoscope timeouting)
<infinity> rbalint: Done.
<rbalint> infinity: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected s390-tools [source] (zesty-proposed) [1.37.0-0ubuntu3]
<infinity> jibel: Ugh.  That ubuntu-ui-extras upload is very not feature-freeze friendly.
<stgraber> infinity: hmm, I wonder what's going on here... I uploaded 0ubuntu2 a couple weeks back and nothing since
-queuebot:#ubuntu-release- New sync: ubuntu-filemanager-app (zesty-proposed/primary) [0.4+17.04.20170323-0ubuntu1]
<infinity> stgraber: https://launchpad.net/ubuntu/+source/lvm2/+publishinghistory
<stgraber> infinity: and rmadison tells me the only lvm2 in zesty right now is 2.02.167-1ubuntu2 (nothing in zesty-proposed)
<infinity> stgraber: publishing history shows some upload and the deletion action?
<infinity> s/the/then/
<infinity> stgraber: By you, even. :P
<infinity> stgraber: So, okay, let me diff against ubuntu2 to get something more readable.
<stgraber> infinity: ah, yeah, almost forgot about that. It was a mistargeted PPA upload that made it to proposed and that I wiped from the archive before it had a chance to build
<infinity> stgraber: Yep, the diff against ubuntu2 is indeed much more readably sane.  Accepting.
-queuebot:#ubuntu-release- Unapproved: isso (zesty-proposed/universe) [0.10.6-2 => 0.10.6-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted isso [source] (zesty-proposed) [0.10.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (zesty-proposed) [2.02.167-1ubuntu5]
<infinity> slangasek: When the personal/unity8/whatever session landed in the default install, did we also do away with their blanket exception to abuse freezes?  I suspect we should have, not sure if we explicitly did?
<infinity> (Asking because of a current landing that is very freeze-unfriendly)
<infinity> (Which only affects the unity8 session)
<infinity> (More stuff in brackets)
<jibel> infinity, agreed it is not freeze friendly at all
<jibel> infinity, hence my question last week if we could have an overlay for zesty, a blanket exception would work too
 * infinity fixed ubuntu-archive-tools a bit better for powerpc removal.
<davmor2> ( infinity ) thought I'd put you in () being as you loved them so much
<infinity> jibel: My preference would be for removing the unity8 session from the default install, but I suspect I'd lose that argument. :/
<jibel> infinity, right, that would stay your preference
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (zesty-proposed/universe) [8.2-0ubuntu1 => 8.2-0ubuntu2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-proposed/main) [1:0.196.22 => 1:0.196.23] (core)
<slangasek> infinity, jibel: what's freeze-unfriendly about it?  unity8 is supposed to have strong upstream CI such that the release team should feel comfortable granting exceptions
<infinity> slangasek: Did you look at the diff before making that statement?
<slangasek> no, of course not
<slangasek> what's in the diff? :)
<infinity>  127 files changed, 6353 insertions(+), 1101 deletions(-)
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (trusty-proposed) [1:0.196.23]
<infinity> http://paste.ubuntu.com/24261929/
<bdmurray> rbasak: I fix update-manager thanks for spotting that!
<infinity> slangasek: I'm sure their CI is lovely, but that's a whole lot of change.
<slangasek> infinity: ok. does it change the packaging?
<infinity> And I don't buy the "upstream's CI is so good we don't care about freezes anymore" argument, or we'd take new versions of a lot more software than we do.
<infinity> slangasek: No, it doesn't change the packaging.  How's that relevant?
<slangasek> lots of upstreams have CI.  not a lot of upstreams have CI that it's been worth our time to grant exceptions around
<slangasek> it's relevant because we should be able to trust upstream to be the authority on the quality of their code, and we should only have to get involved for integration questions
-queuebot:#ubuntu-release- Unapproved: xorg-server (zesty-proposed/main) [2:1.18.4-1ubuntu9 => 2:1.19.3-1ubuntu1] (desktop-core, xorg)
<jibel> slangasek, it adds printing support to ubuntu-system-settings
<jibel> ie not a bug fix
<jibel> OTOH, it has CI + manual verification of the silo
<infinity> slangasek: So, I understand that's the argument we used for ci-train landings, I don't think we EVER used it for freeze exceptions.  The exception they had previously was based on the code not being delivered with the regular distro cadence.
<infinity> slangasek: And I still don't buy the "Canonical upstreams are unique snowflakes wrt CI" argument.  Saying it doesn't make it true.
<slangasek> I didn't say they were unique snowflakes
<slangasek> what I'm saying is that if there are other upstreams with strong CI that are worth our effort to develop exceptions for, I would be ok with that
<infinity> So, you'd be happy with new systemd upstream versions breaking freezes?
<slangasek> I'm not sure I would consider systemd upstream's CI "strong", the coverage might be a bit weak
<slangasek> I do actually in principle prefer having that package in a state that we can rely on the CI instead of constantly worrying about what may have broken with a package update
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.0-0ubuntu3 => 2:10.0.0-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: linux-signed (zesty-proposed/main) [4.10.0-14.16 => 4.10.0-15.17] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (zesty-proposed/main) [4.10.0-14.16 => 4.10.0-15.17] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (zesty-proposed/main) [4.10.0.14.16 => 4.10.0.15.17] (core, kernel) (sync)
<infinity> rtg: Aww, crap.  Did my request just miss a new upload? :P
<infinity> Oh well.
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (zesty-proposed/universe) [2:10.0.0-0ubuntu1 => 2:10.0.0-0ubuntu2] (openstack)
<rtg> infinity, well, -15 was already built in the PPA. It'll show up in -16
<infinity> rtg: Off-by-1 error?  That's 14.
<rtg> infinity, I just promoted -15 to -proposed
<infinity> rtg: Oh, off-by-dumb error, I was reading the left side of queuebot's messages. ;)
<rtg> infinity, your patch will make kernel freeze (in -16)
<infinity> rtg: Ta.  It's currently making my tools lie, so I'm hoping to see that clear up.
<nacc> infinity: would you be willing to process the src:vm-builder removal for 17.04? I think it would also require removing src:sandbox-upgrader and I'm not sure if the latter is used by the release team or not (i'm assuming not given that it's in universe)
<nacc> infinity: LP: #1618899
<ubot5> Launchpad bug 1618899 in vm-builder (Ubuntu) "vmbuilder fails with dist-upgrade with release xenial; remove vm-builder from zesty" [Low,Triaged] https://launchpad.net/bugs/1618899
<infinity> rtg: Due to powerpc removal, the config/ changes are unreviewable (as expected).  Can you swear on a stack of bibles that nothing actually changed beyond "remove powerpc && updateconfigs"?
<infinity> Oh, I guess I could review the final configs from the binaries instead.  I might do that to be paranoid.
-queuebot:#ubuntu-release- Unapproved: munin (trusty-proposed/main) [2.0.19-3ubuntu0.3 => 2.0.19-3ubuntu0.4] (ubuntu-server)
<rbalint> is there anything to be done for LP: #1672941 ?
<ubot5> Launchpad bug 1672941 in cyrus-sasl2 (Ubuntu) "FTBFS with older versions of OpenSSL" [High,New] https://launchpad.net/bugs/1672941
-queuebot:#ubuntu-release- Unapproved: stress-ng (zesty-proposed/universe) [0.07.26-1 => 0.07.27-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (zesty-proposed) [0.07.27-1]
<rtg> infinity, only one config change other then powerpc, "UBUNTU: [Config] CONFIG_PINCTRL_GEMINILAKE=m"
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu1 => 2:8.4.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.2.0-0ubuntu1 => 2:9.2.0-0ubuntu2] (openstack, ubuntu-server)
<infinity> rtg: Kay, I'm diffing config-$(uname -r) from the binaries to confirm.
-queuebot:#ubuntu-release- Unapproved: mate-desktop (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (xenial-proposed/main) [2:8.3.0-0ubuntu2 => 2:8.3.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
<tjaalton> i've uploaded xorg-server update to zesty, it was acked by Laney
<mapreri> http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.62.html
<mapreri> this was last generated the 21st.  What happened?
<barry> any thoughts on what we should do about emacs25.1+1-3ubuntu3?  It's been held up for several weeks due to failing/crashing tests on arm64  all other arches are fine.
<nacc> barry: dannf has been looking into it
<nacc> barry: but it's not easily reproducible, unfortunately
<dannf> yeah, i haven't been able to reproduce it all for weeks now
<nacc> barry: and it appears that it may have been happening for some time
<barry> nacc, dannf thanks for looking into it.  have either of you looked to see if upstream has a bug on that?  i could look if you haven't yet.
<dannf> barry: i did at the time and didn't see one. i also tried to reproduce w/ all usptream code back when i could reproduce it, and i couldn't break upstream
<nacc> barry: i've not done any digging beyond what dannf has done -- i just have packages blocked by it :)
<barry> dannf: that's interesting.  so perhaps it's a debian or ubuntu delta?
<barry> nacc: :)
<dannf> barry: my hope was that i could reproduce it in debian and get a bug filed there - iirc, the build failure is correlated with the REL_ALLOC=no change in debian
<barry> i don't see anything in a quick search of gmame.emacs.bugs
<barry> dannf: gotcha.  well, if i can help in any way, please do ping.  i don't have direct access to arm64 h/w tho.
<dannf> barry: there's a canonical porterbox, but when i could reproduce it, it was only in a vm
<barry> dannf: yep
<dannf> barry: i'm sure we could provide you with hw access though
<barry> dannf: that would be great
<dannf> doko: is the mcdivitt you have deployed from our maas shareable?
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (zesty-proposed) [2:1.19.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (zesty-proposed) [4.10.0-15.17]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (zesty-proposed) [2:10.0.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-settings-daemon [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (zesty-proposed) [8.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (zesty-proposed) [4.10.0.15.17]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (zesty-proposed) [4.10.0-15.17]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-15.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-15.17]
-queuebot:#ubuntu-release- New: accepted nama [sync] (zesty-proposed) [1.208-1]
-queuebot:#ubuntu-release- New: accepted sdpb [sync] (zesty-proposed) [1.0-3]
<rbalint> barry: you probably also saw in #842852 that emacs25.1+1-3 seems to fix crashes on amd64
<rbalint> barry: letting it migrate manually seems to be a better state for zesty, maybe we hit a VM bug on arm64?
<infinity> Letting it migrate "manually" breaks a ton of rdeps.
-queuebot:#ubuntu-release- New binary: sdpb [ppc64el] (zesty-proposed/none) [1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: sdpb [s390x] (zesty-proposed/none) [1.0-3] (no packageset)
-queuebot:#ubuntu-release- Packageset: 70 entries have been added or removed
<infinity> emacs isn't exactly a leaf package.
-queuebot:#ubuntu-release- New binary: sdpb [arm64] (zesty-proposed/none) [1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: sdpb [i386] (zesty-proposed/none) [1.0-3] (no packageset)
<infinity> As much as I wish it were, so I could remove it from the archive and tell barry to just snap it instead. :P
-queuebot:#ubuntu-release- New binary: sdpb [amd64] (zesty-proposed/universe) [1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: sdpb [armhf] (zesty-proposed/universe) [1.0-3] (no packageset)
<barry> >:-|
<infinity> :)
 * barry joins forces with rbalint 
<barry> rbalint: it looks like 842852 might already be fixed with -3 so we should try to get that through proposed first
<infinity> Is it possible that it's the backtrace code that's choking, and fixing the warnings spit out in the build would paper over it?
<infinity> Curiously, the Debian build doesn't throw warning on that same .el file (though it does on later ones).
<infinity> That's a bit WTF.
<barry> infinity: i was thinking something similar
<barry> yeah
<nacc> infinity: yeah, that's what made it a bit confusing
<nacc> infinity: iirc, dannf's debugging
<nacc> infinity: and we were trying to guess if the parallel=1 fix just papered over it before, but don't anymore (at least not consistently)
<infinity> I also wonder if building on real hardware would fix it.
<nacc> right
<infinity> Cause we still have the power to do that.
<infinity> Err, I might have the power to do that.  Maybe not.
<nacc> i think that would be worth trying, if its possible :)
<dannf> infinity: i think it is likely that real hw woudl fix it
<infinity> That's disconcerting.
<barry> indeed
-queuebot:#ubuntu-release- Unapproved: xorg-server (zesty-proposed/main) [2:1.18.4-1ubuntu9 => 2:1.19.3-1ubuntu1] (desktop-core, xorg)
<tjaalton> Laney: new attempt ^
-queuebot:#ubuntu-release- Unapproved: julia (zesty-proposed/universe) [0.4.7-6 => 0.4.7-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted julia [source] (zesty-proposed) [0.4.7-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: eject (zesty-proposed/main) [2.1.5+deb1+cvs20081104-13.1 => 2.1.5+deb1+cvs20081104-13.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (zesty-proposed/main) [20101020ubuntu500 => 20101020ubuntu501] (core)
<tsimonq2> infinity: Is there any chance you would let a new Lubuntu slideshow package in to Zesty within the next... idk... week? that would fix some glaring problems
<infinity> tsimonq2: Yup.
<infinity> tsimonq2: Slideshows kinda get a pass for obvious reasons.  You can't take screenshots of your finished product until post-freeze, when it's finished.
<infinity> cyphermox: Which reminds me, do we have a slideshow update for Ubuntu for zesty, or is that going to be the usual last-minute panic?
<infinity> Wow, it's had three revisions in zesty!
<infinity> A miracle.
<tsimonq2> infinity: bug 1633148 and another bug which shows our incorrect website is in a screenshot (lubuntu.net which someone is squatting versus lubuntu.me, our new one)
<ubot5> bug 1633148 in ubiquity (Ubuntu) "Lubuntu 16.10 slideshow still incorrectly showing Lubuntu Software Center" [Undecided,New] https://launchpad.net/bugs/1633148
<tsimonq2> infinity: That would be the main fixes.
<tsimonq2> infinity: But I'm glad for the ack, thank you. :)
<infinity> tsimonq2: Yeah, all good.
<tsimonq2> infinity: Yeah, gilir was having doubts about uploading a slideshow at this point because of FF, I'll let him know you gave it an ack ;)
<tsimonq2> infinity: He still hasn't gotten back to me on lubuntu-next yet, fyi
-queuebot:#ubuntu-release- Unapproved: runc (zesty-proposed/universe) [1.0.0~rc2-0ubuntu3 => 1.0.0~rc2+docker1.12.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (zesty-proposed) [1.0.0~rc2+docker1.12.6-0ubuntu1]
<bdmurray> infinity: Are you doing any SRU work today? I've a couple of uploads I'd prefer not to self-approve.
<infinity> bdmurray: rbasak was taking my day, but I can look at a couple, I suspect he's EOD by now.
<bdmurray> infinity: its update-manager & update-notifier in T and X, somebody already approved Y.
<infinity> bdmurray: Way to look out for 2038 in a punctual manner.
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (trusty-proposed) [1:0.196.23]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (trusty-proposed) [0.154.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.4]
<infinity> bdmurray: Done.
<bdmurray> infinity: thanks
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.6]
-queuebot:#ubuntu-release- Unapproved: caja-dropbox (zesty-proposed/multiverse) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
<cyphermox> infinity: it's still a panic
<cyphermox> infinity: I'm mangling the translations right now, about to test it
<infinity> cyphermox: I dunno, I see an upload 7 days ago that looks promising.
<cyphermox> it looks promising except for all the places where it still says 16.10.
<infinity> \o/
-queuebot:#ubuntu-release- Unapproved: zfs-linux (zesty-proposed/main) [0.6.5.9-5ubuntu1 => 0.6.5.9-5ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (zesty-proposed) [0.6.5.9-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (zesty-proposed) [20101020ubuntu501]
-queuebot:#ubuntu-release- Unapproved: accepted eject [source] (zesty-proposed) [2.1.5+deb1+cvs20081104-13.1ubuntu1]
<infinity> flexiondotorg: That caja XDG_CURRENT_DESKTOP change will have a lot of knock-on effects.  Can you not just yell at dropbox instead?
<infinity> flexiondotorg: Or is that somehow limited to only being in the environment when dealing with dropbox itself?
<flexiondotorg> infinity So I discussed this with Laney earlier.
<flexiondotorg> I've also prepare a debdiff for nautilus-dropbox, that checks if XDG_CURRENT_DESKTOP includes 'Unity' before exporting a modified environment.
<flexiondotorg> I've tried, and am still trying, to get the attention of Dropbox.
<infinity> flexiondotorg: Okay, maybe I'm mireading this.  Is the environment here limited to running some dropbox binary, and not being pushed back to the user's desktop environment?
<flexiondotorg> The caja-dropbox changes is deliberately made this way so all DE can benefit.
<flexiondotorg> LXDE, XFCE and MATE have been using my patched caja-dropbox for about a year now.
<infinity> Question not being answered. :)
<flexiondotorg> The environment change it just in the content of the Dropbox binary, not the whole session.
<infinity> Right, okay.  Then it's fine.  I mean, super gross, but fine.
<infinity> It was that context I was missing.
<flexiondotorg> I was getting there :-)
<infinity> Cause in the desktop session, claiming to be another DE ends up doing VERY WEIRD THINGS.
<flexiondotorg> Indeed.
<flexiondotorg> Laney asked me to fix nautilus-dropbox, the debdiff is ready and the approach used there was agreed with Laney.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/1559249/comments/7
<ubot5> Ubuntu bug 1559249 in nautilus-dropbox (Ubuntu) "Dropbox indicator is broken on non-Unity environments" [High,Triaged]
<infinity> Oh, you no can upload that?
<flexiondotorg> I have no super powers.
<infinity> Slacker.
<flexiondotorg> Says you. It's 00:45 here ;-)
<flexiondotorg> infinity So if you can take a look at the debdiff for nautilus-dropbox that would be grand.
<flexiondotorg> http://www.webupd8.org/2017/03/fix-dropbox-indicator-menu-not-working.html
<infinity> flexiondotorg: So, I like the nautilus diff better, from my paranoid POV.
<flexiondotorg> Yep.
<infinity> flexiondotorg: As you're clearly only applying that env to the Popen.
<infinity> flexiondotorg: Don't suppose that same clarity could be applied to the caja one?
<flexiondotorg> Like I say, caja-cropbox is being used by XFCE and LXDE users too.
<infinity> Yes...
<infinity> I just mean, use the env.copy, then pass new_env trick.
<infinity> Since changing os.env directly is less obviously not a leak.
<flexiondotorg> And, in my testing, without passing a faux XDG_CURRENT_DESKOP recent Dropbox just doesn't work.
<flexiondotorg> So use the say limit for just MATE in caja-dropbox?
<infinity> I don't need you to explain the fix any more.  I get it.  I'm just asking it to look like the nautilus fix.
<infinity> (minus the if)
<flexiondotorg> Ah, right.
<flexiondotorg> Can do.
<infinity> ie: new_env = os.environment.copy(); new_env['XDG_CURRENT_DESKTOP'] = 'Unity'; sub.Popen(blah, env=new_env)
<flexiondotorg> Wilco
<infinity> Thanks.  I'm not an expert on python and os.env, but altering the environment directly when you really care about the env of a fork makes me twitch a bit.
<infinity> So, better safe than lolz.
<infinity> And I'll sponsor the nautilus fix for you, looks sane enough.
<flexiondotorg> infinity Cheers. I'll let Laney know in the morning. I'll rework the caja-dropbox patch.
<infinity> Ta.
-queuebot:#ubuntu-release- Unapproved: rejected caja-dropbox [source] (zesty-proposed) [1.18.0-0ubuntu2]
<infinity> flexiondotorg: Please use update-maintainer to update maintainers on Ubuntu changes, rather than setting the maintainer to yourself. ;)
<infinity> flexiondotorg: Fixed that and the version number, and uploaded.
<flexiondotorg> infinity OK. Noted. First time doing a change like that.
-queuebot:#ubuntu-release- Unapproved: aptdaemon (yakkety-proposed/main) [1.1.1+bzr982-0ubuntu16.1 => 1.1.1+bzr982-0ubuntu16.2] (kubuntu, ubuntu-desktop)
<flexiondotorg> infinity Thanks.
-queuebot:#ubuntu-release- Unapproved: nautilus-dropbox (zesty-proposed/multiverse) [2015.10.28-1 => 2015.10.28-1ubuntu1] (xubuntu)
#ubuntu-release 2017-03-28
-queuebot:#ubuntu-release- Unapproved: accepted nautilus-dropbox [source] (zesty-proposed) [2015.10.28-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted sdpb [amd64] (zesty-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted sdpb [armhf] (zesty-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted sdpb [ppc64el] (zesty-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted sdpb [arm64] (zesty-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted sdpb [s390x] (zesty-proposed) [1.0-3]
-queuebot:#ubuntu-release- New: accepted sdpb [i386] (zesty-proposed) [1.0-3]
<tsimonq2> infinity: TIL, I've been doing it manually this whole time...
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [121 => 122] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.1.4+bzr5591-0ubuntu1~16.04.1 => 2.1.5+bzr5596-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.4+bzr5591-0ubuntu1~16.10.1 => 2.1.5+bzr5596-0ubuntu1~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2-0ubuntu2~16.04.1 => 1.0.0~rc2+docker1.12.6-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (yakkety-proposed/universe) [1.0.0~rc2-0ubuntu2~16.10.1 => 1.0.0~rc2+docker1.12.6-0ubuntu1~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hw-detect (zesty-proposed/main) [1.117ubuntu3 => 1.117ubuntu4] (core)
<flexiondotorg> infinity I've uploaded a reworked caja-dropbox
<flexiondotorg> Time for sleeping Z z .
-queuebot:#ubuntu-release- Unapproved: caja-dropbox (zesty-proposed/multiverse) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyboard (zesty-proposed/main) [0.100+17.04.20170301-0ubuntu1 => 0.100+17.04.20170320-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: yp-tools (zesty-proposed/universe) [3.3-5 => 3.3-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yp-tools [source] (zesty-proposed) [3.3-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (zesty-proposed/universe) [56-1 => 57-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [sync] (zesty-proposed) [57-1]
<infinity> flexiondotorg: Looks better.  Not sure why you changed the build-depends, though. :P
<infinity> flexiondotorg: But it's basically a no-op at this point in the cycle, so meh.
 * infinity goes to sleep now.
-queuebot:#ubuntu-release- Unapproved: accepted caja-dropbox [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (zesty-proposed) [1.117ubuntu4]
<tjaalton> infinity: mind letting xorg-server pass so that it would be built. the ffe is acked
<infinity> tjaalton: How much did you pay Laney for that ACK?
<tjaalton> hehe
<tjaalton> passively waiting for someone to act on the bug didn't work out
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (zesty-proposed) [2:1.19.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xf86-input-mtrack (zesty-proposed/universe) [0.3.1-1build1 => 0.3.1-1build2] (xorg)
-queuebot:#ubuntu-release- Unapproved: xf86-input-xwiimote (zesty-proposed/universe) [0.5-1build2 => 0.5-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-xwiimote [source] (zesty-proposed) [0.5-1build3]
<tjaalton> wi n29
<tjaalton> uh
-queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (zesty-proposed/main) [1:0.33.0-0ubuntu1 => 1:0.34.0-0ubuntu2] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-aiptek (zesty-proposed/universe) [1:1.4.1-2 => 1:1.4.1-2build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-evdev (zesty-proposed/universe) [1:2.10.2-1ubuntu1 => 1:2.10.5-1ubuntu1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-elographics (zesty-proposed/universe) [1:1.4.1-1build5 => 1:1.4.1-1build6] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-mutouch (zesty-proposed/universe) [1:1.3.0-1build8 => 1:1.3.0-1build9] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-joystick (zesty-proposed/universe) [1:1.6.3-1 => 1:1.6.3-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-void (zesty-proposed/universe) [1:1.4.1-1build2 => 1:1.4.1-1build3] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (zesty-proposed/main) [0.23.0-2 => 0.25.0-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-synaptics (zesty-proposed/main) [1.8.3-1ubuntu1 => 1.9.0-1ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (zesty-proposed/main) [1.2.0-1 => 1.3.0-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (zesty-proposed/main) [1:7.8.0-1 => 1:7.9.0-0ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-dummy (zesty-proposed/main) [1:0.3.8-1 => 1:0.3.8-1build1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode (zesty-proposed/universe) [2.11.19-1 => 2.11.19-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-neomagic (zesty-proposed/universe) [1:1.2.9-1build2 => 1:1.2.9-1build3] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-fbdev (zesty-proposed/main) [1:0.4.4-1build5 => 1:0.4.4-1build6] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-mach64 (zesty-proposed/universe) [6.9.5-1build2 => 6.9.5-1build3] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-openchrome (zesty-proposed/universe) [1:0.5.0-3 => 1:0.5.0-3build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-r128 (zesty-proposed/universe) [6.10.2-1 => 6.10.2-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-sisusb (zesty-proposed/universe) [1:0.9.7-1 => 1:0.9.7-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-trident (zesty-proposed/universe) [1:1.3.8-1 => 1:1.3.8-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl (zesty-proposed/main) [0.1.4-3ubuntu3 => 0.1.5-2build1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-tdfx (zesty-proposed/universe) [1:1.4.7-1 => 1:1.4.7-1build1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-savage (zesty-proposed/universe) [1:2.3.8-1ubuntu3 => 1:2.3.9-1ubuntu1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vesa (zesty-proposed/main) [1:2.3.4-1build2 => 1:2.3.4-1build3] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vmware (zesty-proposed/main) [1:13.1.0-2ubuntu3 => 1:13.2.1-1build1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel (zesty-proposed/main) [2:2.99.917+git20160706-1ubuntu1 => 2:2.99.917+git20170309-0ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-siliconmotion (zesty-proposed/universe) [1:1.7.8-1ubuntu6 => 1:1.7.9-2ubuntu1] (xorg)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau (zesty-proposed/main) [1:1.0.13-1 => 1:1.0.14-0ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: mosh (zesty-proposed/universe) [1.3.0~rc2-1 => 1.3.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mosh [sync] (zesty-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- Unapproved: oxide-qt (zesty-proposed/main) [1.20.4-0ubuntu1 => 1.21.5-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
<apw> tjaalton, i assume all of the deps between these x things are expressed in packaging so we can accept them randomly and things will work ?
<tjaalton> apw: right, the xserver is built there already. maybe ack one and I'll verify the build log just to be sure..
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-mtrack [source] (zesty-proposed) [0.3.1-1build2]
<apw> tjaalton, ^
<apw> tjaalton, and this is all under an FFE already right ?
<tjaalton> yep
<tjaalton> apw: looks good
<apw> tjaalton, ta
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-aiptek [source] (zesty-proposed) [1:1.4.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-elographics [source] (zesty-proposed) [1:1.4.1-1build6]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-joystick [source] (zesty-proposed) [1:1.6.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-mutouch [source] (zesty-proposed) [1:1.3.0-1build9]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-void [source] (zesty-proposed) [1:1.4.1-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-dummy [source] (zesty-proposed) [1:0.3.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-fbdev [source] (zesty-proposed) [1:0.4.4-1build6]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode [source] (zesty-proposed) [2.11.19-1build1]
<Laney> aieeee
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-mach64 [source] (zesty-proposed) [6.9.5-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-neomagic [source] (zesty-proposed) [1:1.2.9-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-openchrome [source] (zesty-proposed) [1:0.5.0-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-r128 [source] (zesty-proposed) [6.10.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-sisusb [source] (zesty-proposed) [1:0.9.7-1build1]
<apw> Laney, ?
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-tdfx [source] (zesty-proposed) [1:1.4.7-1build1]
<Laney> all the accepts :-)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-trident [source] (zesty-proposed) [1:1.3.8-1build1]
<apw> and all in your name :)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vesa [source] (zesty-proposed) [1:2.3.4-1build3]
<Laney> ohohoho
 * Laney 's shoulders slope
 * apw adds a little gutter at the bottom of them and plumbs that into your trousers
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-wacom [source] (zesty-proposed) [1:0.34.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-evdev [source] (zesty-proposed) [1:2.10.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput [source] (zesty-proposed) [0.25.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: s390-tools (zesty-proposed/main) [1.37.0-0ubuntu2 => 1.37.0-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: storage-framework (zesty-proposed/universe) [0.2+17.04.20161212.1-0ubuntu1 => 0.3+17.04.20170320.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted storage-framework [sync] (zesty-proposed) [0.3+17.04.20170320.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics [source] (zesty-proposed) [1.9.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [source] (zesty-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [source] (zesty-proposed) [1:7.9.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl [source] (zesty-proposed) [0.1.5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-savage [source] (zesty-proposed) [1:2.3.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vmware [source] (zesty-proposed) [1:13.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel [source] (zesty-proposed) [2:2.99.917+git20170309-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (zesty-proposed/main) [1.0.13+17.04.20170307-0ubuntu1 => 1.0.13+17.04.20170324-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-siliconmotion [source] (zesty-proposed) [1:1.7.9-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau [source] (zesty-proposed) [1:1.0.14-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (zesty-proposed/main) [17.04.0-0ubuntu1 => 17.04.1-0ubuntu1] (ubuntu-desktop)
<caribou> apw: or anybody in the release team who can help, is it possible to review nfs-utils which has been stucked in zesty-proposed for a while
<Laney> caribou: It's not waiting for review, it's waiting for the failing tests to be sorted out
-queuebot:#ubuntu-release- Unapproved: keyrings.alt (zesty-proposed/main) [1.3-1 => 2.2-1] (core) (sync)
<caribou> Laney: which test is failing, I don't see anything in excuse
<Laney> caribou: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nfs-utils ?
<ginggs> would someone please configure kineticstools autopkgtests to run on large instances?  amd64 and ppc64el tests both fail with 'OSError: [Errno 12] Cannot allocate memory' now
<Laney> why did that happen?
<ginggs> new version, new tests.  It has only tried to run its tests now that i386 binaries were removed
<Laney> ok, done
<ginggs> Laney: ta!
-queuebot:#ubuntu-release- Unapproved: diffoscope (zesty-proposed/universe) [80 => 81] (no packageset) (sync)
<jibel> could someone review ubuntu-ui-extras/zesty, it's part of ubuntu-system-settings that landed yesterday?
<apw> jibel, hey i did look at that, it seemed to haave a lot of stuff in it, is that expected
-queuebot:#ubuntu-release- Unapproved: accepted diffoscope [sync] (zesty-proposed) [81]
<jibel> apw, yes, it adds printing support to ubuntu-system-settings. This is this landing https://bileto.ubuntu.com/#/ticket/2605
<jibel> apw, u-s-s, ubuntu-pinting-app and qtprint-ubuntu have been published to zesty, only u-ui-extras is missing
-queuebot:#ubuntu-release- Unapproved: networking-l2gw (zesty-proposed/universe) [1:1.0.0+git20170315.37fe94-0ubuntu1 => 1:10.0.0-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: vmware-nsx (zesty-proposed/universe) [9.0.0~git20160927.64c87d2-0ubuntu1 => 10.0.1~git20170317.bfa48c0-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted networking-l2gw [sync] (zesty-proposed) [1:10.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [sync] (zesty-proposed) [10.0.1~git20170317.bfa48c0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-extras [sync] (zesty-proposed) [0.3+17.04.20170323-0ubuntu1]
<apw> ^ though it is unclear whether this needed an FFE as the other half has been release we are in a mess if we do not have these in sync and the non-FFE has already been blown
<jibel> thanks
<Laney> they do, and we should be more strict from now I think
<Laney> at least I haven't heard about / been involved in discussions about any special exemptions this cycle
<apw> Laney, indeed, not sure how we got here, but not getting here again sounds good
<apw> Laney, there has been some discussion on unity8 session i think having one, but i am not convinced it came to concensus
<Laney> mmm
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.1 => 0.12.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (zesty-proposed) [122]
-queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (zesty-proposed) [1.0.13+17.04.20170324-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keyrings.alt [sync] (zesty-proposed) [2.2-1]
<Laney> xnox: DEP3 :(
<xnox> Laney, i have no origin.... i had to hand craft this from doing whitespace agnostic diff of tarballs.
<Laney> Origin: some random tarball on a bug <url> would be better than nothing imho
 * apw stands with Laney
 * Laney eyes queue fetch
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode (zesty-proposed/universe) [2.11.19-1build1 => 2.11.19-2] (xorg) (sync)
<Laney> why are you suspiciously slow
<apw> tjaalton, wtf ?  didn't i just review that build1 ?
<tjaalton> apw: dunno, someone synced it?
<apw> tjaalton, not you then ... hmmm
<tjaalton> nope
 * apw has a look at it ...
<tjaalton> looks innocent enough
<apw> tjaalton, yeah i see no reason to ding it, that same thing has happened to a lot of the otehrs in that set too
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode [sync] (zesty-proposed) [2.11.19-2]
<apw> tjaalton, ^ it is the same other than dbg package handling which matches many of the others
<tjaalton> right
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (zesty-proposed) [17.04.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted oxide-qt [sync] (zesty-proposed) [1.21.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.3 => 1.13.4-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3ubuntu0.2 => 1.13.4-3ubuntu0.3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: opentk (xenial-proposed/universe) [1.1.4c+dfsg-2 => 1.1.4c+dfsg-2ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opentk (yakkety-proposed/universe) [1.1.4c+dfsg-2 => 1.1.4c+dfsg-2ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (xenial-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu23.16.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (yakkety-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu23.16.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected activity-log-manager [source] (xenial-proposed) [0.9.7-0ubuntu23.1~xenial]
-queuebot:#ubuntu-release- Unapproved: rejected activity-log-manager [source] (yakkety-proposed) [0.9.7-0ubuntu23.1~yakkety]
-queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (yakkety-proposed) [0.9.7-0ubuntu23.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (xenial-proposed) [0.9.7-0ubuntu23.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (trusty-proposed) [0.9.7-0ubuntu14.2]
-queuebot:#ubuntu-release- Unapproved: openssh (yakkety-proposed/main) [1:7.3p1-1 => 1:7.3p1-1ubuntu0.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssh (xenial-proposed/main) [1:7.2p2-4ubuntu2.1 => 1:7.2p2-4ubuntu2.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (zesty-proposed/universe) [8.2-0ubuntu2 => 8.2.1-1ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: lernid (zesty-proposed/universe) [1.0.7 => 1.0.8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lernid [source] (zesty-proposed) [1.0.8]
-queuebot:#ubuntu-release- Unapproved: multipath-tools (xenial-proposed/main) [0.5.0+git1.656f8865-5ubuntu2.4 => 0.5.0+git1.656f8865-5ubuntu2.5] (core)
-queuebot:#ubuntu-release- Unapproved: virtualbox (zesty-proposed/multiverse) [5.1.18-dfsg-1 => 5.1.18-dfsg-1build1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (yakkety-proposed/main) [0.5.0+git1.656f8865-5ubuntu7.2 => 0.5.0+git1.656f8865-5ubuntu7.3] (core)
<LocutusOfBorg> apw, ^^^ virtualbox :D
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (zesty-proposed) [5.1.18-dfsg-1build1]
<LocutusOfBorg> ta
<tjaalton> indeed
-queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.0~beta3+bzr5815-0ubuntu1 => 2.2.0~beta4+bzr5856-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5ubuntu0.16.04.1 => 2.2.2-5ubuntu0.16.04.2] (mozilla, mythbuntu)
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (xenial-proposed) [2.2.2-5ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5ubuntu0.16.04.1 => 2.2.2-5ubuntu0.16.04.2] (mozilla, mythbuntu)
-queuebot:#ubuntu-release- Unapproved: vlc (yakkety-proposed/universe) [2.2.4-4ubuntu0.16.10.1 => 2.2.4-4ubuntu0.16.10.2] (mozilla, mythbuntu)
<kenvandine> can someone please accept ubuntu-keyboard?
<apw> kenvandine, that is pending (in my mind) on whether we have either an FFe or an outstanding exception as it has new functionality
<kenvandine> apw, i'm guessing not, but not sure what the procedure is now for the phone stuff
<tjaalton> I don't understand the onscripter/yorick test failures on new xorg-server, xvfb-run clearly works on other tests/archs and also locally..
 * Laney runs
<Laney> yep, fails the same
<Laney> autopkgtest --shell-fail -U --apt-pocket=proposed=src:xorg-server onscripter  -- qemu autopkgtest-zesty-amd64.img
<Laney> should be debuggable
<tjaalton> and that's not just any qemu img?
<Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<tjaalton> okay
<tjaalton> pretty sure i've been here before, but no idea where the images are :P
<Laney> there's a command there that builds it
<tjaalton> yes
<tjaalton> and apparently puts it in $pwd
<Laney> yap
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu1 => 232-21ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.2-1ubuntu1 => 17.0.2-1ubuntu2] (core, xorg)
<tjaalton> the doc could probably use the current binary name (autopkgtest-buildvm-ubuntu-cloud)?
<tjaalton> which has a manpage
<tjaalton> oh it's not on the wiki
<nacc> the old name is still an alias, iirc
<tjaalton> a symlink yes
<nacc> but yes, autopkgtest-*
<tjaalton> but had no manpage
<Laney> you mean https://bazaar.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk/revision/601 ?
<nacc> also that page is probably old :)
<nacc> heh
<tjaalton> Laney: haha :)
<nacc> it refers to bzr as being the way to get fixes in, e.g. (udd is still pretty widely documented last i checked)
<Laney> that guide has big problems
<Laney> the autopkgtest page is largely ok
<nacc> Laney: true
<tjaalton> oh well, onscripter test runs fine locally via xvfb or on qemu without xvfb
<Laney> should be possible to find out what the difference is then
<Laney> night!
-queuebot:#ubuntu-release- Unapproved: dsdp (zesty-proposed/universe) [5.8-9.1ubuntu2 => 5.8-9.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dsdp [sync] (zesty-proposed) [5.8-9.2]
-queuebot:#ubuntu-release- Unapproved: dnsmasq (xenial-proposed/main) [2.75-1ubuntu0.16.04.1 => 2.75-1ubuntu0.16.04.2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dnsmasq (yakkety-proposed/main) [2.76-4 => 2.76-4ubuntu0.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<nacc> bah, can someone reject the yakkety upload? forgot to run update-maintainer!
<tjaalton> tw, softhsm 2.2.0 breaks dns integration on freeipa, so could I revert to 2.1.0 for zesty?
<tjaalton> *btw
<tjaalton> and shouldn't be just freeipa https://github.com/opendnssec/SoftHSMv2/issues/298
<nacc> rbasak: --^ can you reject dnsmasq from the  yakkety queue?
<nacc> bdmurray: --^ or maybe better for your tz :)
<bdmurray> nacc: got it
<nacc> bdmurray: thanks
-queuebot:#ubuntu-release- Unapproved: rejected dnsmasq [source] (yakkety-proposed) [2.76-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (zesty-proposed/main) [0.6.5.9-5ubuntu3 => 0.6.5.9-5ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: dnsmasq (yakkety-proposed/main) [2.76-4 => 2.76-4ubuntu0.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (zesty-proposed) [0.6.5.9-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (zesty-proposed) [1.37.0-0ubuntu3]
<infinity> jbicha: What do you have against history? ;)
<infinity> jbicha: http://launchpadlibrarian.net/313174821/chrome-gnome-shell_8.2-0ubuntu2_8.2.1-1ubuntu1.diff.gz
<nacc> heh
-queuebot:#ubuntu-release- Unapproved: ldns (zesty-proposed/main) [1.7.0-1 => 1.7.0-1ubuntu1] (ubuntu-server)
<jbicha> infinity: I can add the old changelog entriesback to that upload if you like, it was a bit more work since I was only applying the Ubuntu patch changes on top of Debian's
<jbicha> infinity: could I interest you in reviewing switcheroo-control for zesty? LP: #1671828
<ubot5> Launchpad bug 1671828 in Ubuntu GNOME "[FFe] [needs-packaging] switcheroo-control" [Medium,In progress] https://launchpad.net/bugs/1671828
-queuebot:#ubuntu-release- Unapproved: lshw (zesty-proposed/main) [02.18-0.1ubuntu2 => 02.18-0.1ubuntu3] (core)
<tjaalton> infinity: I can't figure out what's wrong with the remaining xserver autopkgtest failures, Xvfb didn't get any new commits in 1.19.x, and it works just fine when these are run manually, even on qemu
<tjaalton> I _can_ modify xvfb-run so that it leaves the Xvfb behind, and then attaching the test to it fails the same way
<tjaalton> but no idea why
<tjaalton> though running any other X app on that same Xvfb again works fine
<tjaalton> so it's some libsdl crap I guess
-queuebot:#ubuntu-release- Unapproved: rejected aptdaemon [source] (yakkety-proposed) [1.1.1+bzr982-0ubuntu16.2]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (yakkety-proposed/main) [1.1.1+bzr982-0ubuntu16.1 => 1.1.1+bzr982-0ubuntu16.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.8 => 1.157.9] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: gvfs (zesty-proposed/main) [1.30.3-1ubuntu1 => 1.30.4-0ubuntu1] (ubuntu-desktop)
<bdmurray> stgraber: Do you know if you still have access to iso.qa.ubuntu.com or recall where sync-lp-bugs is running?
<stgraber> bdmurray: I think I still do, it's on limequat
<stgraber> bdmurray: and looks like you're in the right group too
<bdmurray> I'll make a note this time then
<stgraber> bdmurray: sync-lp-bugs runs as the "db" user on limequat, you should be able to sudo to that user
<stgraber> bdmurray: just synced limequat's copy and the bzr branch, so if you need to do some changes, you can push them to the branch and pull on limequat
-queuebot:#ubuntu-release- Unapproved: ginga (zesty-proposed/universe) [2.6.1-1 => 2.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ginga [source] (zesty-proposed) [2.6.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pysurfer (zesty-proposed/universe) [0.7-2 => 0.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pysurfer [sync] (zesty-proposed) [0.7-2]
-queuebot:#ubuntu-release- Unapproved: mate-menu (zesty-proposed/universe) [17.04.2-0ubuntu2 => 17.04.3-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntu-terminal-app (zesty-proposed/main) [0.7.218ubuntu2 => 0.7.218+17.04.20170328.3-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: cyrus-sasl2 (zesty-proposed/main) [2.1.27~101-g0780600+dfsg-2 => 2.1.27~101-g0780600+dfsg-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (xenial-proposed/main) [3.5.7-1 => 3.5.7-1ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (yakkety-proposed/main) [3.5.7-1 => 3.5.7-1ubuntu0.16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: click-reviewers-tools (zesty-proposed/universe) [0.45 => 0.46] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted click-reviewers-tools [source] (zesty-proposed) [0.46]
-queuebot:#ubuntu-release- Unapproved: bibcursed (zesty-proposed/universe) [2.0.0-6ubuntu3 => 2.0.0-6.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: dsdp (zesty-proposed/universe) [5.8-9.2 => 5.8-9.4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bibcursed [sync] (zesty-proposed) [2.0.0-6.1]
-queuebot:#ubuntu-release- Unapproved: accepted dsdp [sync] (zesty-proposed) [5.8-9.4]
#ubuntu-release 2017-03-29
-queuebot:#ubuntu-release- Unapproved: emacs25 (zesty-proposed/main) [25.1+1-3ubuntu3 => 25.1+1-3ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: subiquity (zesty-proposed/universe) [0.0.28 => 0.0.29] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (zesty-proposed) [0.0.29]
<bdmurray> stgraber: even running sync-lp-bugs in debug I don't see 1675210 being proccessed. http://iso.qa.ubuntu.com/qatracker/reports/bugs/1675210
-queuebot:#ubuntu-release- Unapproved: multipath-tools (zesty-proposed/main) [0.6.4-3ubuntu2 => 0.6.4-3ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: rawtherapee (zesty-proposed/universe) [5.0-1 => 5.0-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: golang-go-xdg (zesty-proposed/universe) [0~bzr20140219-1 => 0~bzr20140219-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-go-xdg [sync] (zesty-proposed) [0~bzr20140219-2]
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.5 => 1.11.8-0ubuntu0.6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (zesty-proposed) [8.2.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nfs-utils (yakkety-proposed/main) [1:1.2.8-9.2ubuntu1 => 1:1.2.8-9.2ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: nfs-utils (xenial-proposed/main) [1:1.2.8-9ubuntu12 => 1:1.2.8-9ubuntu12.1] (core)
<LocutusOfBorg> hello, do you want to see something really nice?
<LocutusOfBorg> accept emacs25 from zesty unapproved queue then!
<LocutusOfBorg> "25.1+1-3ubuntu4"
<LocutusOfBorg> :)
<LocutusOfBorg> one line changed, ~25 packages migrating
<LocutusOfBorg> apw, ^^^ (emacs25) <3
<Laney> The queue's all going to get reviewed
<apw> LocutusOfBorg, is someone chasing down why -O2 is borked on arm64 ?
<LocutusOfBorg> no, but since it stalls the whole imagemagick stuff I prefer to unblock
<LocutusOfBorg> imagemagic needs a new upload to fix CVEs
<LocutusOfBorg> apw, I did a lot of testing, and IIRC in a local qemu-pbuilder it is not even failing
<LocutusOfBorg> might be some sbuild issue, I can try again in a local build if matters
-queuebot:#ubuntu-release- Unapproved: less (zesty-proposed/main) [481-2.1ubuntu1 => 481-2.1ubuntu2] (core)
<ginggs> apw: barry said he would forward upstream
<ginggs> [00:49:09] <barry> i do plan on reporting this to upstream, even though it might be near impossible for them to repro
<ginggs> from #-devel
<LocutusOfBorg> cjwatson, my daily hero
<LocutusOfBorg> (wrt buildinfo, thanks!)
<tjaalton> Laney: onscripter test fail can be reproduced by modifying xvfb-run so that it doesn't clean up after a failure (Xvfb left running), but any other X client works fine with the server, just not this test suite
<xnox> apw, infinity: are there any wiki docs w.r.t what the Archive Team do? and/or specifically about NEW review process / requirements?
<apw> xnox, i imagine there is a documentation, though there is a lot of common sense applied too
<apw> xnox, what are you trying to determine
-queuebot:#ubuntu-release- Unapproved: accepted ldns [source] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (zesty-proposed) [02.18-0.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (zesty-proposed) [1.30.4-0ubuntu1]
<xnox> apw, i am more after documentation jibberish similar to e.g. MIR requirements page to satisfy some enquiries.
-queuebot:#ubuntu-release- New binary: ldns [amd64] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ldns [s390x] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ldns [ppc64el] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
 * apw defers to infinity on that
-queuebot:#ubuntu-release- New binary: ldns [i386] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
<tjaalton> Laney: so my point is that since neither Xvfb nor xvfb-run changed between 1.18..1.19 the failure is a non-issue which shouldn't block the migration..
<Laney> It's a test which fails using the new xorg-server and passes without
<tjaalton> not on all archs
<tjaalton> go figure that out then
<Laney> Don't be rude.
<xnox> infinity, apw: At https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages i found the criteria of "In order for a piece of software to be included in Ubuntu, it must meet the Ubuntu License Policy." which is a link to https://www.ubuntu.com/about/about-ubuntu/licensing and imho is good enough.
<Laney> On armhf and s390x the test is running using lxd and lxc respectively
<tjaalton> the old xserver was last update mid-december
<tjaalton> +d
-queuebot:#ubuntu-release- New binary: ldns [arm64] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
<tjaalton> let me try a rebuild 1.18 then
<tjaalton> rebuilt
-queuebot:#ubuntu-release- New binary: ldns [armhf] (zesty-proposed/main) [1.7.0-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+17.04.20170322-0ubuntu1.1 => 15.04.1+17.04.20170328-0ubuntu1] (ubuntu-desktop) (sync)
<tjaalton> so it only fails on qemu, not on lxd or real hw
-queuebot:#ubuntu-release- Unapproved: crash (zesty-proposed/main) [7.1.7-1ubuntu2 => 7.1.8-1ubuntu1] (core)
<ahayzen> hey, i was wondering if someone from the release team would be able to look at this FFe request? https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1676436   it basically adds the depends for printing support under unity8, and doesn't affect the unity7 session. I have the changes ready in this silo https://bileto.ubuntu.com/#/ticket/2642
<ubot5> Ubuntu bug 1676436 in unity8-desktop-session (Ubuntu) "[FFe] Add qtubuntu-print (and ubuntu-printing-app) to default unity8 experience" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: indicator-sound (zesty-proposed/main) [12.10.2+17.04.20170208-0ubuntu1 => 12.10.2+17.04.20170328.1-0ubuntu1] (ubuntu-desktop) (sync)
<dobey> hi, can i get a poke to approve indicator-sound in zesty please? it's a trivial change we need to make our jenkins behave better, and doesn't actually change anything about the build in the archive itself (other than being rebuilt). thanks
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.23.6~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.1 => 2.23.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.1+16.10 => 2.23.6+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.23.1+17.04 => 2.23.6+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pbuilder-scripts (zesty-proposed/universe) [21 => 22] (no packageset)
<tjaalton> more fun testing onscripter; fails on debian qemu too, and the failure only happens when Xvfb is started from the same shell. and of course it works just fine when trying to strace it...
-queuebot:#ubuntu-release- Unapproved: accepted pbuilder-scripts [source] (zesty-proposed) [22]
<tjaalton> I'm out of ideas and about to give up
<LocutusOfBorg> mterry, why pbuilder-scripts aren't in Debian? :)
<LocutusOfBorg> mapreri, ^^^
<mterry> LocutusOfBorg: heh because they were always sort of an idiosyncratic method of working and I think sbuild and friends is the recommended pattern.  I'm just stuck in my ways  :)
<mapreri> LocutusOfBorg: I have no clue what that thing even is
<LocutusOfBorg> mapreri, learn, merge into pbuilder :)
<LocutusOfBorg> s/learn/steal :D
<mapreri> mterry: I'm the pbuilder maintainer, guess there several idiosyncratic individuals around :P
<mterry> mapreri: it's just a set of scripts for working with several distro pbuilders.  I think even pbuilder has a better way of doing that these days.  But I use theses scripts because I have muscle memory for them
<mapreri> Well, I fear to say that doing nice enough multidistribution/multiarch work is not yet into pbuilder itself.  I mean, once a chroot is setup usually just changing --basetgz is enough to do everything, but in cases of create and `update --override-config` you alwyas need to either have a huge pbuilderrc, or provide tons of options
<mapreri> mterry: I fear everybody had to write their own pbuilderrc (or steal pieces from around, like there is one in the ubuntu wiki)
<mapreri> I suppose one day the situation will improve
-queuebot:#ubuntu-release- Unapproved: udisks2 (zesty-proposed/main) [2.1.8-1git1 => 2.1.8-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<mterry> mapreri: oh well maybe some of what these scripts do is useful to others then.  I quite like 'pget' which goes into the pbuilder, apt-get's source, and then gives you back the result in your project dir.  Helps when you have pbuilders with weird apt sources
<mterry> Also calls apt update so you know you have the latest
<mapreri> well my chroots don't have deb-src lines, for exampleâ¦
<mterry> Everyone's setup is idiosyncratic I guess :P
<mapreri> heh
-queuebot:#ubuntu-release- Unapproved: gnupg2 (zesty-proposed/main) [2.1.15-1ubuntu6 => 2.1.15-1ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (zesty-proposed/universe) [17.04.8 => 17.04.9] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: xkeyboard-config (zesty-proposed/main) [2.17-1ubuntu1 => 2.19-1ubuntu1] (core)
<bdmurray> stgraber: Did you my last comment about sync-lp-bugs?
<stgraber> bdmurray: yeah, no idea why the script isn't syncing that particular bug
<bdmurray> stgraber: okay, well thanks for the debuggin help
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (zesty-proposed/universe) [0.76 => 0.77] (ubuntugnome)
<stgraber> bdmurray: I believe I put some logic in there not to do changes to bug tasks outside of launchpad.net/ubuntu, since that bug has two tasks, maybe the script is getting confused somehow
<slangasek> xnox: so are you driving this systemd upload through to devel?
<bdmurray> stgraber: its using staging :-(
<xnox> slangasek, well the adt bug appeared indepdant of systemd changes; it was already spotted by linux uploads.
<bdmurray> stgraber: on the plus side its tagged there
<xnox> at the moment we only know that said test hangs thanks to zesty userspace changes for some reason.
<xnox> and yes i will want to get systemd changes into the release.
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.3 => 1:4.2.8p4+dfsg-3ubuntu5.4] (ubuntu-server)
<slangasek> xnox: that's the regression for systemd itself?
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (zesty-proposed/universe) [0.76 => 0.77] (ubuntugnome)
<jbicha> please reject the older ubuntu-gnome-meta/zesty
<xnox> slangasek, regression of the adt test shipped by systemd; and no it started first without any systemd changes (linux upload first triggered to spot the failure; but kernel has already been ruled out)
<slangasek> xnox: so does this mean you're still investigating and trying to resolve it, or should the release team set an override?
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (yakkety-proposed) [1.1.1+bzr982-0ubuntu16.2]
<xnox> slangasek, i'd rather add that one test to blacklist and reupload systemd such that all the other tests are still executed.
<xnox> (something else is already blacklisted as well, e.g. some selinux thing i believe)
<slangasek> rbasak, bdmurray: I'm looking at bug #1665436 (because following through on SRUs that have my name on them ;), and I see the bug was marked incomplete due to autopkgtest failures but nobody tried rerunning the failing test?
<ubot5> bug 1665436 in pciutils (Ubuntu Yakkety) "lspci tool needs to be updated to support pci gen4 cards" [Undecided,Incomplete] https://launchpad.net/bugs/1665436
<slangasek> (via http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#pciutils)
<stgraber> bdmurray: hmm, what? how comes it's using staging?
<bdmurray> stgraber: I don't know why yet
<bdmurray> https://bugs.staging.launchpad.net/ubuntu/+source/ubiquity/+bug/1675210
<ubot5> Ubuntu bug 1675210 in ubiquity (Ubuntu) "Ubuntu GNOME 17.04 Try or Install screen missing decorations" [Undecided,New]
<stgraber> bdmurray: that's just weird...
<bdmurray> slangasek: is it the SRU team's duty to investigate every autopkgtest failure?
<bdmurray> slangasek: I usually review things without failure first then get to the others when I can, so commenting on them so the uploader looks at it seems reasonable to me.
<slangasek> bdmurray: if you're looking at the statu, is it a burden to click the 'retry' button?
<slangasek> I'm looking at it now, but that means clicking retry on a bunch of linux autopkgtests, so it'll be hours before they're done and days before I context switch back to looking at these packages
<slangasek> also, in this case the failures are linux autopkgtests... which the SRU team is in a better position to have context on than a random SRU uploader (the context is: the kernel autopkgtests pull from a code repo outside of the package, so can regress without obvious archive trigger)
<bdmurray> slangasek: there is no retry button the the pending-sru page so sort of
<slangasek> right
<slangasek> I have suggested we should fix that, perhaps that should be a higher priority :)
<bdmurray> maybe a bug report would help
<bdmurray> should all failures just be retried automatically one time?
<slangasek> bdmurray: do you mean server-side, as opposed to when an SRU team member clicks the button?
<slangasek> that might be ok
<slangasek> Laney: ^^ do you have any opinions on this?
<bdmurray> slangasek: yes, I do
 * slangasek nods
<slangasek> I think we should also have a 'retry' button on the autopkgtest results page itself
<slangasek> so if I've already browsed to http://autopkgtest.ubuntu.com/packages/l/linux/yakkety/armhf and see that pciutils is failed, I should be able to just click next to it to retry with the same params
<slangasek> instead of having to navigate elsewhere
<bdmurray> yeah, that's crazy
<slangasek> and does someone remember the name of the project where we track bugs on the autopkgtest infra?  because https://bugs.launchpad.net/autopkgtest is not it :/
<slangasek> right, https://bugs.launchpad.net/auto-package-testing
-queuebot:#ubuntu-release- Unapproved: accepted emacs25 [source] (zesty-proposed) [25.1+1-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-gnome-meta [source] (zesty-proposed) [0.77]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (zesty-proposed) [0.77]
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (zesty-proposed) [0.6.4-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (zesty-proposed) [2.1.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cyrus-sasl2 [source] (zesty-proposed) [2.1.27~101-g0780600+dfsg-2ubuntu1]
<sergiusens> rbasak: hey, mind letting snapcraft 2.28 into xenial-updates and yakkety-updates please?
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (zesty-proposed) [15.04.1+17.04.20170328-0ubuntu1]
<dobey> anyone mind accepting indicator-sound into zesty-proposed please?
-queuebot:#ubuntu-release- Unapproved: libertine (zesty-proposed/main) [1.7+17.04.20170320.1-0ubuntu1 => 1.7.1+17.04.20170328-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-app-launch (zesty-proposed/main) [0.11+17.04.20170321-0ubuntu1 => 0.11+17.04.20170328-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<slangasek> bdmurray, Laney: LP: #1677331 filed
<ubot5> Launchpad bug 1677331 in Auto Package Testing "http://autopkgtest.ubuntu.com/ pages should allow directly retrying a test" [Undecided,New] https://launchpad.net/bugs/1677331
<sergiusens> slangasek: can I fallback to you for getting snapcraft 2.28 into {xenial,yakkety}-updates ?
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.23.6+17.04]
<slangasek> sergiusens: sure, looking
<bdmurray> infinity: Let me know what you think of the output in bug 1673557 or the linked OOPS on errors.
<ubot5> bug 1673557 in whoopsie (Ubuntu) "/proc/cpuinfo should be collected" [Medium,Triaged] https://launchpad.net/bugs/1673557
<infinity> bdmurray: Is the limit still 1k?
<infinity> bdmurray: If so, it'll still get filtered sometimes.  The fact that your machine is less fancy than mine shouldn't be the deciding factor.
<infinity> bdmurray: Otherwise seems fine.
<infinity> barry: I accepted it, but building an entire project with -O0 because (presumably) 1 file is being miscompiled is a rather large hammer. :P
<barry> infinity: thanks.  i predict the # of people who care about emacs on arm64 to be 3 or 4 and all of those just want the darn thing to not block other packages ;)  fwiw, i did report this upstream so if they suggest a better fix we can do that
<infinity> barry: Well, as bug reports go, "the project miscompiles" is a hard one to action.  Narrowing it down to the problematic file is nicer (but yes, lots of work), and may well prove it's a gcc or binutils bug.
<barry> infinity: indeed, esp because it seems completely unreproducible in anything but the arm64 buildds (e.g. we cannot repro on the porter box)
<infinity> barry: Anyhow, I agree with the general sentiment, though your number is probably off.  arm64 users today are still people moving over from the embedded crow, the idea that any of them would type "emacs" on purpose seems ludicrous. :P
<infinity> barry: But as arm64 server become more popular, maybe weirdoes like you will log into them.
<barry> infinity: me and rbalint my buddy in arms <wink>.  but yeah, we wouldn't want emacs to be *too* fast on arm64
<infinity> (And, for once, that wasn't me knocking emacs, so much as "modern editors" in general... vim is equally bloated on slow/embedded hardware)
<barry> +1
<infinity> nvi 4 lyf.
<barry> what he sed
<dobey> how else are you going to run emacs on a modern phone
<infinity> dobey: Step 1: Don't do that.
<infinity> dobey: Step 2: Rethink the decisions that brought you here.
<infinity> dobey: Step 3: Go for ice cream instead.
<dobey> it's called "convergence" man
<dobey> get used to it :)
<barry> 0. type 'emacs'
<infinity> :)
<barry> 1. rethink the decisions that brought you here
<barry> 2. go for ice cream
<barry> 3. take a nap
<barry> 4. take another nap
<barry> 5. watch emacs start
<bdmurray> infinity: yeah, the limit is 1k. Would you want this SRU'ed?
<dobey> 0. get a tripod to hold your ice cream, because you're going to need both hands for emacs keybindings
<infinity> dobey: I wasn't implying at all that emacs shouldn't be performant on arm64 (it very much should be), but that the *current* set of arm64 users are mostly people from a pre-holy-crap-arm-is-fast-now world, and thus probably don't run emacs. :P
<infinity> bdmurray: I think we should SRU it, but only after we're pretty sure we'll catch all the data (which a 1k limit won't). :/
<dobey> anyway
<infinity> bdmurray: Since one of the primary motivators here is 100% coverage for faux metrics about who's running what hardware.
<bdmurray> infinity: right
 * dobey just wants (his trivial change) to be accepted :-/
<infinity> bdmurray: I'm betting your cpuinfo is only a few chars shy of 1k, and last I checked, mine (cut down to a single CPU stanza) was a few chars over.
<infinity> bdmurray: So, as limits go, that one's unfortunately in just the wrong place for this. :)
-queuebot:#ubuntu-release- Unapproved: qtmir (zesty-proposed/main) [0.5.1+17.04.20170320.1-0ubuntu1 => 0.5.1+17.04.20170328-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir-gles (zesty-proposed/universe) [0.5.1+17.04.20170320.1-0ubuntu1 => 0.5.1+17.04.20170328-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtubuntu (zesty-proposed/main) [0.64+17.04.20170320-0ubuntu1 => 0.64+17.04.20170328.1-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtubuntu-gles (zesty-proposed/universe) [0.64+17.04.20170320-0ubuntu1 => 0.64+17.04.20170328.1-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: unity8 (zesty-proposed/main) [8.15+17.04.20170321-0ubuntu1 => 8.15+17.04.20170328.3-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (zesty-proposed/main) [1:10.0-1ubuntu1 => 1:10.0-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu2 => 2.20.4-0ubuntu3] (core)
<nacc> infinity: should i mark 12.04, 12.04.1 and 12.04.5 as eol on april 28, 2017 on https://wiki.ubuntu.com/Releases?
-queuebot:#ubuntu-release- Unapproved: sane-backends (zesty-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu3] (desktop-core, ubuntu-server)
<nacc> infinity: and should 12.04.2-12.04.4 and 14.04.2-14.04.4 be moved to eol?
-queuebot:#ubuntu-release- Unapproved: sane-backends (yakkety-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu2.16.10.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sane-backends (xenial-proposed/main) [1.0.25+git20150528-1ubuntu2 => 1.0.25+git20150528-1ubuntu2.16.04.1] (desktop-core, ubuntu-server)
<rbalint> barry: since emacs don't have problems on Debian i suspect one of the coming gcc updates will eliminate the workaround
<barry> rbalint: that's my suspicion too.  i think we should do a no-change rebuild once aamazing aardvark's toolchain lands
<nacc> slangasek: --^ or your opinion on that (releases wiki update)
<rbalint> barry: when time permits i would also give a shot to ASAN and UBSAN against emacs if the problem does not go away
<infinity> nacc: You can record the exact date if you like.  14.04.2-14.04.4 aren't EOL, however.
<barry> rbalint: i also have a couple of hints/questions from upstream worth investigating
<infinity> nacc: The kernels they shipped with are, and there's already a link explaining that.
<barry> infinity, rbalint, nacc, dannf interestingly, emacs 24.5+1-6ubuntu3 has apparently been in proposed for 47 days.  i didn't notice earlier because i don't use emacs24
<infinity> You mean 24.5+1-8ubuntu2?
<infinity> It'll migrate when emacs25 is sorted.
<barry> infinity: yep, and cool.  upstream is asking about 24.5
<rbalint> barry, infinity: I have just tested emacs on an rpi2 and it is perfectly usable, even without daemon mode :-)
<rbalint> barry, infinity: it is -O2, however
<barry> rbalint: it'd be interesting to see how the -O0 build performs :)
<infinity> barry: Based on how much slower the build is going (much of which involves running emacs itself after it's built), I'm guessing -O0 really doesn't perform. :P
<infinity> But that's no surprise.
<barry> indeed.  and emacs24 was last built in feb.  i don't know if there were any relevant toolchain updates since then, but i'm going to build the current zesty emacs24 in my ppa to see if it now has the same arm64 crash
<barry> btw, that traceback is interesting because prev points to ascii "ginning" almost for sure it was "beginning".  so memory corruption
<dobey> maybe it just really likes gin
<barry> emacs does work better when you're drunk
<dobey> indeed
-queuebot:#ubuntu-release- Unapproved: whoopsie (zesty-proposed/main) [0.2.54 => 0.2.55] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-os-brick (yakkety-proposed/main) [1.6.1-0ubuntu1.1 => 1.6.1-0ubuntu1.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-brick (xenial-proposed/main) [1.2.0-2ubuntu0.2 => 1.2.0-2ubuntu0.3] (openstack, ubuntu-server)
<nacc> infinity: ack
-queuebot:#ubuntu-release- Unapproved: spyder (zesty-proposed/universe) [3.1.3+dfsg1-1 => 3.1.3+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spyder [sync] (zesty-proposed) [3.1.3+dfsg1-2]
<barry> infinity, rbalint interestingly, i just built zesty's 24.5 in my ppa and arm64 succeeded
<barry> i think i'm going to try debian's 25.1 in my ppa just to rule out any ubuntu deltas
<infinity> barry: Do we have deltas against the code?  I would have assumed we only had packaging deltas.
<barry> infinity: just build-depends differences and the parallel=1.  i honestly can't imagine those make a difference but just want to definitely rule it out
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-82-g0e2030ca-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<ginggs> emacs25 has been failing on arm64 since 25.1+1-2ubuntu3 (2016-11-17)
<barry> ginggs: that's interesting because 25.1+1-3 is the first one that set REL_ALLOC=no.  but emacs24 also sets REL_ALLOC=no and doesn't crash
<ginggs> emcas24 built successfully on arm64 quite a few times since that date
<barry> yep
<barry> and i *just* built emacs24 again in my ppa and it passed
<rbalint> barry: i saw differences in dependencies and buildd config only
<barry> rbalint: me too, but upstream was asking so i want to definitively rule that out, even though if it *does* fix things that'll make no sense ;)
<nacc> infinity: slangasek: could i get a review of LP: #1671905? now that imagemagick has migrated, this will save us one security update
<ubot5> Launchpad bug 1671905 in imagemagick (Ubuntu) "[FFe] Please merge with imagemagick 8:6.9.7.4+dfsg-2 from Debian unstable." [Undecided,In progress] https://launchpad.net/bugs/1671905
<infinity> nacc: LGTM, go for it.
<dobey> infinity: care to poke indicator-sound in zesty unapproved over to proposed? it's a trivial change we need for CI, so roughly no-change rebuild in the archive
<infinity> dobey: Looking.
-queuebot:#ubuntu-release- Unapproved: accepted indicator-sound [sync] (zesty-proposed) [12.10.2+17.04.20170328.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (zesty-proposed) [1.0.25+git20150528-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (zesty-proposed) [1:10.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted whoopsie [source] (zesty-proposed) [0.2.55]
-queuebot:#ubuntu-release- Unapproved: eject (zesty-proposed/main) [2.1.5+deb1+cvs20081104-13.1ubuntu1 => 2.1.5+deb1+cvs20081104-13.2] (core) (sync)
<nacc> infinity: thanks
<dobey> thanks infinity
-queuebot:#ubuntu-release- Unapproved: screen (zesty-proposed/main) [4.5.0-3ubuntu1 => 4.5.0-4ubuntu1] (ubuntu-desktop, ubuntu-server)
<barry> well that's a "good" sign.  straight up d/unstable emacs25 also fails on arm64 as expected
<nacc> barry: nice :)
<barry> same crash
<doko> please unblock openjdk-9, nothing uses it, the autopkg test failures are not relevant
<infinity> doko: The openjdk-9 that migrated 12 hours ago?
<doko> hmm, ok. didn't get an email
<doko> ahh, it was a sync
<doko> barry: did you identify the file needing O0?
-queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:6.9.7.0+dfsg-2ubuntu1 => 8:6.9.7.4+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
<barry> doko: no, and i'm not sure how to narrow it down to a single file.  still talking w/upstream tho
<doko> barry, having an optimized build, and a -O0 build, and then using half of the O0 built files ... and bisecting ...
<doko> but maybe later ... afk now, hopefully 'til early April
<barry> doko: that doesn't sound like a lot of fun ;)
<barry> doko: okay!  enjoy, ttyl
<barry> btw, i do plan on more investigation, including removing -O0 for zesty+1
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-84.92] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-71.92] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-115.162~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-45.48~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-115.162] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-45.48] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-71.92~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-115.162~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-115.162]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-71.92~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-84.92]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-45.48~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-45.48]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-71.92]
-queuebot:#ubuntu-release- Unapproved: kombu (zesty-proposed/main) [3.0.35-1.1ubuntu1 => 3.0.35+dfsg-2] (ubuntu-server) (sync)
<slangasek> robru: hi, you recall LP: #1668353?
<ubot5> Launchpad bug 1668353 in britney "Linux kernel autopkgtests often fail due to version mismatch between running kernel and tested kernel." [Undecided,New] https://launchpad.net/bugs/1668353
<slangasek> I have a slew of examples that I just ran across
<robru> slangasek: mention them on the bug please. I never fully understood the issue and most of the comments deny it exists
<slangasek> robru: already done
<robru> slangasek: ok thanks, will take a look
-queuebot:#ubuntu-release- Unapproved: python-django (zesty-proposed/main) [1.8.7-1ubuntu9 => 1.8.7-1ubuntu10] (ubuntu-server)
#ubuntu-release 2017-03-30
-queuebot:#ubuntu-release- Unapproved: gtksourceview2 (zesty-proposed/universe) [2.10.5-2ubuntu2 => 2.10.5-2ubuntu3] (ubuntu-desktop)
<handsome_feng> Hi, Could someone there can help check the two update request: bug: #1677432 bug: #1677157 Thank you!
<ubot5> bug 1677432 in ubuntukylin-wallpapers (Ubuntu) "[FFe] Update ubuntukylin-wallpapers to 17.04.0" [Undecided,New] https://launchpad.net/bugs/1677432
<ubot5> bug 1677157 in ubuntukylin-theme (Ubuntu) "[FFe] Update ubuntukylin-theme to 1.7.0" [Undecided,New] https://launchpad.net/bugs/1677157
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (zesty-proposed/universe) [1.6.2 => 1.7.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: rpi.gpio (zesty-proposed/universe) [0.6.3-1 => 0.6.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rpi.gpio [source] (zesty-proposed) [0.6.3-1ubuntu1]
-queuebot:#ubuntu-release- New binary: rpi.gpio [arm64] (zesty-proposed/universe) [0.6.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rpi.gpio [armhf] (zesty-proposed/universe) [0.6.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: squid3 (zesty-proposed/main) [3.5.23-1ubuntu1 => 3.5.23-1ubuntu2] (ubuntu-server)
<Saviq> hi all, could someone please approve the packages coming from https://bileto.ubuntu.com/#/ticket/2626? thanks!
-queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:6.9.7.0+dfsg-2ubuntu1 => 8:6.9.7.4+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: kdevelop (zesty-proposed/universe) [4:5.0.4-0ubuntu1 => 4:5.0.4-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate, ubuntukylin)
<tjaalton> Laney: added debug notes on #1671799
<tjaalton> bug #1671799
<ubot5> bug 1671799 in xorg-server (Ubuntu) "FFe: xserver 1.19.3" [Undecided,Confirmed] https://launchpad.net/bugs/1671799
<LocutusOfBorg> hello release team, feature request: is it possible when receiving the "your package is stuck in proposed since foo days", to have also the changelog of the latest upload attached? this way I can understand if this was a transition, a no change rebuild, or a bad merge
-queuebot:#ubuntu-release- Unapproved: brisk-menu (zesty-proposed/universe) [0.3.0-0ubuntu1 => 0.3.5-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-themes (zesty-proposed/universe) [3.22.7-0ubuntu1 => 3.22.8-0ubuntu1] (ubuntu-mate)
<LocutusOfBorg> (I can open a bug if needed, just I don't know where that service is located)
-queuebot:#ubuntu-release- Unapproved: unity-greeter-session-broadcast (zesty-proposed/main) [0.1+14.10.20140601-0ubuntu4 => 0.1+14.10.20140601-0ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: aethercast (zesty-proposed/universe) [0.1+16.10.20160808-0ubuntu4 => 0.1+17.04.20170328.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aethercast [sync] (zesty-proposed) [0.1+17.04.20170328.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bluez (xenial-proposed/main) [5.37-0ubuntu5 => 5.37-0ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted ldns [amd64] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldns [armhf] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldns [ppc64el] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldns [arm64] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldns [s390x] (zesty-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldns [i386] (zesty-proposed) [1.7.0-1ubuntu1]
<cpaelzer> Hi, could one please reject squid3 3.5.23-1ubuntu2 from zesty unapproved queue?
<cpaelzer> While technically correct on the work with Debian we spottet some licence things that should be sorted out before.
<apw> cpaelzer, looking
-queuebot:#ubuntu-release- Unapproved: rejected squid3 [source] (zesty-proposed) [3.5.23-1ubuntu2]
<cpaelzer> thanks apw
<smoser> hey. can someone NACK a cloud-init upload for me ?
<smoser> the one in the queue is missing a bug reference.
<Saviq> hi release team, any chance of approving the packages synced from this silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2626/+packages?field.series_filter=zesty ?
-queuebot:#ubuntu-release- Unapproved: parallax (zesty-proposed/universe) [1.0.1-2 => 1.0.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted parallax [sync] (zesty-proposed) [1.0.1-3]
<apw> smoser: looking
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-82-g0e2030ca-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-82-g0e2030ca-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: vulkan (zesty-proposed/universe) [1.0.42.0+dfsg1-1 => 1.0.42.0+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vulkan [source] (zesty-proposed) [1.0.42.0+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-xkcd (zesty-proposed/universe) [2.4.1-1 => 2.4.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-xkcd [sync] (zesty-proposed) [2.4.2-1]
<rbasak> Do I need an FFe to drop something from a seed?
<rbasak> bug 1667195
<ubot5> bug 1667195 in mdbtools (Ubuntu) "Drop mdbtools-gmdb from main" [Undecided,New] https://launchpad.net/bugs/1667195
-queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.1 => 2.8.0-1ubuntu1~16.04.2] (no packageset)
<rbasak> If unsure, can a release team member give me an ack on it at least please?
<rbasak> 16:15 <jbicha> my opinion is that since it wasn't shipped but only listed as "supported" that it wouldn't need a FFe
<rbasak> 16:15 <rbasak> Good point. It wouldn't make any changes to an image.
<rbasak> So I did it.
<flexiondotorg> Ubuntu MATE would like to run a testathon this weekend, we've got a few packages pending, could someone eye them over please?
<flexiondotorg> brisk-menu, mate-menu, mate-control-center, ubuntu-mate-artwork, mate-themes
<maclin> hi, release team,  Ubuntu Kylin image building was failed yesterday. The build log shows there was a conflict of dependencies:   "libmagickwand-6.q16-2 : Depends: imagemagick-6-common (= 8:6.9.6.6+dfsg-1ubuntu3) but 8:6.9.7.0+dfsg-2ubuntu1 is to be installed"  Could someone help to check the problem?
<maclin> This package was not directly depend by our packages. There were only some "oxideqt" related packages update  yesterday, but we can't confirm the relation.  So I am afraid other image building may face this problem today?
<maclin> If this is a problem only affecting Ubuntu Kylin, could someone help to confirm it?  thanks :)
<nacc> maclin: it might be from the transition as we finally got imagemagick migrated yesterday and there was a ABI bump
<nacc> maclin: ah i see, i think we need to do some NBS cleanup too
<maclin> nacc,  is there anything we have to change?
<nacc> maclin: no i think it's my cleanup to resolve
<maclin> nacc, I got it, thanks:)
<nacc> maclin: can you paste me a link to the build log?
<maclin> https://launchpadlibrarian.net/313471764/buildlog_ubuntu_zesty_amd64_ubuntukylin_BUILDING.txt.gz
<nacc> maclin: thanks!
<nacc> maclin: probably need to some no change rebuilds as well
<nacc> maclin: will work on that now
<maclin> nacc: ok, we will wait for the new image tomorrow, thanks:)
<nacc> slangasek: confused by something: http://people.canonical.com/~ubuntu-archive/nbs.html says sunflow and usbview depend on specific older binaries, but looking at those packages, i don't see the deps? What am I missig?
<infinity> nacc: Probably dependencies on virtual packages.
<infinity> nacc: Also, it's referring to build-depends, not depends.
<nacc> infinity: "Packages which depend on NBS packages" refers to build depends?
<infinity> nacc: And, indeed, sunflow build-depends on libmagickcore-6.q16-2-extra
<infinity> nacc: It does, if you read the whole line. :P
<bdmurray> infinity: I typed the wrong i package name and released initramfs-tools for trusty. Can anything be done?
<infinity> nacc: The last column helpfully tells you which arch's binaries have the issue.  When it's build-depends instead of binary, it says "build".
<nacc> infinity: ah i see it now!
<nacc> infinity: sorry for the noise, will fix
<bdmurray> infinity: its verified but has linux-lts autopkgtest failures
<infinity> bdmurray: Like, JUST now?
<bdmurray> infinity: yes JUST now
<infinity> Yeah, we can just delete it.  It hasn't published yet.
<infinity> And then copy the old version back.
<infinity> I'll sort that.
<bdmurray> Great, thanks.
<infinity> bdmurray: Although, the linux autopkgtest failures, do they really have anything to do with initramfs-tools?  They're not exactly known for their stability.
<bdmurray> infinity: I didn't look at them so can't say
<bdmurray> they certainly do look flakey
<infinity> I'm more inclined to say "hey kernel people, fix your tests" than hold off the SRU indefinitely. :P
<infinity> I'll spot check a few of these before I do the delete and copy thing.
<infinity> Oh, in fact, these are failing for entirely other reasons.
<infinity> So, yeah.
<infinity> bdmurray: Not reverting.
<bdmurray> infinity: okay
<infinity> bdmurray: I'll have some chats at the kernel sprint next week about how we can get a green baseline on all these kernel tests.
<bdmurray> where's that?
<infinity> (And then maybe actually implement the results of said chats)
<infinity> Londres.
-queuebot:#ubuntu-release- Unapproved: libdrm (zesty-proposed/main) [2.4.75-2 => 2.4.76-1] (core, xorg) (sync)
<infinity> nacc: Were/are you driving this imagemagick transition?
<nacc> infinity: yeah i suppose so
<nacc> infinity: by virtue of keeping it migrating recently
<infinity> nacc: Pretty sure that https://bugs.launchpad.net/ubuntu/+source/jxrlib/+bug/1666687 isn't going to get resolved by release, so that Recommends should drop to a Suggests, IMO.
<ubot5> Ubuntu bug 1666687 in jxrlib (Ubuntu) "[MIR] jxrlib" [Undecided,Incomplete]
<nacc> infinity: ack, on my list too
<nacc> infinity: i plan on uploading those three after breakfast :)
<infinity> nacc: Arguably, it should be a suggests anyway, and the code should actually TEST for the binary and suggest installing libjxr-tools, rather than just throwing ugly errors.
<nacc> infinity: ack
<infinity> nacc: Or, to be more verbose about my reasoning there, the fact that it throws hard errors makes it a Depends, per policy, not Recommends.  If it didn't throw errors, it would be a Suggests, because one would only call it a Recommends if a major/common use-case of imagemagick was converting that specific file type, which seems like quite a stretch to argue.
<infinity> nacc: But, for now, an incorrect Suggests will do, unless you have the time to also fix the hard error.
<nacc> infinity: yep, understood -- i think there are a number of things like this in the imagemagick code. I will take a look but probably just drop it to a suggests for  now
 * infinity nods.
<infinity> Also, the docs depending on some random JS library is kinda fun.  But if that's a hard dep for a good reason, we can just blacklist the docs from main.
<infinity> nacc: ^-- Lemme know on that score, and I'll adjust the seeds if appropriate.
<nacc> infinity: will do
-queuebot:#ubuntu-release- Unapproved: usbview (zesty-proposed/universe) [2.0-21-g6fe2f4f-1 => 2.0-21-g6fe2f4f-1ubuntu1] (no packageset)
<slangasek> infinity: tzdata required->important as discussed
-queuebot:#ubuntu-release- Unapproved: accepted usbview [source] (zesty-proposed) [2.0-21-g6fe2f4f-1ubuntu1]
<infinity> slangasek: Fun, fnu.
<infinity> fnu!
<infinity> slangasek: Thanks for changing the archive as well this time. ;)
-queuebot:#ubuntu-release- Unapproved: sunflow (zesty-proposed/universe) [0.07.2.svn396+dfsg-14 => 0.07.2.svn396+dfsg-14ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sunflow [source] (zesty-proposed) [0.07.2.svn396+dfsg-14ubuntu1]
<nacc> infinity: can you reject the imagemagick in the unapproved queue? then i'll upload the same version with the fixed component mismatch
<flexiondotorg> infinity Any chance I can ask for some reviews of zesty uploads?
<flexiondotorg> Would like to get the last bits in for an Ubuntu MATE testathon this weekend.
<flexiondotorg> ubuntu-mate-artwork, brisk-menu, mate-menu, mate-control-center, mate-themes
<infinity> nacc: Oh just upload ubuntu2 with your changes, so you're not mangling history?
<infinity> nacc: s/Oh/Or/
<nacc> infinity: yeah i'm happy to do that too
<nacc> infinity: will upload shortly then
<infinity> nacc: Yeah. Just grab the one from the queue and build on it.
<infinity> flexiondotorg: The queue will be empty by my EOD, either by accepting or rejecting.
<infinity> flexiondotorg: History went wonky in mate-menu.  Expected?
<flexiondotorg> infinity I'm checking mate-menu...
<infinity> flexiondotorg: http://launchpadlibrarian.net/313265955/mate-menu_17.04.2-0ubuntu2_17.04.3-0ubuntu1.diff.gz
<nacc> infinity: oh i see the docs reference, sorry -- will examine it now
<flexiondotorg> infinity wtf. Reject that, their is a glitch in the matrix. I'll upload a replacement promptly.
<infinity> flexiondotorg: heh.
<flexiondotorg> *there even
-queuebot:#ubuntu-release- Unapproved: rejected mate-menu [source] (zesty-proposed) [17.04.3-0ubuntu1]
<infinity> dput needs an eliza frontend that goes something like "Did you debdiff before you uploaded?" (response) "And how did that make you feel?"
<infinity> "I'm not sure what you mean by 'Just upload the friggin package, can you elaborate?"
<infinity> s/package/package'/
<nacc> infinity: it would appear the doc dep is a real one, rather than using the version bundled with the source so i think a blacklist may be appropriate
<nacc> infinity: would you like a bug filed to refer to?
<wxl> infinity: s/\(package\)/\1'/ would have been shorter ;)
<infinity> nacc: Nah, I'll just refer to the MIR.
<nacc> infinity: ok, thanks
<infinity> wxl: My regular expressions in IRC are usually written for readability, not length.
<wxl> infinity: well you get points for that :)
<flexiondotorg> infinity Thanks for the reject, correct upload for mate-menu incoming.
-queuebot:#ubuntu-release- Unapproved: mate-menu (zesty-proposed/universe) [17.04.2-0ubuntu2 => 17.04.3-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:6.9.7.0+dfsg-2ubuntu1 => 8:6.9.7.4+dfsg-2ubuntu2] (desktop-core, ubuntu-server)
<infinity> nacc: Err, why did you change the previous changelog entry?
<infinity> nacc: Or was it a lie that it was locutusofborg's upload, and you're correcting that? :P
<nacc> infinity: um, strange
<nacc> so i also uploaded 8:6.9.7.4+dfsg-2ubuntu1 to the queue
<infinity> nacc: Not the one I downloaded from the queue...
<infinity> Oh!
<infinity> You both uploaded one.
<nacc> infinity: right, i didn't realize it had been superseded
<nacc> well 'superseded' :)
<nacc> infinity: totally my fault, as i thought it was my upload that i was looking for the ubuntu1
<infinity> Okay, to be fair, they're basically identical.
<nacc> yeah, contentfully the same
<nacc> infinity: you can reject and i can refresh from the queue
<infinity> nacc: Nah, all good.
<nacc> infinity: ok, sorry about that!
<infinity> nacc: Your upload beat his.  So, if it wasn't a freeze, you would have won. :P
<nacc> heh
<infinity> nacc: queue fetch just got me the newer one.
<nacc> also, mine closes the bug filed for the FFe :)
<infinity> nacc: Not that it'll make a big difference (since the bug has no imagemagick task), but his bug ref with the intentional parse error is more correct for referencing a bug, rather than closing it.
<infinity> nacc: (The MIR bug, not the FFe bug)
-queuebot:#ubuntu-release- Unapproved: rejected imagemagick [source] (zesty-proposed) [8:6.9.7.4+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted imagemagick [source] (zesty-proposed) [8:6.9.7.4+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected imagemagick [source] (zesty-proposed) [8:6.9.7.4+dfsg-2ubuntu1]
<nacc> infinity: ah yes, sorry about that!
<nacc> infinity: regardless, sorry for the noise with all that
<tjaalton> slangasek, infinity: Laney seems absent, so could you check if my analysis of the onscripter test failures are enough to let xserver enter zesty https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1671799/comments/37
<ubot5> Ubuntu bug 1671799 in xorg-server (Ubuntu) "FFe: xserver 1.19.3" [Undecided,Confirmed]
<infinity> tjaalton: Any idea what's up with the yorick/s390x regression?
<tjaalton> infinity: no.. not the most important platform for X anyway
<infinity> No, but regressions still point to bugs somewhere.
<tjaalton> I don't know how to debug that one
<infinity> xnox: ^
<infinity> tjaalton: As for your onscripter analysis, it sort of creates more questions than it answers.
<infinity> tjaalton: I was hoping it was a simple "qemu sucks, and we're detecting CPU features that get masked" bug, but your indication that it works from other shells in the same VM throws that out.
<infinity> error: ("/usr/lib/powerpc64le-linux-gnu/ada/adalib/gmpada/gnu_multiple_precision.ali" is obsolete and read-only)
<infinity> doko: ^-- Are we supposed to be doing gnat transitions of some sort, and did we fail to do one properly?
<wxl> new xorg would be nice
<tjaalton> infinity: yeah it's a weird issue.. real hw is fine, lxc is fine
<Saviq> hi release team, can we please have the packages from this silo https://bileto.ubuntu.com/#/ticket/2626 approved to zesty?
<infinity> tjaalton: On a hunch, does "kvm -cpu host" work?  I mean, that might confirm my original claim, though makes your findings even more bizarre. :P
<infinity> Saviq: I'll have a look at that bunch after lunch.
<Saviq> infinity, thanks
<tjaalton> infinity: what exactly do you mean? running just that does run qemu but doesn't boot anything
<tjaalton> oh you mean running the qemu image with host cpu model?
<infinity> tjaalton: I mean using "-cpu host" as the cpu spec for the test, rather than whatever the default is.
<tjaalton> got it, trying..
<tjaalton> infinity: heh, I get a segfault instead
<tjaalton> (EE) Floating point exception at address 0x7fdb9a9e2d19
<tjaalton> this is from swrast_dri.so
<tjaalton> so now Xvfb crashes
<tjaalton> I'll try again after dist-upgrade..
<tjaalton> had to use another instance that has working network
<tjaalton> right, fails the same way after upgrade, so -cpu host didn't change anything
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-87-gd23543eb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<nacc> infinity: i think the imagemagick packages that are NBS can all be removed now
<nacc> and looks like once the tests finish the component-mismatch should go away
-queuebot:#ubuntu-release- Unapproved: accepted qtmir-gles [sync] (zesty-proposed) [0.5.1+17.04.20170328-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu-gles [sync] (zesty-proposed) [0.64+17.04.20170328.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity8 [sync] (zesty-proposed) [8.15+17.04.20170328.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir [sync] (zesty-proposed) [0.5.1+17.04.20170328-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [sync] (zesty-proposed) [0.64+17.04.20170328.1-0ubuntu1]
<slangasek> infinity, apw: so I want to give you both a heads-up regarding a discussion cyphermox and I are having about how to make available a grub that enforces kernel signatures, before we're ready to turn that on for the distro as a whole
-queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (zesty-proposed) [1.7.1+17.04.20170328-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-app-launch [sync] (zesty-proposed) [0.11+17.04.20170328-0ubuntu1]
<slangasek> infinity, apw: we /could/ be ready to turn it on for the distro as a whole, except that I think we need some upgrade logic around detecting systems where the currently-configured kernel is not signed and warn instead of leaving the system unbootable. :P
<apw> slangasek: sounds like a great idea
<infinity> s/upgrade logic/preinst logic/
<infinity> So, how are we going to prevent people from shooting themselves in the foot by removing linux-signed?
<infinity> Other than going back in time and agreeing that linux-signed is a silly idea, and linux-image should just be signed by default. :P
<slangasek> infinity, apw: so of the many options on the table, we think that the most straightforward option that gives us what we need - namely, *a* signed (with Ubuntu key) grub.efi that doesn't allow fallback to unsigned kernels, that we can put in a gadget snap for a customer (doesn't need to be in a grub-signed .deb at the moment) is to just build two grub.efi, one with the linux module, one without,
<slangasek> and let them be accepted into the archive
<infinity> slangasek: Sure, seems reasonable.  Put them both in the efi tarball, sign both, but have grub-signed pick up the non-enforcing one.
<infinity> slangasek: Which, if you name the new one something else, happens by default.
<slangasek> UX for the one without the 'linux' grub module is probably going to be a weird 'missing module' message rather than a 'security failed' message, but we mostly don't care for the present use case, because this is for a product that's SB-enforcing and anybody managing to point grub at an unsigned kernel can keep both pieces anyway
<apw> infinity: could we use a provides: kernel-signed to ensure you have at least one bootable kernel
<slangasek> and the policy of this new binary isn't special, it's the next step along our path of turning on enforcement, we're just not ready to do it yet
<infinity> slangasek: So, I might be unfamiliar with the process here, but why remove a module?  Isn't there just an "enforce or not" option at build time?
<slangasek> so I don't feel like we're signing an artifact we shouldn't be
<slangasek> infinity: we would have to build the grub source twice with different patches; there's no build time flag in the patchset
<slangasek> oh
<slangasek> shoot
<infinity> You're building it twice anyway, no?
<slangasek> infinity: the idea would be we wouldn't need to build it twice, only run the build-efi-image script twice
<cyphermox> not twice for efi.
<infinity> Or just linking it twice, I guess.  But same-same, it's just machine time.
<cyphermox> slangasek: not even run build-efi-image twice, I can just add a grub-mkimage.
<slangasek> right
<cyphermox> it's very nearly a one-liner.
<slangasek> infinity: setting aside the implementation details of how this gets done in the grub package - no objections to having two signed .efi binaries for grub starting now-ish in zesty?
<infinity> slangasek: Nope.
<slangasek> and yes, the fact that you can currently get your signed kernel removed on a SB system and be none the wiser is something we also need to tackle
<infinity> slangasek: Perfectly fine with that idea, so long as the one we're shipping in grub-signed doesn't regress in any way.
<slangasek> ack
<cyphermox> infinity: the grub$arch.efi we ship would be exactly as it was, untouched. I'd add a "enfore_grubx64.efi" or something like that
<infinity> apw: Depending on kernels works really poorly, which is why we almost always try to avoid it.
<infinity> cyphermox: *nod*
<infinity> cyphermox: Well, surely not exactly, as it sounds like there's patches involved here.
<cyphermox> infinity: nah, I think I can circumvent that
<cyphermox> ie. removing the 'linux' module breaks the fallback to loading unsigned.
<infinity> Maybe it would help if I knew what "remove the linux module" actually means.
<cyphermox> (if it works)
<cyphermox> grub is modular, every command (or nearly) is a "module"
<infinity> Sure, I know that.
<cyphermox> obviously, this is what I'm about to test
<infinity> But the implication here is that the efi module requires SB chaining, while the linux module doesn't, and it's that fallback we currently rely on?
<apw> infinity: would it serve us well to switch linux-image to install signed
<infinity> apw: Yes, that's what we should have done years ago.
<infinity> apw: But we never got around to implementing our discussions.
<apw> on everything, now in advance
<cyphermox> infinity: yeah, currently if linuxefi fails to validate the signature, it silently goes to start the kernel using the 'linux' command.
<infinity> apw: Basically, we should do what Ben was doing, where the buildds upload foo-unsigned.deb, and then we package it as foo.deb.
<apw> so if they upgrade it gets reinstalled
<infinity> apw: The inverse of the current status quo.
<apw> we can likely retrofit that
<apw> discussion for now+4?
<infinity> apw: Sure, we can.  The only problem is that old kernels won't have it.  So, if we intend to enforce in old stables, we'll still need to think of a way forward.  But maybe just a preinst guard and grub that just refuses to upgrade unless you're on a kernel that's packaged the New Way would suffice, cause once you're on that track, accidentally removing your signed kernel is kinda a "duh, don't do that" thing, instead of an honest mistake.
<infinity> apw: Discussion for the sprint, but probably we should carve out some pair programming time to *implement* at the sprint.  Given we've discussed this literally for years, more talk won't help us much. ;)
<infinity> apw: Err, of course, the immediate path forward, if we were in a hurry, is much simpler.  Given we rely on meta for upgrades anyway (derp), we should just make linux-image point to linux-signed.
<infinity> apw: It's not like anyone will get an upgrade to a new packaging method without meta installed anyway, so...
<infinity> I really wish I could understant the paranoia that originally led to us thinking there was a reason to have an unsigned option.
<infinity> Other than for testing, I suppose.
<infinity> apw: So, yeah.  linux-image-flavour Depends linux-signed-image-flavour, done.
<infinity> apw: Much simpler than reworking all the packaging. :P
<infinity> (Throw an [amd64] in there)
<infinity> apw: Belt and bracers that with linux-image-$abi-flavour Depends linux-signed-image-$abi-flavour, and even people who install individual linux-image packages can't screw themselves.
<infinity> The latter would actually remove the need for the former.
<infinity> And the linux-signed metas could just go away.
<infinity> Oh.  But that has a chicken and egg issue where you (incorrectly) build-depend on linux-image to create linux-signed. ;)
<infinity> Meh.
<infinity> apw: Okay, shutting up.  Put it on the agenda for next week please.
<slangasek> cyphermox: hurr, not building in the 'linux' module means we also don't have the 'linux' command; makes our grub.cfgs a bit broken
<cyphermox> doh.
<infinity> alias linux linuxefi?
<infinity> Doubt that grub.cfg allows aliases, mind you. :P
<slangasek> that sounds like something requiring a change to grub.cfg also :)
<slangasek> we *can* work around that by changing grub.cfg
<slangasek> but that means it's not just a drop-in replacement
<infinity> Well, that could go in grub.d, if it was a thing.
<slangasek> ... not on ubuntu-core
<apw> infinity: yep
<infinity> Heh.  Right.
<infinity> cyphermox: BUILD_PACKAGES += grub-efi-enforce, REAL_PACKAGES += grub-efi-enforce, and add configure and build stamps, applying patchset in the latter?
<infinity> Perhaps after copying the source around, so you can (a) avoid parallelism issues with applying a patch mid-build and (b) rm -rf the patched source when done with it.
<cyphermox> or I could maybe cheat and really alias linux to linuxefi in the binary itself.
<slangasek> infinity: so then you're build-time-applying patches in a 3.0 (quilt) package, WIN :)
<infinity> slangasek: Hey, what could possibly go wrong?
-queuebot:#ubuntu-release- Unapproved: clutter-gst-3.0 (zesty-proposed/main) [3.0.22-1 => 3.0.24-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (yakkety-proposed) [0.5.0+git1.656f8865-5ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (zesty-proposed/main) [17.04.2 => 17.04.3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (xenial-proposed) [0.5.0+git1.656f8865-5ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [source] (yakkety-proposed) [2.76-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [source] (xenial-proposed) [2.75-1ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (yakkety-proposed) [1.0.25+git20150528-1ubuntu2.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (xenial-proposed) [1.0.25+git20150528-1ubuntu2.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (yakkety-proposed) [3.5.7-1ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (xenial-proposed) [3.5.7-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:6.9.7.4+dfsg-2ubuntu2 => 8:6.9.7.4+dfsg-2ubuntu3] (desktop-core, ubuntu-server)
<nacc> infinity: urgh, sorry, i missed one more component mismatch for the libjxr-tools change (another binary package from src:imagemagick). Just uploaded ubuntu3 --^
-queuebot:#ubuntu-release- Unapproved: asterisk (xenial-proposed/universe) [1:13.1.0~dfsg-1.1ubuntu4 => 1:13.1.0~dfsg-1.1ubuntu4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (yakkety-proposed) [1:1.2.8-9.2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (xenial-proposed) [1:1.2.8-9ubuntu12.1]
#ubuntu-release 2017-03-31
-queuebot:#ubuntu-release- Unapproved: accepted imagemagick [source] (zesty-proposed) [8:6.9.7.4+dfsg-2ubuntu3]
<slangasek> tumbleweed: it seems you uploaded an SRU of pollinate to trusty 71 days ago which references a wrong bug number in the changelog... I guess arges overlooked the wrong bug number in the trusty upload since yakkety and xenial were fine.  I'm going to remove-package it now and either you or I can reupload (1656484 vs. 1456484)
<slangasek> tumbleweed: hmm nevermind I'll just reupload, it's not worth the mental effort /not/ to ;P
<slangasek> cyphermox: do you recall where things were left with golang-go.crypto and LP: #1634609?  Did you try to rebuild the revdeps?
<ubot5> Launchpad bug 1634609 in juju-core (Ubuntu Zesty) "de-vendorize golang-go.crypto from juju-core" [Undecided,New] https://launchpad.net/bugs/1634609
<slangasek> mm. where does the blacklist of xenial/s390x/akonadi live, given that it does not appear to be in lp:~ubuntu-release/+git/autopkgtest-cloud ?
<slangasek> it is... outside the VCS on wendigo
<slangasek> Laney: ^^ do you know why the s390x worker.conf isn't in the VCS?
<tumbleweed> slangasek: err, yeah, sorry I know I left some SRUs hanging
<cyphermox> slangasek: not done yet, xenial's crypto in proposed doesn't need to build revdeps (but I had tried some, things were building properly). In yakkety, we removed crypto because it broke other things, plus it needed the rebuilding of half the golang world; if we still want to go with the SRU it would need to be started again
<handsome_feng> Hi, could someone in archive admin team apporve the ubuntukylin-theme and ubuntukylin-wallpapers? It's just some updates of theme and wallpapers, Thanks!
<slangasek> cyphermox: why do you say we don't need to rebuild revdeps for xenial?  nothing in the SRU bug says there is a different test case here for xenial than yakkety
-queuebot:#ubuntu-release- Unapproved: showq (zesty-proposed/universe) [0.4.1+git20161215~dfsg0-2 => 0.4.1+git20161215~dfsg0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted showq [source] (zesty-proposed) [0.4.1+git20161215~dfsg0-2ubuntu1]
<tjaalton> infinity: so, what's the verdict on xserver? i'd like to have some time to react in case there are some bugs actual users would hit
-queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.23-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04.2] (no packageset)
<slangasek> apw, cpaelzer: libvirt 2.1.0-1ubuntu9.3 was accepted into yakkety-proposed built with a wrong -v option; the change from 2.1.0-1ubuntu9.2 is not linked from the .changes file and no one has verified this bug.  This should really get reuploaded with a bumped version number and a fixed .changes file
<slangasek> that bug is LP: #1672367
<ubot5> Launchpad bug 1672367 in qemu (Ubuntu Yakkety) "libvirt uses password-secret on old style drive_add syntax" [Undecided,Fix committed] https://launchpad.net/bugs/1672367
<apw> slangasek, bah did i do that, bad on me
<slangasek> apw: oh - no, you didn't, you accepted nova and arges accepted libvirt
<apw> well i will take it as a timely reminder to check because it creates work none the less
<slangasek> :)
<slangasek> cpaelzer: also the test case in the description of LP: #1665698 (the bug that is linked) makes no sense to me, so I'm not sure how jamespage verified it...
<ubot5> Launchpad bug 1665698 in OpenStack Compute (nova) ocata "/etc/qemu-ifup not allowed by apparmor" [High,In progress] https://launchpad.net/bugs/1665698
 * slangasek highlights all the people
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.23-0ubuntu1~14.04.2]
<cpaelzer> slangasek: apw: trying to sort out what you mean there - is the -v something I forgot or something that was missed when accepting it?
<cpaelzer> slangasek: apw: the upload does 9.2 and 9.3 and I assume that the -v would have been to link up the changes of 9.2 as well?
<apw> cpaelzer, the -v should always point to the current version in -updates so that the tools know that all the ones since then are new
<cpaelzer> apw: ok so my assumption was right at least on that
<cpaelzer> apw: I wonder what I should/could do now
<cpaelzer> apw: the upload itself is correct
<cpaelzer> apw: the tests are correct, although I understand the descriptions can be misleading - I'm currently updating as good as possible in the bugs
<cpaelzer> apw: yet I assume there is no way to "link" the bug that was forgotten after the fact
<apw> cpaelzer, steve is suggesting a no-change rebuild with version +1 (ie no changes) and the right -v
<apw> cpaelzer, accepting that over the top will let the tooling sort itself out and the resulting bits will be basically the same
<cpaelzer> ah thanks I didn't get the no change - I thought I should even worse mess up the changelog, but a no-change makes sense to me
<cpaelzer> apw: thanks, I'll prepare something and if it is ok for you contact you once it is in unaccepted
<apw> cpaelzer, i assume it would be *9.4 with a 'no change rebuild' as the changelog entry
<apw> cpaelzer, let us know here you have done that, and we can get it sorted
<cpaelzer> apw: does the following make sense as a changelog entry then: "no change rebuild to properly pick up all the changes since the last release to yakkety-updates." ?
<cpaelzer> ah that is genchanges, so it is me who should have wrapped that, good that I checked before the upload
<cpaelzer> yeah, that looks much better
<apw> cpaelzer, yeah that sounds fine to me
<cpaelzer> I must admit I never realized so far (shame on me) this was an upload side thing, I thought the bug linking would be done due to the tooling when accepted
<cpaelzer> +1 to the (almost) secret packaging knowledge count
<apw> cpaelzer, it is the tooling which works out which bugs to play with, but it does so from the changes file
<cpaelzer> apw: I expected the tooling to distrust .changes anyway and debdiff vs -updates or such anyway
<cpaelzer> apw: it is in yakkety-unapproved now, could you give it a double check?
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu9.3 => 2.1.0-1ubuntu9.4] (ubuntu-server, virt)
<apw> cpaelzer, looks better indeed
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9.4]
<flexiondotorg> Can I request reviews for ubuntu-mate-artwork, brisk-menu, mate-menu, mate-control-center and mate-themes please.
-queuebot:#ubuntu-release- Unapproved: stress-ng (zesty-proposed/universe) [0.07.27-1 => 0.07.28-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (zesty-proposed) [0.07.28-1]
<Laney> slangasek: s390x conf> I'm not sure I even knew that detail (or if I once did, I've forgotten), so nope - ask pitti?
<jamespage> cpaelzer, slangasek: I may have not commented on the right bug for that libvirt issue - apologies (had a few in the air last week)
<cpaelzer> jamespage: I think we are fine now, although it is a no-change-rebuild if you could spin off another tempest for the rbd bug that would be kind
<cpaelzer> jamespage: I'm planning to the other (qemu/ifup) test for libvirt somewhen later today against proposed
<jamespage> cpaelzer: great
<cpaelzer> since it is a no-change if you feel bold enough just say it works (as before), but I'm always a coward and will retest
<jamespage> bdmurray: btw the nova autopkgtest failure cleared itself for the libvirt in proposed (although we now have new libvirt again)
<jamespage> cpaelzer: I can run the verification testing in the lab - takes time but not really mine
<cpaelzer> perfect, machines are there to serve us
-queuebot:#ubuntu-release- Unapproved: youtube-dl (zesty-proposed/universe) [2017.03.07-1 => 2017.03.26-1] (lubuntu, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: libosl (zesty-proposed/universe) [0.8.0-1 => 0.8.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libosl [sync] (zesty-proposed) [0.8.0-1.1]
-queuebot:#ubuntu-release- New binary: libosl [amd64] (zesty-proposed/universe) [0.8.0-1.1] (no packageset)
<tjaalton> could someone ack libdrm which adds amd vega support, eventually needed by mesa
-queuebot:#ubuntu-release- Unapproved: accepted less [source] (zesty-proposed) [481-2.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-docs (zesty-proposed/universe) [16.10.1 => 17.04.1] (ubuntukylin)
<apw> tjaalton, that is a fair sized update with "new upstream release" as the entire documentation
-queuebot:#ubuntu-release- New sync: telegram-desktop (zesty-proposed/primary) [1.0.14-1]
<tjaalton> apw: these are backported to lts as-is
<tjaalton> nothing ever broke
<apw> tjaalton, oh am i reviewing the wrong one then, i was looking at zesty
<tjaalton> no
<tjaalton> zesty
<tjaalton> this would be backported to xenial
<tjaalton> after release
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (zesty-proposed) [7.1.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (zesty-proposed) [2.1.15-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (zesty-proposed) [17.04.9]
-queuebot:#ubuntu-release- Unapproved: accepted eject [sync] (zesty-proposed) [2.1.5+deb1+cvs20081104-13.2]
-queuebot:#ubuntu-release- Unapproved: accepted xkeyboard-config [source] (zesty-proposed) [2.19-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rawtherapee [source] (zesty-proposed) [5.0-1ubuntu1]
<tjaalton> https://pastebin.com/ag81nMQX
<tjaalton> git log diff
<apw> tjaalton, thanks, whoever does those in debian should include some of that info in the package
<tjaalton> some packages have the git log diff as upstream ChangeLog
<tjaalton> pkg-xorg packages i mean
<apw> that would be nice
<apw> ok that does look to be essentially bug fixes anyhow
<ogra> it seems like the live-build SRU into xenial broke core snap builds ...
<ogra> (tries to remove systemd and install upstart during build)
<apw> ogra, it is a good job that snaps are in the archive and can trigger adt tests to prevent those kinds of regressions
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (zesty-proposed) [2.4.76-1]
<ogra> apw, well, the core snap has a travis hook, not sure if you can pull that into adt
<apw> tjaalton, ^
<tjaalton> apw: cool, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted gtksourceview2 [source] (zesty-proposed) [2.10.5-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (zesty-proposed) [1.8.7-1ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted kombu [sync] (zesty-proposed) [3.0.35+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted screen [source] (zesty-proposed) [4.5.0-4ubuntu1]
<apw> ogra, i doubt we can easily do that, but ... you could test the -proposed versions when they appear perhaps to catch this for next time
<ogra> not easily
<ogra> i'ÃD have to set up anopther github branch just for pointing to proposed i fear
<apw> oh well, i guess we just get to break when it hits updates then
<ogra> it didnt break for 2 years :P
<ogra> has it been tested with xenial --minbase builds at all ?
<ogra> iirc we had special handling of upstart packages there
<apw> ogra, so the change there is to purge packages which are no longer marked essential in the updates pocket
<ogra> ++# remove all installed packages that are Prio: required in the release
<ogra> ++# pocket but something else in the latest version
<ogra> "something else"
<ogra> and yes, i have the diff in front of me
<apw> anything else is probabally a better wording
<ogra> as i said, i belive there was some special handling of init systems in xenial that pitti implemented
<apw> got a log for what yours did ?
<ogra> here is the last working build (search for lb_chroot_install): https://launchpadlibrarian.net/313520770/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<ogra> and here is a current build https://launchpadlibrarian.net/313704330/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<apw> as it rmeoving upstart sounds more believable than it removing systemd from those words ... very odd
<ogra> yes
<ogra> but as i said, iirc pitti did something special there (for the phone ? cant remember)
<ogra> looking at the bottom of the live-build diff, just another env var to make it skip that step should be enough, i can easily export that
<apw> ogra, i am not sure that is the right approach
 * apw tries to grok the effect of this code accuratly
<apw> ogra, so if i read this code right it looks to see all things marked required at release pocket versions, it checks the current version of just those to see how they are marked, if they are not still required it simulates remove them, if only they are removed in that simulation they are removed for real
<apw> ogra, so its not at all clear how that would trigger your extra installs
<ogra> it removes systemd-sysv
<apw> which looks right in the sense it was required and is now only important
<ogra> i dont see why though, it is still prio required here
<ogra> oh ?
<ogra> why does my desktop not thing so
<apw> sorry my check was zesty
<ogra> what i dont get in that code is that the first run uses the version, the second doesnt and it is expected that the Prio filed changed between these two ...
<ogra> ... but i'm building an image so i will always have the latest version of the package anyway
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-wizard (zesty-proposed/universe) [16.10.0 => 17.04.0] (ubuntukylin)
<apw> ogra, so apt-cache shows you all the ones available to you not just the most recent
<ogra> well, for the release i'm currently building for only ...
<ogra> and since i build from scratch i should already have the latest version
<apw> ogra, so ... i canont acount for why it thinks systemd-sysv wants to be removed in xenial
<ogra> me neither ... but it surely happens :)
<apw> you odn't have systemd in your PPA do you ?
<ogra> hmm, there is an obsolete version idling around
<ogra> https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
<ogra> argh
<ogra> not as obsolete as LP wants to make me think
<apw> well it might show up on the list, me tries
<apw> adding that here
<ogra> seems the "newer version" it points to is only in -proposed
<apw> i also think there is a separate bug here, that if the removal causes an install it should not be implemented
<apw> ogra, would you file a bug for me on live-build, so i have somewhere to vomit my analysis ?
-queuebot:#ubuntu-release- Unapproved: less (xenial-proposed/main) [481-2.1ubuntu0.1 => 481-2.1ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: less (yakkety-proposed/main) [481-2.1ubuntu1 => 481-2.1ubuntu1.1] (core)
<ogra> on it
<apw> ogra, your ppa version seems newer than everything in the archive, not that i am sure we take version into account
<ogra> the build takes version into account indeed
<ogra> LP actually points to https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu17 as newer version ... but doesnt take into account this is only proposed
<ogra> i got cheated by the LP UI
<apw> ogra, ahh ok, but regardless of that it is not clear that if -updates was really newer we would notice that if your PPA is present, any of them not being required is enough
<apw> to my reading of the code
<ogra> right
<apw> but in your case it is right to want to remove it, it is wrong (separatly imo) to actually remove it because it causes installations
-queuebot:#ubuntu-release- Unapproved: accepted kdevelop [source] (zesty-proposed) [4:5.0.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [source] (zesty-proposed) [1.18.0-0ubuntu2]
<apw> and that is "too much"
-queuebot:#ubuntu-release- Unapproved: accepted brisk-menu [source] (zesty-proposed) [0.3.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-wallpapers [source] (zesty-proposed) [17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (zesty-proposed) [3.22.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-greeter-session-broadcast [source] (zesty-proposed) [0.1+14.10.20140601-0ubuntu5]
<ogra> Bug #1678042
<ubot5> bug 1678042 in live-build (Ubuntu) "removal of priority changed packages breaks builds of the core snap" [Critical,New] https://launchpad.net/bugs/1678042
<apw> ogra, thanks, will propose a fix for that ... is that something you can test ?
<ogra> i could push live-build into the PPA i guess
<ogra> that would override the archive if the version is picked high enough
<apw> ogra, really?  isn't the PPA only used within the build ?
<apw> anyhow we can try it i guess
<ogra> apw, so running the script snippet in a classic shell on the core install on a pi here actually agrees that systemd-sysv isnt required
<apw> let me actually fix this bug :)
<ogra> no, we pull livecd-rootfs from there
<ogra> so it is also used for the outer build chroot
<apw> ogra, yeah i can see that in a xenial vm too so with your PPA addded , so i can at least test a bit
<apw> ok good
<ogra> it seems it is pulled in from init by default now
<ogra> (which itself is actually required but has a "Pre-Depends: systemd-sysv | upstart-sysv" )
<ogra> i think that was the trick that pitti implemented to make it possible to have phone builds with upstart still working in xenial or some such
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (zesty-proposed/universe) [17.04.5 => 17.04.6] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: choose-mirror (zesty-proposed/main) [2.77ubuntu1 => 2.78ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: openssh (zesty-proposed/main) [1:7.4p1-9 => 1:7.4p1-10] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-82-g0e2030ca-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (zesty-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-87-gd23543eb-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (zesty-proposed) [17.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted clutter-gst-3.0 [sync] (zesty-proposed) [3.0.24-1]
-queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [sync] (zesty-proposed) [2017.03.26-1]
<apw> ogra, see the bug for my write up and a potential fix, if you can test that all the better
<apw> ogra, it is obviously untested as a whole though the various bits are tested by hand
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-docs [source] (zesty-proposed) [17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (zesty-proposed) [17.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-wizard [source] (zesty-proposed) [17.04.0]
<ogra> apw, pushed to the PPA ... lets see
<apw> slangasek, see bug #1678042
<ubot5> bug 1678042 in live-build (Ubuntu) "removal of priority changed packages breaks builds of the core snap" [Critical,New] https://launchpad.net/bugs/1678042
<apw> ogra, separatly we need to consider if you are able to change the priority of systemd in that ppa to match what it should be
<cjwatson> In theory change-override should work on PPAs, though I'm not sure I've ever tested it.
<cjwatson> -A ppa:OWNER/ubuntu/NAME
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
<ogra> apw, yeah, seems the debian/control file actually has "Priority: important" ... i can fix that after testign your change
<ogra> apw, https://launchpad.net/~snappy-dev/+snap/core if you want to watch it
<ogra> oh, that failed fast
<ogra> err, or not ... the UI cheated me (once again)
<infinity> We should just revert to the much simpler and less error-prone "Remove locales and tzdata after debootstrap" method I had proposed.
<infinity> This attempting to detect downgrades thing is madness.
<ogra> funnitly we even remove locales in our image with a live-build hook at the end :)
<ogra> so for me the gain of that change is perfectly at zero
-queuebot:#ubuntu-release- Unapproved: kylin-greeter (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
<infinity> Not all changes are for you? :P
<ogra> damn ...
<ogra> :)
<ogra> apw, looks like that build got past the breakage ... but waitign for the full log to actually see it also ended up as it should be
<ogra> hmm
<ogra> it works but i dont see it remove locales after deboostrap
 * ogra wonders if he missed something when applying the diff
<ogra> this looks exactly like before the breakage, i would at least expect locales to be removed
<ogra> oh
<ogra> /usr/lib/live/build/lb_chroot_archives: 64: [: Illegal number:
<apw> oh ?
<apw> oh what a fool i am
 * apw fixes
<apw> ogra, i assume you can see the obvious error s/-eq/=/
<apw> ogra, but for clarity i will update the debdiff in the bug
<ogra> yeah
<apw> ogra, ok updated, see if that works better
<ogra> pushed
<infinity> http://paste.ubuntu.com/24287455/
<infinity> I'd prefer this.
<infinity> It'll need another upload after we demote tzdata, though maybe I can just do that right now.
 * ogra ponders to drop all that building for core and instead use ubuntu-base in the future and add/remove there instead
<infinity> Err, "add/remove there"?
<ogra> well, that is what we do when building core
<apw> infinity, i would argue you should still check that the removal is clean and installs nothing
<infinity> No, you don't get to repurpose base.
<ogra> debootstrap --minbase ...
<apw> infinity, in case some other package has bee modified
<ogra> then add a few packages and then mangle the hell out of it
<apw> infinity, and added a dep or whatever
<infinity> apw: Why?  We know we want to remove locales at that stage on xenial.  If that fails, there's a bug that needs investigating, and a failed build is better than a silent misbuild.
<ogra> infinity, i dont want to re-purpose, i just want to base on it
<apw> infinity, but do we not explicitly allow us to add random PPAs to the build and they are allowed to make changes
<infinity> ogra: Oh.  Yes, it should perhaps be a minbase variant + stuff.
<ogra> right
<infinity> apw: They're not allowed to make changes to the debootstrap set.
<infinity> apw: Simply because debootstrap doesn't allow that.
<ogra> the team wants a rootfs tarball that they only add snapd bits to ... so i have to re-think how i build anyway
<infinity> apw: We control everything up to the point I patched.
<ogra> (to have better snapshot abilities ti roll back snapd on an unchanged rootfs)
<apw> infinity, they could change systemd in that set to depend on locales, and then you would force remove both no ?
<infinity> apw: Which is why my 1-line patch is much safer than Steve's 30.
<infinity> apw: No.  I remove RIGHT AFTER DEBOOTSTRAP.
<infinity> apw: Unlike Steve's patch, which removes when the apt archives are all set up.
<ogra> well, for his setup he needs the archives set up
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (zesty-proposed/universe) [2.1.5-0ubuntu1 => 2.2.1-0ubuntu1] (ubuntukylin)
<infinity> Right, he does.
<apw> right but it is at the same point we would have installed the versions from a PPA in your form too no ?
<infinity> apw: In my scenario, you have exactly one source.  ubuntu/xenial-release/main.
<ogra> for yours you should add the ability to have a list (via LB_ vars or so)
<infinity> apw: debootstrap can't use multiple archives.
<apw> ok
<ogra> instead of just hardcoding locales
<apw> so i f we have a PPA we would later upgrade and reinstall locales
<apw> and all is well
<infinity> ogra: No, I shouldn't.  This isn't meant to be an extensible thing.  This is a one-time slimming retroactively.
<ogra> ah, well, steves explanation sounds like thats a broader meant thing
<ogra> (in the patch description)
<infinity> Another reason I wish Steve hadn't implemented it as if it were an ongoing thing to be abused.
<ogra> if it is solely locales thats indeed better
<infinity> It'll be locales and tzdata, AFAIK.
<ogra> ah, that one we "seed" i think
<infinity> You do.
<infinity> And both are in minimal, so they get installed later for all variants except base.
<infinity> So, y'know what, I'll amend this patch to include tzdata too.
<ogra> we dont install minimal
<infinity> The archive demotion isn't actually relevant.
<ogra> core is smaller :)
<ogra> but we have a metapackage that depends on tzdata
<infinity> I know.
<apw> infinity, not with your approach :)
<infinity> core-libs.
<infinity> Which is gross.
<infinity> Anyhow.
<apw> so i assuem for ogra we will remove it and he will put it back and not notice
<ogra> we have another core-meta (that i need to merge eventually)
<apw> infinity, so ... i assume i can just give you this bug :)
<ogra> apw, right
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.9 => 17.04.10] (ubuntu-mate)
<infinity> apw: No, you get to review my 1-line upload. ;)
<infinity> apw: After ogra tests it for me.
<ogra> well, once the test of apw's last change finished ...
<infinity> Heh.
<ogra> the core build only takes a few mins anyway ... it is quick :)
<infinity> ogra: dget http://lucifer.0c3.net/~adconrad/live-build_3.0~a57-1ubuntu25.3~adam1_source.changes
<infinity> And even simpler fix (just drop the patch altogether) uploaded to zesty.
-queuebot:#ubuntu-release- Unapproved: live-build (zesty-proposed/main) [3.0~a57-1ubuntu28 => 3.0~a57-1ubuntu29] (desktop-core)
<infinity> ogra: Ima play some video games while you test that ~adam1 version for me.  If the logs look sane to me, we'll bounce it at the queue and expedite it.
<ogra> ok
<ogra> infinity, just FYI seems steves change with apw's fix actually runs but adds 20min build time now :P
 * ogra ponders to just kill all the builds 
<infinity> ogra: That seems... Bizarre.
<infinity> ogra: Did Andy accidentally write an infinite awk loop?
<ogra> it goes over dplg -l and then loops over all packages with apt
<infinity> ogra: Anyhow, please test mine.  I'm not really interested in investing more time in the complex solution.
<ogra> it removed locales just fine but seesm to still loop over packages
<infinity> Sunk cost fallacies and such.
<ogra> https://launchpad.net/~snappy-dev/+snap/core/+build/30634
<ogra> Purging configuration files for locales (2.23-0ubuntu3) ...
<infinity> Yeah, that's hung.
<ogra> sits there since a while
-queuebot:#ubuntu-release- Unapproved: appstream (xenial-proposed/main) [0.10.6-1~ubuntu16.04.2 => 0.9.4-1ubuntu3] (kubuntu, ubuntu-desktop)
<infinity> I killed it.
<ogra> ok
<infinity> The only "downside" of my patch is that if people want to demote more packages, they need another SRU.  And, honestly, I think that's a feature, not a bug.
<infinity> I'm not keen on stable image builds suddenly changing randomly because someone's working on a minimal cloud image and messing with things.
<ogra> well, worst case you can always make it an LB_REMOVE_DEMOTED list or so
<infinity> No.
<infinity> Also, no.
<ogra> in case someone freaks out about having to SRU
<infinity> This is not a feature.  It's a hack.  Hacks should not be configurable, or they become features.
<infinity> The first moment someone relies on this being extensible is when it breaks.
<infinity> As it did.
<infinity> Because it was written to be extensible. :P
<ogra> well, it broke because of a PPA package in the end
<ogra> but yeah
<infinity> Sure.  But it was still overengineered and bound to have corner cases.
-queuebot:#ubuntu-release- Unapproved: rejected live-build [source] (zesty-proposed) [3.0~a57-1ubuntu29]
-queuebot:#ubuntu-release- Unapproved: live-build (zesty-proposed/main) [3.0~a57-1ubuntu28 => 3.0~a57-1ubuntu29] (desktop-core)
<ogra> yup
<infinity> When the intent is "remove two packages", the patch should be "remove two packages".
 * infinity shrugs.
<ogra> i still dont get why this is in live-build and not in livecd-rootfs though
<infinity> Because I told Steve to put it in live-build, because my patch was the fix I envisioned.
<infinity> Then he went and found an entirely different part of live-build to do it in. :P
<ogra> we seem to start to spread distro changes across ...
<infinity> For mine, live-build is the obvious place for it.
<ogra> (though it probably doesnt matter much given live-build is already at -ubuntu25)
<infinity> livecd-rootfs has no really good place to put it.
<infinity> But also, this is a xenial-only hack.
<infinity> Hack, hack, hack.  Remember? :)
<infinity> The goal for stable patches should be efficiency and readability, not future extensibility.
<ogra> yeah, translates to hook in my head since i work on core and phones :P
<estan> hi folks. would be great if someone could have a look at the qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 currently in the xenial upload queue (result of my bug https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173).
<ubot5> Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New]
<ogra> (i lately use live-build/hooks inb livecd-rootfs for nearly everything ... has the advantage of having all hacks in one place)
<ogra> though as i said, we might move away completely from that build infra and just use some scripts on top of -base
<ogra> ah, looks ... ppc64el is already done building
 * ogra chacks the log
<ogra> I: Base system installed successfully.
<ogra> (Reading database ... 7247 files and directories currently installed.)
<ogra> Removing locales (2.23-0ubuntu3) ...
<ogra> Purging configuration files for locales (2.23-0ubuntu3) ...
<ogra> Removing tzdata (2016d-0ubuntu0.16.04) ...
<ogra> looks good !
<infinity> And tzdata gets correctly re-added later.
<infinity> So, success.
<ogra> yup and all the locales hackery is still there and working as well
<ogra> (we do some extra stuff with the package later)
<ogra> infinity, so upload it then :)
<infinity> apw: Fixed in the xenial and zesty queues for that bug.
<infinity> s/Fixed/Fixes/
<infinity> apw: Please review/accept.
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.2 => 3.0~a57-1ubuntu25.3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted choose-mirror [source] (zesty-proposed) [2.78ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-greeter [source] (zesty-proposed) [17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (zesty-proposed) [17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-china-weather [source] (zesty-proposed) [2.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (zesty-proposed) [17.04.10]
-queuebot:#ubuntu-release- Unapproved: rejected live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.3]
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.2 => 3.0~a57-1ubuntu25.3] (desktop-core)
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (zesty-proposed/universe) [17.04.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (zesty-proposed) [3.0~a57-1ubuntu29]
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.3]
-queuebot:#ubuntu-release- Unapproved: skiboot (zesty-proposed/universe) [5.3.3-1ubuntu1 => 5.4.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted skiboot [sync] (zesty-proposed) [5.4.3-1]
<slangasek> apw, cpaelzer: I wouldn't normally do 'no-change rebuild' for an SRU, I would just increment the version number of the upload in the changelog, build with the right -v option, and reupload
<apw> slangasek, i can see that, will recommend that in future
<slangasek> Laney: s390x conf> ok, if you're not making changes to that file then I should just log a bug about us needing to get it into the VCS
<slangasek> infinity: 1678042> err, you've dropped this from zesty? so if we ever have a similar stable demotion in the future we will need to do archaeology on live-build's code?
<slangasek> apw, infinity, ogra: so did someone fix the priority of systemd-sysv in the ppa, to unblock those core builds?
<ogra> slangasek, no, i'll do that before EOD though
<slangasek> ok
<slangasek> why do you have systemd in the ppa?
<ogra> i'd have to ask mvo who is off today ... some network thing it seems
<ogra> slangasek, bug 1678042 btw
<ubot5> bug 1678042 in live-build (Ubuntu Xenial) "removal of priority changed packages breaks builds of the core snap" [Critical,Fix committed] https://launchpad.net/bugs/1678042
<slangasek> ah, the network thing, right :/
<slangasek> ogra: yeah, a highlight from apw on the bug was what prompted my question :)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.23.6]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.1 => 2.23.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.23.6+16.10]
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.1+16.10 => 2.23.6+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.23.6~14.04]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.23.6~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (yakkety-proposed/universe) [3.22.6-0ubuntu1 => 3.22.7-0ubuntu1] (desktop-extra)
<ChrisTownsend> Hi!  Should I be concerned that libertine and ubuntu-app-launch haven't migrated out of zesty-proposed yet?
<nacc> ChrisTownsend: libertine seems to break ubuntu-touch (per update_output.txt)
<nacc> ChrisTownsend: same for the other, i tink?
<nacc> *think
<ChrisTownsend> nacc: Grr, ok, I wonder how.
<ChrisTownsend> nacc: Thanks.  I saw the raw output, but I'm learning how to decipher it:)
<apw> ChrisTownsend, yeah as nacc says either of those causes ubuntu-touch to be deinstalled
<nacc> ChrisTownsend: http://paste.ubuntu.com/24288801/
<nacc> ChrisTownsend: from `chdist apt-get zesty-proposed install libertine ubuntu-app-launch ubuntu-touch`
<nacc> ChrisTownsend: so there must be some dependencies down that hole :)
<ChrisTownsend> nacc: Great, this will be fun to figure out what is is:/
<apw> ubuntu-touch seems to dep: on both directly if i am reading reverse-depends output right
<apw> have we lost some arches or something ?
<ChrisTownsend> It definitely deps on ubunu-app-launch, but only deps on libertine-tools.
<apw> * ubuntu-touch [amd64 arm64 armhf i386]  (for python3-libertine-chroot)
<apw> * ubuntu-touch [amd64 arm64 armhf i386]  (for libertine-tools)
<ChrisTownsend> apw: Ohhhh, yeah, I bet that is what it is.  We are now having to restrict some archs due to Xmir only being built on amd64, i386, arm64, and armhf.
<apw> both of those
<ChrisTownsend> frick
<ChrisTownsend> apw: thanks
-queuebot:#ubuntu-release- Unapproved: tomcat7 (trusty-proposed/main) [7.0.52-1ubuntu0.10 => 7.0.52-1ubuntu0.11] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tomcat7 (yakkety-proposed/universe) [7.0.72-1 => 7.0.72-1ubuntu0.1] (ubuntu-server)
<dobey> ChrisTownsend: huh. why is xmir not built on all the same archs that mir and xorg are built on?
-queuebot:#ubuntu-release- Unapproved: tomcat7 (xenial-proposed/universe) [7.0.68-1ubuntu0.1 => 7.0.68-1ubuntu0.2] (ubuntu-server)
<ChrisTownsend> dobey: Good question
<ChrisTownsend> dobey: Basically as I understand it, it's poor support or immediate crashes when running in the other archs.
<ChrisTownsend> dobey: But I'm about ready to throw down to get someone to fix xmir so it'll build on the other archs so this damned song and dance will end!
 * apw likes the sound of that
<dobey> ChrisTownsend: well if it builds and just doesn't work, i think that's ok for now
<ChrisTownsend> dobey: I'm not 100% sure it will build.
<dobey> ChrisTownsend: when you find someone that wants to run unity8 on an ibm mainframe, let me know :)
<ChrisTownsend> dobey: hah, yeah, really
<dobey> hmm, well unless it's doing something absurd, there's no reason it shouldn't at least build, i would think
<ChrisTownsend> dobey: I really don't know what the true rationale is.
<dobey> if it's just the tests, you can do like content-hub and just disable them on those archs
<ChrisTownsend> dobey: I'm going to get to the bottom of this.
<bregma> dobey, ChrisTownsend, you'd have to ask tjaalton why Xmir is build for only that subset of architectures, there is not reason I'm aware of why it is so restricted
<ChrisTownsend> bregma: Ok
<ChrisTownsend> bregma: dobey:  This seems to be the commit where the initial restriction occurred: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/xorg-server/vivid/revision/282
<ChrisTownsend> We've since added arm64 in there.
<dobey> oh
<dobey> hmm
<ChrisTownsend> So it's really not clear what the "real" reasons are.
<dobey> well, looks like the previous changelog entry restricted xmir to !powerpc
<ChrisTownsend> But it might be due to old Mir restrictions that have since been removed and xmir never caught up???
<dobey> no idea
<ChrisTownsend> Me neither
<Laney> There's some weird stuff here
<bregma> we need an adult to tell us
<Laney> ubuntu-touch is uninstallable in zesty?
<Laney> without proposed
<ChrisTownsend> Eh?
<Laney> try it
<bregma> I'm not why we care about ubuntu-touch in Zesty
 * ChrisTownsend tries it
<dobey> bregma: because it's there and a seed
<dobey> bregma: we could get the seed updated to not depend on the libertine/xmir stuff that causes the breakage
<ChrisTownsend> Laney: yep
<dobey> which we should probably do now
<dobey> sil2100: ^^ are you still around?
<dobey> Laney, ChrisTownsend: how is it uninstallable exactly?
<Laney> dunno atm
<Laney> something to do with -gles stuff
<dobey> ah conflicts with the non-gles packages?
<ChrisTownsend> http://pastebin.ubuntu.com/24288959/
<dobey> oh yeah, some of that stuff needs to definitely be removed from the ubuntu-touch seed
<Laney> right, but then add one of the uninstallable packages to the commandline
<dobey> and actually i thought a few of those were removed
<Laney> and you can eventually find out what the final reason is
<ChrisTownsend> Seems ubuntu-touch is stale and needs fixing any ways.
<dobey> indeed
<dobey> well, i guess installing qtubuntu-android on a laptop is also a bad idea anyway too
<ChrisTownsend> I think ubuntu-touch itself should be restricted to armhf and arm64.
<tjaalton> bregma: probably set by someone else before me
<ChrisTownsend> tjaalton: Yeah, it was:)
<ChrisTownsend> We can blame RAOF:)
<tjaalton> was my guess as well :)
<bregma> ah, RAOF who is conveniently disappearing on parental leave, he has obviously been planning this for some time
 * bregma digs a good conspiracy
<ChrisTownsend> How dare he?!?!?!
<Laney> yeah can't find out quickly what the problem(s) are, and I've got to go now, sorry
<Laney> hopefully someone gets there :-)
-queuebot:#ubuntu-release- Unapproved: nama (zesty-proposed/universe) [1.208-1 => 1.208-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nama [sync] (zesty-proposed) [1.208-2]
<ChrisTownsend> Is there a requirement that a seed has to support all archs?
<dobey> ChrisTownsend: well it's a metapackage, and metapackages tend to be arch: all
<dobey> don't know if there's a precident for any seeds not being arch: all
<ChrisTownsend> dobey: Sure, just wondering if there is a hard requirement.  ubuntu-touch makes 0 sense on anything besides armhf/arm64.
<dobey> precedent even
<dobey> ChrisTownsend: well that's not entirely true
<ChrisTownsend> Oh
<ChrisTownsend> dobey: Maybe i386 based devices?
<dobey> ChrisTownsend: it makes no sense on anything that's not android based; it would make perfect sense on an x86 android device that had ubuntu ported to it
<ChrisTownsend> dobey: Right
<dobey> i'm pretty sure android doesn't support any ppc or s390x devices though
<ChrisTownsend> dobey: yeah, that is kind of what I meant.  I didn't think about the x86 version, but you get where I'm coming from.
<dobey> though, without building phone/tablet images, and future ones going to be snaps anyway, i would say ubuntu-touch doesn't make sense as a seed any more at all
<ChrisTownsend> dobey: Yeah, maybe it should just be removed from zesty???
<dobey> ie, it doesn't really make sense in the snaps world. it only makes sense for the .tar.gz preinstalled images for phone/tablet, really
<dobey> well i guess it's probably a bit late to just outright remove it?
<ChrisTownsend> dobey: I guess.  But it needs fixing if it's not removed.  I'm not sure what we can do w/ the restriction in libertine/u-a-l unless someone gets xmir built for those missing archs.
<dobey> slangasek: ^^ you probably have a little more knowledge in the realm of phone/tablet image building process than me, but does it make sense to you to just get rid of ubuntu-touch-meta at this point?
<slangasek> dobey: what is the argument for getting rid of it?
<slangasek> dropping it on archs where it's unsupported is fine, that's a change to the source package
<slangasek> if something else has superseded the metapackage as a definition of the product, please point out what that is
<dobey> slangasek: it doesn't make sense in the realm of snap based images, or general armhf/arm64 builds really. are we still building zesty images in devel-proposed for phone/tablet as a sanity check?
<slangasek> if you're arguing for dropping it because we have no phone product based on zesty and the definition of future phone products is uncertain, that's ok, but then I think we would want a bug report against the package and confirmation from stakeholders
<dobey> slangasek: i think the definition of that product will probably be snapcraft.yaml files in the future, and there's no definition of what a complete "image" for a device would look like at this point afaik
<dobey> hmm, ok
<slangasek> snap based images> is there one of these today, and how are we enforcing the MIR requirements around their contents?
<ChrisTownsend> At the very least, restricting it to amd64/i386/armhf/arm64 would make my life better:)
<dobey> i don't think there are any snap based images yet for phones/tablets
<dobey> we don't enforce the MIR requirements for the current system-image images either, though
<slangasek> yes, and that's a glaring, gaping bug
<slangasek> we got 90% of the way there last cycle when unity8 went on the desktop image
<slangasek> ubuntu-touch should also be required to be in main
<slangasek> thus requiring MIR review for all new dependencies
-queuebot:#ubuntu-release- Unapproved: chameleon-cursor-theme (zesty-proposed/universe) [0.5-5 => 0.5-6] (no packageset) (sync)
<dobey> yeah, i'm not disagreeing with that ideology, just stating how things are today :)
<dobey> oh
-queuebot:#ubuntu-release- Unapproved: accepted chameleon-cursor-theme [sync] (zesty-proposed) [0.5-6]
<dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1619468
<ubot5> Ubuntu bug 1619468 in ubuntu-touch-meta (Ubuntu Yakkety) "Uninstallable ubuntu-touch-meta" [Critical,In progress]
<dobey> ChrisTownsend: ^^ re: earlier issue of it being uninstallable
-queuebot:#ubuntu-release- Unapproved: ginga (zesty-proposed/universe) [2.6.1-1ubuntu1 => 2.6.1-2] (no packageset) (sync)
<ChrisTownsend> slangasek: Is restricting it to the aforementioned archs something reasonable?
<ChrisTownsend> dobey: Ah, ok.
<dobey> man someone really needs to triage the bugs filed against ubuntu-touch-meta
-queuebot:#ubuntu-release- Unapproved: accepted ginga [sync] (zesty-proposed) [2.6.1-2]
<slangasek> ChrisTownsend: of course; having the metapackage on an arch where it can't possibly work is not required
-queuebot:#ubuntu-release- Unapproved: cvs (zesty-proposed/main) [2:1.12.13+real-21 => 2:1.12.13+real-22] (ubuntu-desktop) (sync)
<slangasek> ChrisTownsend: however, I already see ubuntu-touch-meta only on the archs listed, so what changed?
<slangasek> and *where* did it change
<slangasek>  ubuntu-touch          | 1.287   | zesty/universe          | amd64, arm64, armhf, i386
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (zesty-proposed/universe) [10.1.21-5 => 10.1.22-3] (no packageset) (sync)
<ChrisTownsend> slangasek: Errr, so the current libertine and ubuntu-app-launch landing is stuck because of ubuntu-touch.  I figured it was due to now restricting some libertine compnenets to those archs.
<slangasek> ChrisTownsend: link?
<ChrisTownsend> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt <- search 'libertine'
<dobey> just says amd64: ubuntu-touch now
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.1 [sync] (zesty-proposed) [10.1.22-3]
-queuebot:#ubuntu-release- Unapproved: rpm (zesty-proposed/universe) [4.12.0.2+dfsg1-1 => 4.12.0.2+dfsg1-2] (no packageset) (sync)
<ChrisTownsend> Ok, and that is busted even before our landing.
<slangasek> yes, and it says amd64 :)
<dobey> not sure why it says that though :)
<ChrisTownsend> So our landing is caught up in a bigger issue?
<slangasek> no
-queuebot:#ubuntu-release- Unapproved: accepted rpm [sync] (zesty-proposed) [4.12.0.2+dfsg1-2]
<dobey> ubuntu-touch has has installability issues for a long time
<slangasek> no, it hasn't
<slangasek> the very fact that it's listed by name in update_output means this is a regression
<nacc> slangasek: i *think* ubuntu-touch is uninstallable in zesty-proposed period
<dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1619468 <- well this bug has been open for 7 months now
<ubot5> Ubuntu bug 1619468 in ubuntu-touch-meta (Ubuntu Yakkety) "Uninstallable ubuntu-touch-meta" [Critical,In progress]
<slangasek> nacc: this shows that it would be /made/ uninstallable in zesty (not -proposed) by updating libertine
<ChrisTownsend>  But only on amd64?
<dobey> hmm
<nacc> slangasek: i think it's uninstallable in zesty itself too, i meant, sorry
<slangasek> nacc: update_output disagrees with you
<nacc> slangasek: i agree, but try it :)
<nacc> slangasek: i just did on my zesty and i get: http://paste.ubuntu.com/24289195/
<ChrisTownsend> On zesty without proposed: http://pastebin.ubuntu.com/24288959/
<slangasek> intriguing
<nacc> slangasek: i 100% agree that update_output says it's a regression
<nacc> slangasek: and i think it's an *additional* failure now, which is maybe the regression
<nacc> as the conflicts in z-p are much longer, afaict
<slangasek> p-m really shouldn't care about 'additional' failures
<nacc> ok, i wasn't sure
<slangasek> it cares about whether a given package is installable or not
<nacc> yep
<slangasek>  ubuntu-touch : Depends: qml-module-ubuntu-components-gles but it is not going to be installed
<slangasek> that's the root of the problem, dependencies in the tree on both qml-module-ubuntu-components-gles and qml-module-ubuntu-components
<slangasek> so which of those should be used on amd64?
<dobey> the latter
<slangasek> ok, so that's a quick seed fix, let me do that
<ChrisTownsend> In theory, that should fix my issue?
<slangasek> dobey: actually, what I currently see in the seed is:  * qml-module-ubuntu-components-gles [amd64 i386]
<slangasek> dobey: so someone explicitly seeded these for amd64
<slangasek> ChrisTownsend: nope, at the moment I still don't know why update_output is reporting that
<ChrisTownsend> slangasek: lol, ok
<slangasek> basically, it means p-m thinks ubuntu-touch is installable on amd64 currently when it actually isn't
<dobey> slangasek: odd
<dobey> i wonder why that is
<slangasek> dobey: I think it's because the touch metapackage is expected to be usable on goldfish, which is gles-only
<slangasek> dobey: url-dispatcher depends on qtdeclarative5-ubuntu-ui-toolkit-plugin instead of qtdeclarative5-ubuntu-ui-toolkit-plugin | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles, as one example of the breakage
<dobey> hmm
<slangasek> ah - no, it *is* installable, if I hint it as: apt install ubuntu-touch webbrowser-app qml-module-ubuntu-components-gles
<dobey> fun
<slangasek> and what has changed in the new libertine is libertine-tools adds a dep on libertine-xmir-tools -> libqt5gui5 which conflicts with libqt5gui5-gles
<slangasek> why is there a hard-coded dep on libqt5gui5 in libertine?
<bregma> ChrisTownsend, is that pasted? ^^
<larryprice> yes
<ChrisTownsend> slangasek: Because we have a utility called 'pasted' that is a Qt app that is invisible for supporting cut and paste between X applications running on Xmir and native U8 Qt apps.
<slangasek> ChrisTownsend: http://pastebin.ubuntu.com/24289256/ <-- don't hard-code dependencies on libraries?
<slangasek> ChrisTownsend: the question is why is it a *hard-coded* dep.  dh_shlibdeps will automatically pick up ELF dependencies for you
<slangasek> and had already correctly mapped this to libqt5gui5 | libqt5gui5-gles
<bregma> sounds like a easy fix, except for all the paperwork
<ChrisTownsend> slangasek: Oh, well, I didn't know that.
<slangasek> next questions
<slangasek> how did this pass sponsorship review?
<slangasek> because this was a packaging change that someone had to ack
<slangasek> and
<ChrisTownsend> slangasek: Thanks for educating me.
<slangasek> how did this get out of the silo like this without proposed-migration already complaining?
<ChrisTownsend> slangasek: Not sure.
<ChrisTownsend> slangasek: There were no complaints by anything until that ubuntu-touch clue.
<slangasek> yes, but we run p-m on silos so that should have already told us about this problem
<ChrisTownsend> slangasek: nope, it didn't
<slangasek> and whoever acked this packaging should know better than to hard-code library dependencies
<slangasek> i.e. I should not be the first person to have asked you these questions
<ChrisTownsend> slangasek: So you're saying the packages prepended w/ 'lib' there should not be there?
<slangasek> generally speaking, yes
<slangasek> there may be exceptions
<ChrisTownsend> slangasek: Ok, so don't put them there unless they need to be there:)
<ChrisTownsend> slangasek: But maybe some changes to bileto could help catch this before it gets to this point?
<slangasek> kenvandine: ^^ this appears to be your publication
<slangasek> ChrisTownsend: well, I don't know why it didn't already show up as an error via proposed-migration; but the ultimate safeguard here is supposed to be that people who ack packaging changes are sure of its correctness before they publish
 * kenvandine reads back
<ChrisTownsend> slangasek: Ok
<slangasek> however, I'm now confused because I'm looking at https://bileto.ubuntu.com/#/ticket/2576 and the packaging diff there does not show this as a new add
<ChrisTownsend> slangasek: It's not a new package, it's just a change in dependencies.
<slangasek> yes, that's what I mean - this new dep does not show up as new in the diff
<slangasek> oh
<ChrisTownsend> slangasek: In u-a-l?
<slangasek> right, it's the libertine-tools -> libertine-xmir-tools dep that is new, not the libertine-xmir-tools -> libqt5gui5 dep
<slangasek> so that was pre-existing, and I'll never succeed in tracking down who acked that ;)
<ChrisTownsend> slangasek: Right
<slangasek> kenvandine: so you can ignore me, sorry
<kenvandine> slangasek, yeah, that's what i looked at :)
<kenvandine> slangasek, i'll never ignore you
<kenvandine> :-D
<ChrisTownsend> slangasek: Well, at any rate, I'll fix this up and thanks for the lesson (no sarcasm).  I learned a ton in this little foray.
<slangasek> ChrisTownsend: anyway, yes, I can confirm that all of the hard-coded libqt* deps are redundant with autogenerated deps that are already there, so you can drop those, re-publish, and it'll sail through
<slangasek> (I can't tell at a glance if libcontent-hub0 needs to be hard-coded or not)
<ChrisTownsend> slangasek: Ok, the only way to tell if it needs to be hard-coded is to try to install in a pristine system?
<ChrisTownsend> ie, some chroot?
<slangasek> ChrisTownsend: the way to tell would be to build it locally, then look at the contents of debian/libertine-xmir-tools.substvars and see if libcontent-hub0 got added there
<ChrisTownsend> slangasek: Ok, thanks again.
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (yakkety-proposed/main) [3.22.3-0ubuntu0.1 => 3.22.7-0ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: evolution (yakkety-proposed/universe) [3.22.3-0ubuntu0.1 => 3.22.6-0ubuntu0.1] (ubuntugnome, ubuntukylin)
<dobey> yeah you definitely shouldn't need hard-coded deps on libfooN packages except for things like libfoo-dev having versioned dep on libfooN or something like that, or you're doing runtime dlopen() and want to Recommends: a libfooN, which dh_shlibdeps couldn't handle directly
<infinity> slangasek: I don't think "removing things from the debootstrap set post-release" should be a feature we want to "support".  The xenial bits were originally described to me as a one-time hack to slim things down retroactively, but preparing for a future where we intend to do this over and over again is preparing for a future I'm not sure we want.
<slangasek> infinity: fair enough
<infinity> slangasek: Or, to put another way, the required seed has changed 19 times in 10 years, two of those were post-release, both just now.
<ogra> just wait til the extended support for 12.04 kicks in fully in 1-2 years :P
<ogra> (and you have to shuffle all the default package sets )
<infinity> slangasek: Although, as I was falling over from being up all night, an entirely different thing occurred to me.  For >= zesty, this change has changed the outcomes for d-i netboot installs, unless they have the minimal task preseeded.
<infinity> slangasek: Which, sure, maybe they "should", but I bet many don't.
<infinity> ogra: And I have to what?  Why would extending support change packagesets?
<ogra> dunno, because things get completely unsupported or some such ...
<slangasek> infinity: well, that's a major bug in d-i then, which should always have been including minimal by default under our previous definitions of how things are supposed to work
<slangasek> and there may be a bug report open about this, cyphermox may recall it
<slangasek> or xnox
<slangasek> some x
 * slangasek creates a new lp team, ubuntu-nasal-vowel-palatal-sibilant
<infinity> I may have to go back and double-check that, but I don't think we *force* minimal on people.
<infinity> But, indeed, we're also not released, so we have all the time in the next 13 days to figure it out. ;)
<ogra> i think debootstrap defaults to it if you dont use --minbase
<ogra> (or has that changed ? i havent looked for a while)
<slangasek> I'm not saying it needs to be forced, but I do think it should require explicitly opting out of minimal to not have it, not as a side effect of e.g. preseeding other tasks
<infinity> ogra: Oh.  You're sort of right.
<infinity> Non-minbase debootstrap includes Prio: important, of course.  So this change is a no-op there.
<infinity> Right, nevermind. :P
<infinity> slangasek: Well, that's not really how tasksel works, though.  And changing the syntax won't help anyone.
<infinity> slangasek: You get one preseed line to select tasks.  So either we make some mandatory, or they get exactly the ones they asked for.
<slangasek> xnox, cyphermox: congratulations, you're the only two members of ubuntu-nasal-vowel-palatal-sibilant on this channel; only ginggs comes close, but he would have to be ubuntu-vowel-nasal-palatal-sibilant
<infinity> (But nevermind this in context of tzdata and locales, I'm too tired to think straight, debootstrap will still pull those in)
<slangasek> infinity: "one preseed line to select tasks" - that's the part of the design which I think is flawed; I think you should have a default set that you can both add to or remove from
<infinity> It might indeed be that minimal == important, based on how we lay out seeds and priority-mismatches, and the longstanding bug was that we don't force *standard*.
<slangasek> right
<slangasek> I believe that to be true
<infinity> In my defense, I kinda just fell over this morning, and only 3 hours sleep resulted.
<infinity> Which is more than the not-nap I hadn't planned.
<infinity> But less than seems reasonable.
-queuebot:#ubuntu-release- Unapproved: nagios3 (zesty-proposed/main) [3.5.1.dfsg-2.1ubuntu4 => 3.5.1.dfsg-2.1ubuntu5] (ubuntu-server)
<ginggs> slangasek: are you bored? :)
<slangasek> ginggs: no, I'm clearly entertained
<ginggs> I have some universe packages to be removed - could be entertaining :)
<slangasek> ginggs: nothing from you at https://bugs.launchpad.net/~ubuntu-archive/+assignedbugs ?
<ginggs> slangasek: I didn't think of assigning them to myself seeing I can't actually remove them
<slangasek> ginggs: I mean that I see no bugs assigned to ~ubuntu-archive that you filed
<ginggs> oh, I've been subscribing ~ubuntu-archive, not assigning
<ginggs> assigning now...
<cjwatson> used to be that subscribing was preferred ...
<jbicha> slangasek: https://wiki.ubuntu.com/ArchiveAdministration says ubuntu-archive should be subscribed not assigned
<slangasek> ah, well then :)
<ginggs> in my experience, subscribing doesn't seem to work :)
<cjwatson> I don't think there's any likely mechanism by which assigning would work better
<slangasek> perhaps it works better only in the sense that https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs currently gives me a timeout that +assignedbugs did not :D
<cjwatson> I was hoping nobody was going to mention that
<cjwatson> I tend to use http://paste.ubuntu.com/24290050/ as a workaround
<slangasek> other workaround: https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive
<cjwatson> hey, lp-subscribed-bugs times out too, sigh.  not going to go delve into lib/lp/bugs/ right now because I like my sanity
<cyphermox> slangasek: there was a relevant tasksel issue with server before not including "standard"
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-87-gd23543eb-0ubuntu1 => 0.7.9-89-gbf7723e8-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
#ubuntu-release 2017-04-01
<slangasek> ginggs: it's very hard to type 'bedtools' instead of 'debtools'
<handsome_feng> Hi, Could someone ack ubuntukylin-theme from the upload queue? Thank you!
<handsome_feng> Could someone ack ubuntukylin-theme and ubuntukylin-wallpapers from the upload queue? Thank you!
<slangasek> infinity: right, so your approach to the demotions has broken kubuntu builds instead ;)
<slangasek> because it can only be applied when doing a minimal bootstrap
<slangasek> infinity: it's really just that you missed the guard for LB_BOOTSTRAP_FLAVOUR==minimal
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.3 => 3.0~a57-1ubuntu25.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.4]
<ginggs> slangasek: thanks for the removals!
-queuebot:#ubuntu-release- Unapproved: acedb (zesty-proposed/universe) [4.9.39+dfsg.02-1 => 4.9.39+dfsg.02-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted acedb [source] (zesty-proposed) [4.9.39+dfsg.02-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (zesty-proposed) [17.04.0]
-queuebot:#ubuntu-release- Unapproved: ngs-sdk (zesty-proposed/universe) [1.3.0-1ubuntu1 => 1.3.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ngs-sdk [source] (zesty-proposed) [1.3.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: suricata (zesty-proposed/universe) [3.2-2build1 => 3.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted suricata [source] (zesty-proposed) [3.2-2ubuntu1]
<handsome_feng> Hi, Could someone help to approve the ubuntukylin-theme in upload queue? Thanks.
<apw> handsome_feng, i am not sure i am qualified to review that, but i do notice it has two deps dropped which are not documented in the changelog
<apw> (deps or similar)
<handsome_feng> apw, thanks, I will check that soon.
<handsome_feng> apw, yes, we will update the changelog, should we drop a new release?
<apw> you can reuse that same version
<handsome_feng> ok, Thanks a lot!
<ginggs> apw: would you please take a look LP: #1671429 ?
<ubot5> Launchpad bug 1671429 in phyml (Ubuntu) "Please remove ppc64el and s390x binaries" [Undecided,New] https://launchpad.net/bugs/1671429
-queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-theme [source] (zesty-proposed) [1.7.0]
<handsome_feng> Hi, Could someone help to reupload the ubuntukylin-theme? bug: #1677157
<ubot5> bug 1677157 in ubuntukylin-theme (Ubuntu) "[FFe] Update ubuntukylin-theme to 1.7.0" [Undecided,Confirmed] https://launchpad.net/bugs/1677157
-queuebot:#ubuntu-release- Unapproved: ncbi-vdb (zesty-proposed/universe) [2.8.1+dfsg-1 => 2.8.1+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ncbi-vdb [source] (zesty-proposed) [2.8.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: sra-sdk (zesty-proposed/universe) [2.8.1-2+dfsg-1 => 2.8.1-2+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sra-sdk [source] (zesty-proposed) [2.8.1-2+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (zesty-proposed/universe) [17.04.9 => 17.04.10] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: castle-game-engine (zesty-proposed/universe) [5.2.0-3 => 6.0.2+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted castle-game-engine [sync] (zesty-proposed) [6.0.2+dfsg1-2]
<fossfreedom> jbicha: would you be happy to accept this patch to gnome-tweak-tool? https://bugs.launchpad.net/ubuntubudgie/+bug/1678420
<ubot5> Ubuntu bug 1678420 in gnome-tweak-tool (Ubuntu) "gnome-tweak-tool cannot start on ubuntu budgie 17.04" [Undecided,In progress]
-queuebot:#ubuntu-release- Unapproved: scythe (zesty-proposed/universe) [0.994-3 => 0.994-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted scythe [sync] (zesty-proposed) [0.994-4]
-queuebot:#ubuntu-release- Unapproved: autodocktools (zesty-proposed/multiverse) [1.5.7-1 => 1.5.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted autodocktools [sync] (zesty-proposed) [1.5.7-2]
<handsome_feng> Hi, Could someone there can help to check the update request: bug: #1677157 Thank you!
<ubot5> bug 1677157 in ubuntukylin-theme (Ubuntu) "[FFe] Update ubuntukylin-theme to 1.7.0" [Undecided,Confirmed] https://launchpad.net/bugs/1677157
<jbicha> handsome_feng: please subscribe ubuntu-sponsors to bugs where you need someone to sponsor the upload into Ubuntu, https://wiki.ubuntu.com/SponsorshipProcess
<handsome_feng> jbicha, oh, get it, Thank you!
<jbicha> handsome_feng: when are you going to upload ubuntukylin-meta?
<handsome_feng> I have update the seeds, didn't it enough?
<jbicha> no
<handsome_feng> Sorry, but I have no idea about this? How can I upload the ubuntukylin-meta?
<jbicha> you have to update the seed (which you did), then run ./update in the ubuntukylin-meta source package
<jbicha> updating the seed will probably update the .iso, but it won't be enough for people who upgraded to get the new packages
<handsome_feng> And then file a FFe bug for the ubuntukylin-meta package? or something else?
<jbicha> I don't think you need a FFe now; I believe the Release Team is ok with UKUI
<jbicha> but subscribe ubuntu-sponsors! :)
<jbicha> handsome_feng: are you subscribed to the ubuntu-release list? I'm asking because of https://lists.ubuntu.com/archives/ubuntu-release/2017-March/004070.html
<jbicha> you might want to install that package by default
<handsome_feng> not yet...
<handsome_feng> jbicha, So I need add the exfat-utils in seeds?
<jbicha> yes, if Kylin wants it installed
<jbicha> but let's just do the ubuntukylin-meta update first, because I have upload rights for that but not to change your seed
<handsome_feng> Ok, I will do that tomorrow morning, since there will be out of network soon. :)
-queuebot:#ubuntu-release- Unapproved: view3dscene (zesty-proposed/universe) [3.15.0-6 => 3.16.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted view3dscene [sync] (zesty-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-tweak-tool (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (zesty-proposed/universe) [1.6.2 => 1.7.0] (ubuntukylin)
<infinity> slangasek: Oh, erk, because minimal is in the debootstrap set.  Duh.  It could be guarded, or it could also remove minimal (which will just get readded later).
<infinity> slangasek: But the guard makes more sense.
-queuebot:#ubuntu-release- Unapproved: pd-aubio (zesty-proposed/universe) [0.4-1 => 0.4-1build1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: gnome-autoar (zesty-proposed/universe) [0.1.1-4 => 0.2.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted pd-aubio [source] (zesty-proposed) [0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (zesty-proposed/universe) [0.5-1 => 0.6-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-autoar (zesty-proposed/universe) [0.1.1-4 => 0.2.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: sloccount (zesty-proposed/universe) [2.26-5.1 => 2.26-5.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sloccount [sync] (zesty-proposed) [2.26-5.2]
#ubuntu-release 2017-04-02
-queuebot:#ubuntu-release- Unapproved: gnome-recipes (zesty-proposed/universe) [1.0.0-0ubuntu2 => 1.0.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-recipes [source] (zesty-proposed) [1.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: arc-theme (zesty-proposed/universe) [20161119-1 => 20170302-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ncbi-vdb (zesty-proposed/universe) [2.8.1+dfsg-1ubuntu1 => 2.8.1+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ncbi-vdb [sync] (zesty-proposed) [2.8.1+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: ngs-sdk (zesty-proposed/universe) [1.3.0-1ubuntu2 => 1.3.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ngs-sdk [sync] (zesty-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- Unapproved: freevial (zesty-proposed/universe) [1.3-2 => 1.3-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freevial [source] (zesty-proposed) [1.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gpsshogi (zesty-proposed/universe) [0.7.0-1 => 0.7.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gpsshogi [sync] (zesty-proposed) [0.7.0-1.1]
-queuebot:#ubuntu-release- Unapproved: sra-sdk (zesty-proposed/universe) [2.8.1-2+dfsg-1ubuntu1 => 2.8.1-2+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sra-sdk [sync] (zesty-proposed) [2.8.1-2+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (zesty-proposed/universe) [0.19 => 0.20] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (zesty-proposed/universe) [17.04.1 => 17.04.2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: unity-control-center (zesty-proposed/main) [15.04.0+17.04.20170314-0ubuntu2 => 15.04.0+17.04.20170402.6-0ubuntu1] (ubuntu-desktop) (sync)
#ubuntu-release 2018-03-26
-queuebot:#ubuntu-release- New sync: tldextract (bionic-proposed/primary) [2.2.0-1]
<tsimonq2> slangasek: Thanks!
-queuebot:#ubuntu-release- New binary: kproperty [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kproperty [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kproperty [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kproperty [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kproperty [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kproperty [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdb [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
<slangasek> ginggs: I'm not sure precisely what changed or why we're getting different behavior on Ubuntu than on Debian, but we did recently update the autopkgtest branch on the infra to a more recent version
-queuebot:#ubuntu-release- New: accepted kdb [amd64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kdb [armhf] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kdb [ppc64el] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [amd64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [armhf] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [ppc64el] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kdb [arm64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kdb [s390x] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [i386] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kdb [i386] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [s390x] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kproperty [arm64] (bionic-proposed) [3.1.0-2]
<slangasek> tsimonq2: I suspect the wrong use of -proposed might be a regression in autopkgtest upstream not setting the correct pins
<slangasek> tsimonq2: or our branch of it, whichever is currently deployed; checking now
<tsimonq2> slangasek: ack, lmk
<slangasek> yeah, I think the upstream fix for the APT::Default-Release problem does not DTRT
<slangasek> juliank: 'Pin: release bionic'... does that only match bionic release pocket?
<slangasek> yeah, this pin is too broad
<slangasek> Laney, elbrus: ^^ the 'release foo' pin also matches foo-proposed in Ubuntu, which means we've incorrectly been doing the equivalent of --all-proposed for all tests... patching in another temporary workaround
<fossfreedom> hi - I'm a bit lost (actually very) why "postfix" mail server is being pulled into our Ubuntu Budgie iso - can someone help decipher this please (assuming I'm looking at the right area) http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.bionic/all
<slangasek> fossfreedom: usually makes sense to look at those specific seeds that are part of the image, rather than 'all'
<fossfreedom> k - is that the "desktop.seed" ?
<slangasek> fossfreedom: so if I look at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.bionic/desktop I find it being pulled in by liblockfile1 -> bsd-mailx -> default-mta
<slangasek> this seems to be a change in liblockfile1 which previously did not depend on bsd-mailx
<slangasek> and should probably be fixed to again not do so
<slangasek> that seems to be an unexpected side effect of a Debian NMU
<slangasek> oh no, sorry, I was reading that the wrong way around
<slangasek> bsd-mailx depends liblockfile1, liblockfile1 doesn't depend bsd-mailx :P
<slangasek> so it's smartmontools -> bsd-mailx -> postfix
<slangasek> fossfreedom: so, why do you install smartmontools?  No other desktop flavor does
<fossfreedom> we do?
<slangasek> apparently it's tlp -> smartmontools
<fossfreedom> ah - tlp is something we have always pulled in
<fossfreedom> but I dont ever remember postfix being pulled in as well...
<slangasek> so I guess you'd perhaps like tlp to not pull in smartmontools
<slangasek> fossfreedom: well, it was the case already in artful
<fossfreedom> hmm - wonder why mailx is a recommends on smartmontools - seems like an odd recommeds
<slangasek> because it wants to deliver reporting via email
<acheronuk> slangasek: seems someone synced kproperty and kdb 3.1, but not the other build dep kreport for kexi 3.1, or kexi 3.1 itself. so those new versions won't get out of proposed. kexi suite is leaf stuff for kde, so could we have permission to complete syncing those packages, assuming the original sync'r (jbicha) is not intending to or does not have a FFe in place?
<fossfreedom> slangasek, ah - ok.  Thenn yes, I guess tlp shouldnt have that recommendation ... but looking back even xenial had it as well.
<slangasek> acheronuk: that sounds ok, provided you do due diligence on what's being pulled in that it's not going to have further knock-on effects
<slangasek> acheronuk: (which it sounds like you may have already done)
<acheronuk> slangasek: yeah. I will check it fully again before I push any buttons. thanks
<infinity> To be clear, nothing "changed".  tlp and postfix were both in ubuntu-budgie-desktop in artful.
<infinity> It's just that someone finally noticed.
<infinity> slangasek, acheronuk, fossfreedom ^
<infinity> (artful-amd64)root@nosferatu:/home/adconrad# apt-cache show postfix | grep ^Task
<infinity> Task: mail-server, ubuntu-budgie-desktop
<infinity> Oh, maybe acheronuk wasn't involved in that discussion.  Well, the other two were. :P
 * acheronuk was not
<slangasek> jbicha: gnucash FFe> since I use the package I was going to kick the tires on it before acking, and it FTBFS from me locally.  Does it work for you?
<fossfreedom> infinity, would you be ok if I made a debdiff to downgrade smartmontools from recommends to suggests for TLP to resolve the postfix inclusion?
<juliank> slangasek: oh they all have Codename: bionic. Yeah they match all of them, then.
<slangasek> juliank: any further thoughts on a pin that might DTRT everywhere?  Or should we just detect Ubuntu?
<juliank> I don't think there is any pin that works everywhere
<juliank> Basically we want to pin bionic, bionic-updates, and bionic-security, right? (which only really becomes important once it's a stable release)
<infinity> slangasek, juliank: What are we trying to pin?
<infinity> "Pin: release a=<suite>" gets you just suites.
<infinity> If you're after telling bionic, bionic-updates, etc apart.
<infinity> We use that in buildds chroots to force backports from NoInstallAuto back to normal.
<infinity> Package: *
<infinity> Pin: release a=*-backports
<infinity> Pin-Priority: 500
<infinity> (PS: it also takes wildcards, which proved handy for lazy me)
<juliank> Its about autopkgtests
<infinity> juliank: I figured that, I couldn't find context to decide what the desired outcome was, that's all.
<apw> so about trying to pin a!=*-proposed ?
<infinity> juliank: But "they're all bionic" is solved by "use a="
<infinity> apw: That's not how pins work. :)
<infinity> But if you don't want proposed, you can pin it negative.
<juliank> i think we want to pin release bionic to 990, and override bionic-proposed
<apw> infinity, i am sure not :)  i was trying to find out what he wants :)
<juliank> So when testing for stable we test against updates?
<infinity> juliank: Testing proposed tests against release+updates.
<infinity> juliank: If we ever got around to testing security, it would be release+security
<infinity> juliank: And there's no reason this logic needs to differ between stable and devel, since devel always has those pockets (but they're empty).
<juliank> Yeah
<infinity> And in the rare cases where those pockets aren't empty in devel (like when I do weird things during release week), testing in the "stable way" would be correct anyway.
<infinity> I'm confused how this came up, though.  I thought pitti and I sorted all the pinning stuff eons ago.
<infinity> Unless someone broke it.
<juliank> infinity: Debian set apt::Default-Release config option recently
<infinity> Note that it pins in such a way as to not *exclude* proposed, in case deps need to get pulled in.
<infinity> juliank: Right, that's not going to work for us, cause we use partial suites, not releases.
<infinity> But the way we've been doing it for the last couple of years works, no?
<juliank> I'd think so
<infinity> https://salsa.debian.org/ci-team/autopkgtest/commit/7130136a49a2c055d19782f84dba6ea2b27c7006
<infinity> I see a fine mix of "release fluffy" and "release a=fluffy.."
<infinity> Make them all a=, and it's probably happy.
<infinity> Though, that's just looking at a commit, not the existing code.
<infinity> Ahh, but here's where the working logic was torn out:
<infinity> https://salsa.debian.org/ci-team/autopkgtest/commit/8ef72c014cf29c1fe3fb72e1ac8c09aa16dadf65
<infinity> So making the new code match behaviour should be easy enough.
<infinity> juliank: I'm supposedly not here, so I'll go away now, but if you need eyeballs, poke me.
<infinity> juliank: Making the new function produce an identical (except for exact numbers, I guess) output to the original should be both easy and testable, though.
<infinity> It's pretty clear that Paul just didn't really grok how we use this.
<infinity> (or maybe how Ubuntu suites work)
<doko> apw: could you have a look at linux-gcp? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/l/linux-gcp/20180326_074742_bb201@/log.gz
<tsimonq2> infinity, slangasek: I'm Not Here but could I please get node-define-property demoted to bionic-proposed? Debian bug 892656,
<ubot5> Debian bug 892656 in src:node-define-property "node-define-property: FTBFS and Debci failure" [Serious,Open] http://bugs.debian.org/892656
<tsimonq2> https://launchpad.net/~tsimonq2/+archive/ubuntu/upload-testing/+sourcepub/8878227/+listing-archive-extra : it's FTBFS no-change rebuilding against only packages in release, and its failing autopkgtests are blocking nodejs' migration.
<tsimonq2> Nevermind.
<tsimonq2> Not yet.
<apw> doko, damn debhelper and it checking things are correct
 * tsimonq2 botched the whole "test it's FTBFS in release" by not remembering that I copy-package'd nodejs from proposed to do other testing...
<doko> apw: feel free to override it so gdb can migrate
<apw> doko, i am slighly confused how on earth it ever actaully built, given it no longer does, but hey
<apw> doko, oh, i see, britney is testing it on arches it doesn't build on, nice
<apw> doko, sorted
<LocutusOfBorg> hello, please remove this *source* package
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/msgpack-python
<LocutusOfBorg> it has been superseeded by python-msgpack, providing the same binaries, but different source package name
<apw> LocutusOfBorg, looking
<LocutusOfBorg> thanks! I don't know how much it is worth the effort, but having a clean archive is nice :)
<apw> always worth the effort
<LocutusOfBorg> nice :)
<LocutusOfBorg> I requested on #debian-devel the same for debian
<ginggs> apw: src:libthrust can be removed for a similar reason, debian bug #892808
<ubot5> Debian bug 892808 in src:libthrust "src:libthrust: cuda toolkit ships a newer version" [Serious,Open] http://bugs.debian.org/892808
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20180307-0ubuntu1]
<LocutusOfBorg> hello doko, did you find the gcc-8 issue? (static libraries without fPIC), preventing meson from building
<LocutusOfBorg> I can confirm, fPIC is not there libtool: compile:  /<<PKGBUILDDIR>>/build/./gcc/gdc -B/<<PKGBUILDDIR>>/build/./gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -isystem /<<PKGBUILDDIR>>/build/sys-include -O2 -g -nostdinc -pipe -Wno-deprecated -I ../../../../src/libphobos/libdruntime -I . -c ../../../../src/libphobos/libdruntime/rt
<LocutusOfBorg> /sections_elf_shared.d -o rt/sections_elf_shared.o >/dev/null 2>&1
<LocutusOfBorg> btw, I don't understand why files for static library are put in rt/foo.o and the same files are rebuilt for the dynamic version, in .libs/foo.o
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.10-0ubuntu1]
<LocutusOfBorg> apw, maybe I didn't wait long enough, but you deleted the old msgpack-python from universe and not from main? https://launchpad.net/ubuntu/+source/msgpack-python/+publishinghistory
<LocutusOfBorg> apw, maybe I didn't wait long enough, but you deleted the old msgpack-python from universe and not from main? https://launchpad.net/ubuntu/+source/msgpack-python/+publishinghistory
-queuebot:#ubuntu-release- New: accepted tldextract [sync] (bionic-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New binary: tldextract [amd64] (bionic-proposed/none) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tldextract [amd64] (bionic-proposed) [2.2.0-1]
<Laney> juliank: are you looking into that autopkgtest bug?
<juliank> Laney: No, I'm doing other stuff, but I can advise on apt parts
<Laney> ok :/
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (xenial-proposed) [2.8.0-1ubuntu1~16.04.5]
<Laney> might want to wait until e_lbrus is back then, he mentioned in here that he was away this week
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [sync] (trusty-release) [176.0.0-0ubuntu1~14.04.0]
<Laney> I'll file it, looks like nobody else did
<ginggs> Laney: where can I see the source for the "live" autopkgtest? I want to check if we got https://salsa.debian.org/ci-team/autopkgtest/commit/702c31af9e65e71f837703e9a651acfbd62ad471
<Laney> ginggs: You can see the commit at the top of any log.gz.
<xnox> LocutusOfBorg, ruby-defaults.... it's literarly just an update to the Vcs URL =/
<xnox> LocutusOfBorg, just think about all the CO2 emissions that running all the autopkgtests is causing to boil the planet
<ginggs> Laney: ok, i see "git checkout: 7130136 Use apt pinning instead of APT::Default-Release" but from which repo is that?
<xnox> LocutusOfBorg, 1,000+ of VMs are spinned up, because of an URL update =(
<Laney> ginggs: That commit is upstream, but the repository in use is https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development/+ref/master .
<ginggs> Laney: thanks!
<ginggs> something broke a bunch of node autopkgtests recently; node-mapnik, node-ansi, node-archy
<LocutusOfBorg> xnox, queues were empty, and my debcheckout is happier, moreover autosync will happen again...
<LocutusOfBorg> I know and understand your point, I was really worried when pressing yes :(
<xnox> LocutusOfBorg, seriously, we are post featurefreeze, and the update to url does not warrant that sync at all. please do not sync any changes, which are metadata only of urls / standards version, things that do not affect binary packges what's so ever.
<xnox> LocutusOfBorg, it can wait 6 weeks, until we open the flood gates again.
-queuebot:#ubuntu-release- New binary: kreport [s390x] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kreport [ppc64el] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kreport [amd64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kreport [i386] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kreport [arm64] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: kreport [armhf] (bionic-proposed/universe) [3.1.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: lexicon [amd64] (bionic-proposed/universe) [2.1.21-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (xenial-proposed/main) [14.04+16.04.20171116-0ubuntu1 => 14.04+16.04.20180326-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<Laney> ginggs: Stop doing the weird quoting stuff in d/tests/control, it's not needed in recent autopkgtest (5.2)
<Laney> and once https://salsa.debian.org/ci-team/autodep8/merge_requests/2/diffs is fixed, you can drop that kind of test altogether and use the generated one
<ahasenack> Laney: hi, good morning/afternoon, did you get anything interesting out of those gvfs ppc64el autopkgtest runs from last week?
<ginggs> Laney: sounds good - last week e.lbrus asked me about sync-ing autokpgtest 5.2 from debian, but I only saw the message yesterday
<Laney> ginggs: doesn't really matter for autopkgtest.u.c, we use it from git there
<ginggs> Laney: understood, but for the package in the archive?
<Laney> sorry, don't understand the question
<Laney> I don't mind if you want to sync if it's that
<ginggs> Laney: that was it
-queuebot:#ubuntu-release- New: accepted kreport [amd64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kreport [armhf] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kreport [ppc64el] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted lexicon [amd64] (bionic-proposed) [2.1.21-1]
-queuebot:#ubuntu-release- New: accepted kreport [arm64] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kreport [s390x] (bionic-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted kreport [i386] (bionic-proposed) [3.1.0-2]
<smoser> hi, could  someone take a look at my grub-legacy-ec2 upload (new queue) . it is stripped out of cloud-init source into its own package. see bug 1758420
<ubot5> bug 1758420 in cloud-init (Ubuntu) "separate grub-legacy-ec2 from cloud-init" [Medium,In progress] https://launchpad.net/bugs/1758420
<juliank> "adequate" autopkgtest is broken (I retriggered that with hello, and it failed same way; probably some ldd change)
<apw> smoser, is there any reason we cannot just call this 20 or something to avoid an epoch for the rest of time ?
<smoser> slangasek suggested the epoch.
<apw> smoser, ok, then i guess it is ok, /me hates them
<apw> smoser, what are we gaining by splitting this out ?
<smoser> smoser>      you have a suggestion for a version?
<smoser> slangasek>   smoser: 1:1+mariadb10.1
<smoser>  * slangasek amuses himself far too much with his own joke
<smoser> slangasek>   smoser: I think an epoch is genuinely reasonable here
<smoser> apw: its described in the bug some. it has basically no relation to cloud-init.
 * rbasak 's ears perk up
<rbasak> mariadb?
<rbasak> Oh.
<rbasak> :)
<apw> smoser, and as it is included in the said cloud-init, presumably this needs some breaks action
<smoser> apw: well it owuldnt htough, would it?
<smoser> it was a binary package built by cloud-init source
<smoser> and now its a binary package built by its own source
 * apw has a sense of dejavue, i think i say this every time
<smoser> so it definitely does conflict with itself
<apw> so as long as cloud-init doesn't ever upload it again you are ok
<smoser> and with the binary package produced from cloud-init source
<smoser> the same is true though for cloud-init deciding to have a package named 'grep' , right ?
<smoser> and grep doesnt have a breaks on cloud-init.
<apw> it is ok because this entire package it taken over
<smoser> right.
<apw> well if you added a package to cloud-init called grep i suspect i'd get to reject it
<smoser> that would be fun. :)
<apw> and this is only directly seeded right ?
<smoser> but the same process that stops me from doing that for 'grep' will subsequently stop me from doing it for 'grub-legacy-ec2'
<smoser> yes.
<smoser> one other quote from slangasek:
<apw> right, your cloud-init would fail to upload at the binary stage i guess, so you get to lose
<smoser> slangasek   smoser: ordering> new grub-legacy-ec2 source should be uploaded, accepted, and migrate to release pocket before being dropped from cloud-init source (because an unsatisfiable recommends will not stop proposed-migration from updating a package)
<apw> ack
<smoser> apw: thank you for your help.
<LocutusOfBorg> apw, I'm not sure you really fixed msgpack :p
<LocutusOfBorg> now I see the new package both in proposed and release at the same time...
<LocutusOfBorg>  python-msgpack | 0.5.4-0ubuntu2 | bionic          | source, amd64, arm64, armhf, i386, ppc64el, s390x
<LocutusOfBorg>  python-msgpack | 0.5.4-0ubuntu2 | bionic-proposed | source
<LocutusOfBorg>  msgpack-python | 0.5.4-0ubuntu1 | bionic           | source
<apw> LocutusOfBorg, indeed, and yet here is the command in my history
<apw> maybe i forgot to say yes or something dump
<LocutusOfBorg> I see msgpack-python removed from universe, not from main... maybe this is the reason?
<apw> i did change overrides on python-msgpack at the same time, but they shouldn't overlap as that command is versioned
<apw> anyhow, i've applied the axe to its neck again, lets see what falls out
<LocutusOfBorg> the msgpack-python is now gone
<LocutusOfBorg> I'm tempted to no-change rebuild python-msgpack to make britney happy if it doesn't autoheal in the next hour or so, what do you think?
<apw> britney is likely to auto-heal
<apw> but why is it unhappy in the first placce
<LocutusOfBorg> I honestly don't think it will auto-heal, because removing the old package should have no effect on the new one...
<apw> LocutusOfBorg, i don't see it even in britney's view ... it is already in -release
<LocutusOfBorg> rmadison and web has a different pov
<LocutusOfBorg> 	proposed, release (main)	5 hours ago
<apw> its not cleared from -proposed completly indeed, but it is promoted
<LocutusOfBorg> it is at the same time on both places, this is why I don't think britney will change the situation
<apw> yeah likely britney was moving it just as i changed its overrides, or something
<apw> it is however fully promoted, there is just some archive sadness
<apw> which can be repaired whenever
<apw>  python-msgpack | 0.5.4-0ubuntu2 | bionic          | source, amd64, arm64, armhf, i386, ppc64el, s390x
<apw> LocutusOfBorg, you see that at least right?  so everything is out in -release
<LocutusOfBorg> yes
<LocutusOfBorg> just the source is around in proposed
<cjwatson> a no-change rebuild is a silly solution to that :)
<apw> and that would have been the only thing which was being overrideen, so classic overrides racy fun
<LocutusOfBorg> I think I got it, when you promote, did you promote the stuff in proposed?
<apw> i see no reason i cannot just remove the source from -proposed and be happy
<cjwatson> https://launchpad.net/ubuntu/+source/python-msgpack/+publishinghistory gives a much clearer view than the main DSP page
<cjwatson> apw: you can
<LocutusOfBorg> yes cjwatson this is what I proposed above, unless there is a bug somewhere
<cjwatson> LocutusOfBorg: I'm saying it's a silly solution *so don't do it* :P
<apw> cjwatson, and i am sure it was my change-overrides to promte the source which triggered it to remain
<cjwatson> apw: I doubt it.  There are some races
<apw> it was about the right time, but hey, anyhow, removing
<LocutusOfBorg> also abusing time of AAs might be a silly idea :)
<cjwatson> removals aren't an abuse of time
<apw> meh, archive scrubbing is a thing, a thing we do, its like floors when you own a dog
<LocutusOfBorg> nice, now the situation is happy again thanks!
<LocutusOfBorg> doko, my wild, quick, and dirty gcc patch, fixed meson build
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg> -+GDCFLAGS_FOR_TARGET = -O2 -g
<LocutusOfBorg> ++GDCFLAGS_FOR_TARGET = -O2 -g -fPIC
<LocutusOfBorg> so, really please add fPIC when building shared libraries, in a more sane than my patch hacking
<cjwatson> it's not even clear to me what happened here, which is moderately impressive
<LocutusOfBorg> wow, 4 years of hard tries, and at the end I found something challenging even for you :D I'm happy and sad at the same time!
<cjwatson> heh
<cjwatson> I agree the timings are consistent with change-override, just don't see how
<cjwatson> I guess maybe msgpack-python still being around had some effect on what would ordinarily have been an error case
<LocutusOfBorg> cjwatson, can the fact that binaries were "owned" by another source package be somewhat a cause?
<cjwatson> I wouldn't have thought that would have an effect on the *source* still being published in -proposed, but it seems like the only plausible explanation
<cjwatson> and yeah, if you manage to get into SPPH.changeOverride then it just does an IPublishingSet.newSourcePublication
<cjwatson> oh well
<apw> oh lovely :)
<xnox> slangasek, re:dropping dh_python dependency https://lintian.debian.org/tags/missing-build-dependency-for-dh_-command.html
<xnox> also posted by p1otr
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (xenial-proposed) [14.04+16.04.20180326-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted grub-legacy-ec2 [source] (bionic-proposed) [1:1]
-queuebot:#ubuntu-release- New sync: python-gitlab (bionic-proposed/primary) [1:1.3.0-1]
<cascardo> doko: gcc-7-cross now fails to build the kernel on bionic/arm64
<cascardo> http://kernel.ubuntu.com/~kernel-ppa/test-build/bionic/linux/LP%231754584--bc0adba16e0600a898435fa22c803f15e3caa866/arm64.log
<cascardo> /usr/lib/gcc-cross/aarch64-linux-gnu/7/include/arm_neon.h:31605:10: error: incompatible types when returning type 'int' but 'uint32x4_t' was
<cascardo>  expected
<slangasek> xnox: aha, thanks for the corrected lintian tag
<Odd_Bloke> slangasek: I've verified https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1757223; would you mind migrating livecd-rootfs in xenial?
<ubot5> Ubuntu bug 1757223 in livecd-rootfs (Ubuntu Xenial) "ubuntu-cpc: Don't build minimized artifacts that won't boot with linux-kvm" [Undecided,Fix committed]
<slangasek> Odd_Bloke: done
<Odd_Bloke> Thanks!
<tsimonq2> slangasek: peruse> I'll probably ship libacbf.so in its own binary as a library instead of making it private.
<slangasek> Laney: as an aside, I believe it's a mistake that we don't provide a continuous "devel" track of everything cloud+autopkgtest; the discontinuity at release time is a major source of hassle for archive opening.  And if we start using 'devel' instead of 'bionic' in the sources, well...
<slangasek> tsimonq2: is that supported by upstream?  libacbf.so doesn't have a proper SONAME
<slangasek> tsimonq2: so I don't think it's really intended to be public?
<tsimonq2> slangasek: Hm. I might reconsider that then.
<tsimonq2> To be fair, I've asked several people and have gotten different answers.
<slangasek> oh?
<tsimonq2> So far, the three solutions I've heard are to carve it out, to make it private, or to ship it publicly.
<slangasek> I'm wondering if the multiple answers you've gotten have come from Ubuntu uploaders, and if so what their rationale was
<tsimonq2> All are core developers
<tsimonq2> slangasek: I might try to figure out rpath with the arch-specific library directories (...) to ship it privately.
<tsimonq2> But as I said before, this is new territory for me, so I'd like a review from someone when I get a candidate solution.
<infinity> tsimonq2: Why would you need that?
<infinity> tsimonq2: The package isn't multi-arch:same and, indeed, if it were a good candidate for such, it probably wouldn't need this talk about why it shouldn't be a public library.  Thus, it also doesn't need to use multiarch directories.
<tsimonq2> infinity: OK; I'm not entirely clear on what that entails.
-queuebot:#ubuntu-release- Unapproved: update-manager (artful-proposed/main) [1:17.10.13 => 1:17.10.14] (core)
<tsimonq2> infinity: What sort of thing would you do if you were in this situation with a package you maintain?
<infinity> tsimonq2: Short term, mangle the build to link it statically, or ship it in a private location, long term, engage upstream to either do the former or stabilise an API/ABI and make it a proper public library with an SONAME.
<tsimonq2> infinity: Linking it statically would be OK?
<tsimonq2> I mean, if it works.
<infinity> tsimonq2: To that one non-library, sure.  Why wouldn't it be?
<tsimonq2> *insert mantra about dynamically linking everything here*
<tsimonq2> So, I don't know. :)
<tsimonq2> Anyway, thanks.
<infinity> tsimonq2: Dynamically linking to your *external* deps, sure.  THis isn't an external dep.
<infinity> tsimonq2: Literally everything that isn't a single C file is statically linked. :P
<tsimonq2> infinity: TIL.
 * tsimonq2 tries to find something to RTFM on so I can handle this better next time.
<Laney> slangasek: uh, ok, that feels like it came a bit out of nowhere, but if you want to map out the work, be my guest
<slangasek> Laney: it's nothing urgent or high priority, it's just timely to mention because we're filing bugs about trying to fix autopkgtest's handling of pins and it might be better to be forward-looking
-queuebot:#ubuntu-release- New binary: atril [ppc64el] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: atril [armhf] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
<tsimonq2> Laney: Speaking of autopkgtests, I plan on finishing the duplicate queue stuff tomorrow night.
<tsimonq2> I mean, if my code looks sane, you're welcome to cherry-pick the two commits I have done so far, because standalone that does fix part of the problem.
<tsimonq2> It just doesn't look at the queue quite yet.
-queuebot:#ubuntu-release- New binary: libnatpmp [i386] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libnatpmp [s390x] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libnatpmp [amd64] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: atril [s390x] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: libnatpmp [armhf] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libnatpmp [ppc64el] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: atril [amd64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: libnatpmp [arm64] (bionic-proposed/main) [20150609-2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: atril [i386] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: atril [arm64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [ppc64el] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [s390x] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [amd64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [i386] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [armhf] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- New binary: mate-desktop [arm64] (bionic-proposed/universe) [1.20.1-0ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
<xnox> doko, infinity - do you have history as to why we need a delta to have a python-subversion-dbg package? it seems to fail on arm64/s390x and blocking ruby2.3 removal =/ it ends up with
<xnox> <xnox> arm64: Test inherited props ... Fatal Python error: subversion/bindings/swig/python/svn_client.c:24101 object at 0xffff773dec18 has negative ref count -2604246222170760230
<xnox> <xnox> s390x: Test inherited props ... Fatal Python error: subversion/bindings/swig/python/svn_client.c:24101 object at 0x3ffa7140528 has negative ref count -2604246222170760230
<xnox> retried, to see if it works now.... but otherwise, i'd be inclined to either drop python-subversion-dbg alltogether, or at least on those two arches, to get subversion to migrate with ruby2.5 bindings, remove ruby2.3 from release, re-introduce the delta to build python-subversion-dbg on all arches to sort it out later.
<xnox> does above smell like a python and/or swig bug?
<slangasek> xnox: python-subversion-dbg has been a delta since 2007; I don't think that's an interesting thing for us to continue to carry today
<slangasek> if killing that delta unblocks, I think we should
<tsimonq2> slangasek (cc jbicha): I'd be curious to get your opinion on bug 1758702 from both an AA standpoint (irt the blacklist, dunno if that's AA or Release Team but that feels like AA) and a Release Team standpoint.
<ubot5> bug 1758702 in gitlab (Ubuntu) "Please consider adding gitlab to sync blacklist" [Undecided,Confirmed] https://launchpad.net/bugs/1758702
<slangasek> tsimonq2: lp:~ubuntu-archive/+junk/sync-blacklist/ is AA, yes
<tsimonq2> slangasek: Ah ok.
<slangasek> tsimonq2: between that bug report and the removal reason in bionic, I agree that blacklist makes sense; doing
<tsimonq2> slangasek: ack, thanks
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12.3 => 234-2ubuntu12.4] (core)
<tsimonq2> slangasek: Since you had the related discussion, could I get an ACK/NACK on the debdiff attached to bug 1758798?
<ubot5> bug 1758798 in tlp (Ubuntu) "tlp recommends smartmontools which then pulls in Postfix mailserver" [Medium,In progress] https://launchpad.net/bugs/1758798
<tsimonq2> (Just covering my bases here, I guess.)
<slangasek> tsimonq2: ack
<tsimonq2> slangasek: Thanks.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (artful-proposed) [234-2ubuntu12.4]
<jbicha> slangasek: is this a valid autopkgtest control file? https://salsa.debian.org/cinnamon-team/cinnamon-desktop/blob/master/debian/tests/control
<jbicha> http://autopkgtest.ubuntu.com/packages/c/cinnamon-desktop/bionic/amd64
<slangasek> jbicha: one with no non-comment, non-blank lines?  don't know
<slangasek> I am unsurprised if it confuses things
<jbicha> my question is should we set force-badtest or should we tell Debian to just remove debian/tests/ if it's not supposed to be run?
<slangasek> jbicha: ah. I'm perfectly willing to force-badtest it, and also it seems like it should be dropped upstream
<jbicha> let's split it, you do the first part, I do the second part :)
<slangasek> (commenting out code instead of removing it, when maintained in a vcs, is an antipattern)
<jbicha> right
<slangasek> hint added
-queuebot:#ubuntu-release- New binary: deal.ii [s390x] (bionic-proposed/universe) [8.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [ppc64el] (bionic-proposed/universe) [8.5.1-1] (no packageset)
#ubuntu-release 2018-03-27
<xnox> doko, infinity - it built \o/ i guess something somewhere were fixed.
-queuebot:#ubuntu-release- New binary: deal.ii [amd64] (bionic-proposed/universe) [8.5.1-1] (no packageset)
<jbicha> slangasek: there's a typo in your cinnamon-desktop hint
<tsimonq2> ("force-badtest cinammon-desktop/3.6.2-1" should probably be "force-badtest cinnamon-desktop/3.6.2-1")
-queuebot:#ubuntu-release- New binary: deal.ii [arm64] (bionic-proposed/universe) [8.5.1-1] (no packageset)
<doko> xnox: maybe we can drop it. or keep the infrastructure and build a python3 package instead
-queuebot:#ubuntu-release- New: accepted mate-desktop [amd64] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-desktop [armhf] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-desktop [ppc64el] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-gitlab [sync] (bionic-proposed) [1:1.3.0-1]
-queuebot:#ubuntu-release- New: accepted mate-desktop [arm64] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-desktop [s390x] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-desktop [i386] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnatpmp [amd64] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted libnatpmp [armhf] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted libnatpmp [ppc64el] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted libnatpmp [arm64] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted libnatpmp [s390x] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted libnatpmp [i386] (bionic-proposed) [20150609-2]
-queuebot:#ubuntu-release- New: accepted atril [amd64] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted atril [armhf] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted atril [ppc64el] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted atril [arm64] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted atril [s390x] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted atril [i386] (bionic-proposed) [1.20.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-gitlab [amd64] (bionic-proposed/none) [1:1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-gitlab [amd64] (bionic-proposed) [1:1.3.0-1]
-queuebot:#ubuntu-release- New binary: wxpython4.0 [s390x] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [ppc64el] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [i386] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [amd64] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
<slangasek> jbicha: fixed thanks
-queuebot:#ubuntu-release- New binary: wxpython4.0 [armhf] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [arm64] (bionic-proposed/universe) [4.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bpfcc [amd64] (bionic-proposed/universe) [0.5.0-5ubuntu1] (no packageset)
<xnox> doko, it built fine =) so onto more important things, like python2.7 failing autopkgtests with openssl 1.1.1 and tls1.3
<xnox> slangasek, freeipa is a "regression" due to unable to find the source package in release pocket.... maybe it needs hinting over?
<xnox> slangasek, or did you mean for freeipa to get stuck in bionic-proposed?
<xnox> nacc, is the new nodejs likely to land? or who is working on landing it?
<xnox> ginggs, tsimonq2 - are you working on landing the new nodejs?
<xnox> slangasek, puma too -> i am not sure why they are "regressions" if they do not exist in release pocket. Unless that is correct behaviour.
<ginggs> xnox, tsimonq2: aye
<apw> xnox, taking puma as an example, it used to pass its tests and no longer does, how is that not a regression -- regardless of which pocket it is in
<apw> i assume it has been demoted to -proposed somewhen which is how we have this combination
<xnox> apw, right, in the bileto silo the autopkgtests are a lot more weird "source not found puma" i assume, since it looks into release pocket only.
<apw> xnox, that does not seem correct, if you build in a PPA for devel should you not be building against proposed still ?
<apw> else the binaries you produce are not suitable for copying to -proposed in bionic
<xnox> apw, i do build against proposed, but the autopkgtests for the bileto silo, trigger the tests right; but not the right pockets - e.g. against release pocket only.
<xnox> with openssl from the bileto ppa
<apw> which perhaps is correct, ok ... so ?
<xnox> but not adding -proposed for packages that only exist in proposed
<apw> ok so the issue is we are testing things which are not in -release only using release
<xnox> but then it claims regression =) when puma has not regressed in release pocket, because of new openssl in the PPA, since puma does not exist in the release pocket =)
<xnox> let me get the url again
<xnox> https://bileto.ubuntu.com/excuses/3217/bionic.html
<apw> so we should not be testing things not in -release, if we are testing only against release
<apw> 404
<xnox> freeipa is one of these things - W: Unable to locate package freeipa
<xnox> bah
<xnox> i was looking at a cached version, now refreshed, now i get 404 as well
<apw> quality in the making and no mistake
<xnox> apw, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3217-excuses/2018-03-27_09:15:02/3217_bionic_excuses.html
<xnox> those that are "pkg/unknown" do not exist in release but got triggered, hence i got confused.
<xnox> i guess these will not be triggered by the real britney in the real bionic-proposed -> release
<apw> so it all adds up they are regressions because they have worked, they cannot work because they don't exist
<apw> so you get a regression and sad
<apw> i would expect real britney to make the same mistake
<apw> and then they will have to be hinted, or run with a trigger to get the proposed one, or something
<seb128> hey there
<seb128> there is something weird that happened to a package migration
<seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<seb128> gnome-shell-extension-appindicator (18.04 to 18.10)
<seb128> Not touching package as requested in bug 1759180 on Tue Mar 27 09:01:36 2018
<seb128> Not considered
<ubot5> bug 1759180 in gnome-shell-extension-appindicator (Ubuntu) "[proposed] 18.10 new version is wrong, should be 18.04.1" [Undecided,New] https://launchpad.net/bugs/1759180
<seb128> but yet it seems it is migrating
<seb128> or at least according to https://launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+publishinghistory
<seb128> it has been deleted from proposed and is pending publication in bionic
<seb128> did that block didn't work / update_excuses was wrong for some reason?
<Laney> hang on
<Laney> 08:43:43.log:Copying: gnome-shell-extension-appindicator/18.10
<Laney> I think that happened before the bug was filed
<seb128> so update_excuses.html doesn't have the correct status?
<Laney> there's some published latency here and proposed-migration is looking at an out of date archive
<apw> right the bug says files 50m ago, and the britney copy is shown as more than one hour ago
<Laney> publisher*
<Laney> I think
<apw> Laney, i concur with that
<Laney> the timestamp at the top of update_excuses is quite old too
<apw> so the block didn't work because it was entirely too late, and yes the britney status is wrong now, and will sort itself when the publication completes
<apw> of course that is the last thing you want
<Laney> ah well
<Laney> appindicator users can enjoy being in the future :-)
<apw> we have a very small window now, where we could consider blowing it away
<Laney> you can kill pending publications?
<Laney> no too late
<apw> it is already published sadly
<Laney> it just changed
<Laney> but for future reference... you can?
<apw> i beleieve if it is in pending it can go to deleted yes
<apw> without being a thing that is on disk anywhere
<Laney> interesting
<apw> if we were to stop the mirrors now, we might be able to stop it going out, not sure
<apw> cjwatson, ^ you would know if we are entirely too late no
<apw> nwo
<Laney> haha
<apw> the publisher run must have just started running to flip those bits, to it isn't quite published yet
<Laney> It's not an emergency worthy of that
<Laney> but that might be interesting academically
<apw> so i think if we had reacted in that 2m window we cvould have deleted it
<apw> but i think we are committed now, barring someone getting their finger in the gears no
<apw> now
<apw> didrocks, ^ some version fun for you to deal with
<didrocks> if it's not too late, happy to reupload
<apw> i think you should assume it is too late
<didrocks> ok, so nothing to deal with in the end
<didrocks> it's just a number, due to being tired and preparing/testing this on a late train :p
<apw> well i guess you need to decide what you are going to call this going forward
<didrocks> I'll link the conversation on the bug report
<apw> so you don't have to deal with it in 18.10
<apw> perhaps 18.10.0.1 or something
<cjwatson> apw: we could copy back an older version
<apw> cjwatson, we could if we arn't worried about upgraders
<didrocks> yeah, seeing the amount of features every 6 months, it will mostly be the same code anyway
<cjwatson> apw: well, if we could stop it reaching mirrors that'd be OK.  I don't know if it's worth the effort in this case though
<didrocks> same, the worst thing is people opening bugs, but I think it's OKish
<apw> cjwatson, well the publisher is grinding on it now, so it would be a stop publisher job i think
<cjwatson> apw: I could temporarily cowboy out the sync to mirrors
<cjwatson> it's definitely *possible*
<didrocks> if you feel it's better and worth the effort, feel free and I'll reupload with correct version
<apw> i am ambivalent, it is work for you and risk ..
<apw> cjwatson, so i'd say only do it if you feel it is safe
<cjwatson> https://paste.ubuntu.com/p/fKj8XFTXHc/ is in place
<apw> cjwatson, ack thanks, i'll get that removed and the older copied back in
<apw> didrocks, feel free to upload the right version
<didrocks> thx cjwatson. apw: ping me once the old version is copied and I'll reupload the new one
<cjwatson> I'm not *absolutely* certain that some internal mirrors won't sync anyway, but I *think* the internal ones are all push
<cjwatson> note that the 18.10 version is still burned
<apw> didrocks, ^ for when you open cathartic carrot
<didrocks> yeah, we'll move directly to 18.10.0 if any upload on that package :)
<didrocks> well, someone will probably upload with .0, get a reject and bump
<didrocks> 18.04.1 uploaded
<didrocks> thx!
-queuebot:#ubuntu-release- New source: gnome-shell-extension-appindicator (bionic-proposed/primary) [18.04.1]
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-appindicator (bionic-release/primary) [18.04]
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-appindicator (bionic-release/primary) [18.04]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [sync] (bionic-release) [18.04]
-queuebot:#ubuntu-release- New: rejected gnome-shell-extension-appindicator [sync] (bionic-release) [18.04]
<_hc> hey all, I'm part of the Debian Android Tools Team.  We do a dev push before each Ubuntu LTS release, then make sure that it all gets synced properly in Ubuntu LTS, so I'm checking in now on the final details
<_hc> most of it is already included, there are just two outstanding packages, androguard and fdroidserver
<apw> Laney, for clarity, if we had reacted faster and removed it in pending state that would have been sufficient to prevent it making it out
<_hc> rbasak already got android-sdk-meta into bionic for us, the sync requests for androguard and fdroidserver are still open
<_hc> the fdroidserver update requires the androguard update, so that's the place to start 1758199
<LocutusOfBorg> no AA can process https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/1750765 ?
<ubot5> Ubuntu bug 1750765 in bpfcc (Ubuntu) "bpfcc: please remove on i386 s390x and armhf [NBS]" [Undecided,New]
<LocutusOfBorg> btw, gtk+2 gtk+3 glib2, can migrate without regressing release, you need to ignore some tests unfortunately
<LocutusOfBorg> they are all regressed in release, except for something that is regressed in proposed too
<LocutusOfBorg> (double checking is appreciated, because I can't run some tests against -release completely)
<Laney> glib2.0's tests are properly regressed
<cjwatson> publisher uncowboyed
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [source] (bionic-proposed) [18.04.1]
-queuebot:#ubuntu-release- New: accepted bpfcc [amd64] (bionic-proposed) [0.5.0-5ubuntu1]
<LocutusOfBorg> doko, I presume the gcc fix was not worth the effort since you fixed meson in another way?
<doko> you should not presume in the first place
<LocutusOfBorg> mmm so what was the reason?
<LocutusOfBorg> I would like to understand my mistake :)
<doko> look at the backlog, "working with upstream on a solutin"
<LocutusOfBorg> ack probably I did miss because of BNC
<LocutusOfBorg> I can't find it, but I'm happy if the hint was good at the end
<rbasak> _hc: I think you need to follow https://wiki.ubuntu.com/FreezeExceptionProcess on bug 1758199 and then ask the release team to look at that request.
<ubot5> bug 1758199 in androguard (Ubuntu) " Sync androguard 3.1.0rc2-1 (universe) from Debian testing (main) " [Undecided,Confirmed] https://launchpad.net/bugs/1758199
<_hc> thanks
<apw> _hc, androguard is sync'd just stuck in -proposed ?
<_hc> right now, I'm looking for feedback about whether this is a request that is likely to be reviewed.  Then I'm happy to put whatever work it needs into it.
<_hc> My experience with freeze processes is that if no one is interested, all my work won't change anything
<_hc> apw: there is an issue on s390x, other than that, its ready to go
<_hc> I dind't know until now that Ubuntu supports s390x
<_hc> I can fix that right now
<_hc> apw: oops sorry, you're right, its just stuck in -proposed.  fdroidserver is the package with the s390x issue
<apw> so i am confused what you are asking, it has already been sync'd so it doesn't need an FFE for the version that is there; if you are intending on fixing that then it ought to migrate when you do
<apw> if you are indeed asking to upload the final release of it, that needs consideration if it contains features (it may not)
<LocutusOfBorg> apw, the binary on s390x has been removed in Debian, why didn't the removal came in ubuntu too? isn't this something automatic or semi automatic?
<apw> as far as i am aware only full removals are detected
<rbasak> Oh, sorry.
<rbasak> I didn't realise it had autosynced before FF.
<apw> rbasak, don't be ... this mess is utterly confusing like spagetti
<rbasak> I reviewed the sync request assuming it was still needed, and declined on the basis that it appeared to violate FF.
<apw> _hc, if it has been removed in debian, we likely will follow suit
<LocutusOfBorg> rbasak, I closed it :p
<_hc> oh, I guess I'm confused by what -proposed is.  Will that be automatically included then?  I thought that packages had to be synced into bionic from -proposed
<_hc> I've been going on this https://packages.ubuntu.com/bionic/androguard  which shows the old version, not the version in -proposed
<_hc> its in Debian/testing: https://packages.debian.org/testing/androguard
<LocutusOfBorg> _hc, the version goes from proposed to release automatically unless problems shows up
<LocutusOfBorg> in this case, britney (the tool that does the copy from proposed to release), won't allow that, because the version in bionic release has a binary for s390x
<LocutusOfBorg> so, letting it migrate will regress that architecture
<xnox> _hc, https://launchpad.net/ubuntu/+source/androguard
<LocutusOfBorg> removing that binary from s390x will make the migration not worse wrt archive status and binaries, so it will probably land (assuming eventual autopkgtests will be happy, and the installability of reverse-deps will be ok too)
<_hc> ah, that's the blocker then.  Debian already removed the s390x binary package
<xnox> _hc, you can request removal of androguard, on s390x, from bionic-release -> file a bug report and subscribe ubuntu-archive team
<LocutusOfBorg> xnox, if the package has already been removed on debian, pinging here is usually fine too :)
<_hc> xnox: I know that page,  I'm not sure what you're pointing me to
<_hc> FYI, the s390x package never worked, we just enabled the test suite in the package, and found that out with this release
<LocutusOfBorg> _hc, this is the page you need to understand the situation http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
<_hc> ok, thanks
<_hc> ping :-)
<_hc> happy to file the bug if that's helpfuil
<xnox> _hc, on that page you can see what is published in bionic-proposed, what is published in bionic-release, and clicking on the packages, you can see for which architectures they are published, and drill into publication record from there
<xnox> _hc, packges.ubuntu.com does not show such information, and launchpad is the authoritative source of information
<LocutusOfBorg> also, rmadison helps (since you seem to be already a DD, you should have that tool)
<LocutusOfBorg> rmadison -u ubuntu androguard -s bionic,bionic-proposed
<LocutusOfBorg>  androguard | 2.0-3       | bionic/universe          | source, amd64, arm64, armhf, i386, ppc64el, s390x
<LocutusOfBorg>  androguard | 3.1.0~rc2-1 | bionic-proposed/universe | source, amd64, arm64, armhf, i386, ppc64el
<_hc> bug filed 1759261
<LocutusOfBorg> LP: #1759261
<ubot5> Launchpad bug 1759261 in androguard (Ubuntu) "request removal of androguard s390x binary package" [Undecided,New] https://launchpad.net/bugs/1759261
<LocutusOfBorg> thanks ubot5 :)
<apw> _hc thanks for the detail, already processed, bug updates
<stgraber> looks like the snapcraft autopkgtests are broken again, something to do with maven AFAICT
<stgraber> will mark it as badtest for now so it doesn't hold things
<Laney> can you file a bug please?
<stgraber> bug 1759283
<ubot5> bug 1759283 in snapcraft (Ubuntu) "snapcraft adt broken on maven test" [Undecided,New] https://launchpad.net/bugs/1759283
<Laney> ta
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.12 => 1:16.04.13] (core)
<nacc> xnox: i have no idea re: nodejs
<LocutusOfBorg> I can't understand what happened to androguard on s390x, still not disappeared, even if other removals processed at the same time did went successful
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [163-1~ubuntu17.10.1 => 164-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [164-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [163-1~ubuntu16.04.1 => 164-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [164-1~ubuntu16.04.1]
<slangasek> xnox: it's correct behavior; these packages were in releases previously, now they have failing autopkgtests, they shouldn't just be allowed back into the release
<ahasenack> hi all, I filed this FFe out of caution: all new features are not applicable for bionic, but I need them in the devel release for an upcoming xenial sru: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1759280
<ubot5> Ubuntu bug 1759280 in ubuntu-advantage-tools (Ubuntu) "[bionic] [FFe] ubuntu-advantage-tools version 17: FIPS updates" [Undecided,New]
<sergiusens> RAOF: hey can you take a look at getting LP: #1756939 into the release pocket?
<ubot5> Launchpad bug 1756939 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.40" [Undecided,Fix committed] https://launchpad.net/bugs/1756939
-queuebot:#ubuntu-release- Unapproved: plymouth (xenial-proposed/main) [0.9.2-3ubuntu13.2 => 0.9.2-3ubuntu13.3] (core)
<ahasenack> slangasek: thanks for the FFe
<slangasek> ahasenack: n/p
<slangasek> smoser: ubuntu-server is still the expected team subscriber for split-out grub-legacy-ec2, correct?
<smoser> slangasek: well, no. it should be foundations i think.
<smoser> one of the points of the excercise was to get it out of my ownership :)
<slangasek> smoser: hmm ;)
<sergiusens> slangasek: can I bug you with LP: #1756939 ? Getting snapcraft into xenial-updates and artful-updates ?
<ubot5> Launchpad bug 1756939 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.40" [Undecided,Fix committed] https://launchpad.net/bugs/1756939
<leosilva> hi there, I'm already a couple of hours waiting to my sec-update be copied to the publishers (zsh pkg update) and till now nothing. Seems it's not being copied at all. Any clue about that?
<mdeslaur> it's actually the automatic copy from -security to -updates that's not happening
<mdeslaur> cjwatson: any ideas? ^
<stgraber> hmm, is there some kind of problem with the publisher?
<stgraber> looks like it's not done much publishing in the past 6 hours or so
<nacc> stgraber: mdeslaur was just asking about that for security -> -updates as well
<leosilva> yep,
<nacc> stgraber: i wonder if it's more widespread
<cjwatson> looking, just a moment
<cjwatson> oh dear, I might have broked it
<nacc> cjwatson: thanks!
<nacc> :)
<apw> it appears to have spent a lot of time running and then dropped a trace
<cjwatson> it's a regression from my refactoring of how signing works
<cjwatson> working out what to do
<apw> oh is that one of the safeties kicking in to stop random files getting signed ?
<cjwatson> no
<cjwatson> I've reverted the tree to the previous revision (r18573) for now
<cjwatson> that should get us back in business until I have a chance to fix it properly
-queuebot:#ubuntu-release- New binary: linux-gcp [amd64] (bionic-proposed/main) [4.15.0-1002.2] (kernel)
<cjwatson> basically I was trying to extend a particular abstraction that had never been used on the primary archive before to start being so used, and I missed a detail
<tsimonq2> slangasek: Do you have objections to me uploading Qt 5.9.5 as soon as it's ready? It's binary-compatible with the Qt already in the archive and is bugfix-only but it looks like with the way the release is coming along upstream that it won't land until after Bionic's final freeze.
<tsimonq2> slangasek: (With your release team hat on, of course.)
<tsimonq2> So, it wouldn't need a Feature Freeze Exception but I don't want to surprise attack anyone. :)
<cjwatson> need to work out how to adjust the abstraction to cope
<cjwatson> (the primary archive is published into a temporary dists tree and then moved into place, which my code didn't handle)
<tsimonq2> slangasek: To give a feel on timing, upstream says "after Easter," their next meeting is on the third of April, and it takes me at minimum two days to get the transition squared away in Bileto (which is doable if there's a time crunch on it).
<tsimonq2> ("their" = the Qt release team)
<cjwatson> mdeslaur,stgraber: the publisher is working again after the temporary reversion, btw
<stgraber> thanks
<slangasek> tsimonq2: I don't think that we should take a new upstream version of Qt, even bugfix-only, post final freeze, without an explicit reason to
<tsimonq2> slangasek: ooc what's your reasoning?
<slangasek> tsimonq2: the fact that it's final freeze
<slangasek> :)
<slangasek> https://wiki.ubuntu.com/FinalFreeze
<tsimonq2> slangasek: So, what about with your SRU Team hat? :P
<tsimonq2> slangasek: It seems compatible with the SRU policy but not the Final Freeze policy then, I guess.
<slangasek> tsimonq2: I don't generally pre-approve SRUs before seeing what's actually changed
<slangasek> tsimonq2: if you want to follow the normal SRU process, then you get to create a bug report and a test case for each bugfix included from upstream
<slangasek> tsimonq2: if you want an SRU exception process, then you have to negotiate that with documentation
<tsimonq2> slangasek: ack
<tsimonq2> slangasek: https://blog.qt.io/blog/2017/05/11/introducing-long-term-support-qt-5-9/ <-- upstream says that "During the first 6 months after release day, an LTS release receives a lot of fixes, including low-priority ones. Then the LTS release enters a âstrictâ phase where only critical bugs and security issues are addressed. This will ensure the stability of the LTS releases. During the final
<tsimonq2> year of an LTS release the commit policy is âvery strictâ, at which phase we only address severe security issues."
<tsimonq2> slangasek: So, while I do plan on manually reviewing the changes, it should, in concept, be fine to go through as a regular SRU.
<tsimonq2> slangasek: If it's determined when I go through the paperwork that it isn't, then I'll apply for an exception.
<slangasek> tsimonq2: again, a regular SRU means that every single change from upstream gets a separate bug report with a regression test
<tsimonq2> slangasek: I disagree that it's a policy which has always been followed.
<tsimonq2> slangasek: Kubuntu's done updates en masse like this for years.
 * tsimonq2 finds examples
<slangasek> finding examples that didn't follow the policy doesn't mean it isn't the policy
<tsimonq2> slangasek: I believe this clause can be exercised: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<tsimonq2> Specifically: "it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs for each of them (~ubuntu-sru will make the final decision). The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug. In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one
<tsimonq2> member of the Ubuntu Technical Board."
<slangasek> yes, the operant clause is "ubuntu-sru will make the final decision"; all of which is an SRU exception
<tsimonq2> How is this an exception to the policy rather than part of the policy?
<slangasek> there are no exceptions that are not part of the policy, the policy is that the SRU team has to approve the SRU ;)
<tsimonq2> I guess I'm disagreeing with you when you said that each individual bug fixed needs its own report.
<tsimonq2> That clause states otherwise, and it's what I've known as practice in appropriate cases.
<tsimonq2> Sure, the SRU team needs to approve it, as always.
<tsimonq2> I'm just arguing against it needing it to be in many different bug reports.
<tsimonq2> slangasek: Is this incorrect?
<mdeslaur> thanks cjwatson!
<slangasek> tsimonq2: I'm saying that if you're going the microrelease process, that is an exception, not a "normal" SRU.  which is fine
<tsimonq2> slangasek: OK.
<tsimonq2> slangasek: Thanks.
<slangasek> any SRU team members around have insight to why snapd-glib is sitting in unapproved for 19 weeks?
<slangasek> that suggests something's wrong with it, but I couldn't work it out by looking at the bug
-queuebot:#ubuntu-release- New source: kubuntu-wallpapers (bionic-proposed/primary) [18.04.0]
<tsimonq2> slangasek: That source package is very small, it'd be good to get a review real quick ^^^^
-queuebot:#ubuntu-release- New binary: xapp [amd64] (bionic-proposed/universe) [1.0.4-2fakesync1] (no packageset)
#ubuntu-release 2018-03-28
<flexiondotorg> slangasek: I uploaded mate-desktop yesterday to fix a bug with upgrading.
<flexiondotorg> It hasn't migrated out of proposed, I don't see anything in excuses.
<flexiondotorg> Lots of user keep bumping into the issue this update fixes.
<flexiondotorg> Any idea why it is not migrating from proposed?
-queuebot:#ubuntu-release- New: accepted deal.ii [arm64] (bionic-proposed) [8.5.1-1]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [arm64] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [i386] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [s390x] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [amd64] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [ppc64el] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [armhf] (bionic-proposed) [4.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [amd64] (bionic-proposed) [8.5.1-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [s390x] (bionic-proposed) [8.5.1-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [ppc64el] (bionic-proposed) [8.5.1-1]
<tsimonq2> flexiondotorg: The update output says that it makes gir1.2-mate-desktop uninstallable, on at minimum armhf.
<slangasek> flexiondotorg: because it's not "correctly" replacing the package, when you are still building it from this same source package
<slangasek> flexiondotorg: also, unversioned Breaks+Replaces is almost never correct; it's unversioned Conflicts+Replaces, or versioned Breaks+Replaces; see policy
-queuebot:#ubuntu-release- New: accepted kubuntu-wallpapers [source] (bionic-proposed) [18.04.0]
-queuebot:#ubuntu-release- New binary: kubuntu-wallpapers [amd64] (bionic-proposed/none) [18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.8 => 3.20.5-0ubuntu0.16.04.10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ceph (artful-proposed/main) [12.2.2-0ubuntu0.17.10.1 => 12.2.4-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<didrocks> sil2100: hey! I know that seb128 opened the FFe, but I think he didn't suscribe the release team. As now, I want to upload the first components, I added more info and suscribe the team on bug #1755456. Do you mind having a look?
<ubot5> bug 1755456 in ubiquity (Ubuntu) "[ffe] Optional recording/sending of installer&system details to help improving Ubuntu" [Undecided,New] https://launchpad.net/bugs/1755456
<sil2100> didrocks: hey! Sure
<didrocks> thanks :)
<sil2100> didrocks: approved
<sil2100> (why soo laaatee?!)
<didrocks> sil2100: because the request was after FF already
<didrocks> (so not even started developping)
<didrocks> thanks!
<juliank> I guess I'll fix adequate to not fail autopkgtest
<juliank> the fix was trivial: inserting a ? in a regesx
<juliank> (ldd removed a comma in its output for undefined symbols, hence I added a ? after the comma in the regex :D)
-queuebot:#ubuntu-release- New source: ubuntu-report (bionic-proposed/primary) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [source] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New binary: ubuntu-report [s390x] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-report [amd64] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-report [ppc64el] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-report [i386] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-report [arm64] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-report [armhf] (bionic-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted ubuntu-report [amd64] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [armhf] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [ppc64el] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [arm64] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [s390x] (bionic-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ubuntu-report [i386] (bionic-proposed) [1.0.0]
<acheronuk> apw or anyone else: could the kubuntu-wallpapers binary be accepted please?
<sil2100> acheronuk: let me take a look
<sil2100> acheronuk: do you know who reviewed the source?
<acheronuk> sil2100: slangasek did AFAIK
<sil2100> Ok
<sil2100> Looking at it now
<sil2100> acheronuk: all good, done
-queuebot:#ubuntu-release- New: accepted kubuntu-wallpapers [amd64] (bionic-proposed) [18.04.0]
<acheronuk> sil2100: Great. Thank you. BTW, that is likely to be the last new source we need for 18.04, so could Kubuntu perhaps get a packageset update, once my bzr push to our seeds adding that registers?
<acheronuk> well, if not last, we can motu others
<sil2100> acheronuk: I did one in the morning today
<sil2100> Ah
<sil2100> Packageset!
<sil2100> Sorry, mis-read
<sil2100> Yeah
<acheronuk> sil2100: yup
<acheronuk> if it's convenient. no huge rush
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (xenial-proposed) [0.9.2-3ubuntu13.3]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-user-dirs [source] (xenial-proposed) [0.15-2ubuntu6.16.04.1]
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.2 => 2:8.4.0-0ubuntu7.3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libreoffice (artful-proposed/main) [1:5.4.5-0ubuntu0.17.10.5 => 1:5.4.6-0ubuntu0.17.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (artful-proposed/main) [1:5.4.5-0ubuntu0.17.10.1 => 1:5.4.6-0ubuntu0.17.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.3-0ubuntu1.1 => 2:11.0.3-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~17.10.2 => 18.2-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<sil2100> acheronuk: actually, since Final Beta is really close, could you regenerate the required bits from https://community.kde.org/Kubuntu/L10n ? If needed, of course
<sil2100> acheronuk: also, I started https://help.ubuntu.com/community/BionicUpgrades - could you start preparing the Kubuntu version of the upgrade document?
<slangasek> Laney: so I seem to have successfully received a test mail from autopkgtest-web/0
<Laney> good
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu19 => 0.6.5.6-0ubuntu20] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.2 => 0.6.5.11-1ubuntu3.3] (core)
<Laney> maybe if we just remove ssmtp from autopkgtest-cloud-worker/3 the juju configured postfix will take over and work
<Laney> hmm that one doesn't have relayhost
<acheronuk> sil2100: our language packs don't need regenerating in that fashion. they are a static tarball release
<acheronuk> sil2100: ack on the upgrade wiki
<sil2100> acheronuk: so the versions from 17th are all good for final beta?
-queuebot:#ubuntu-release- New: accepted linux-gcp [amd64] (bionic-proposed) [4.15.0-1002.2]
<acheronuk> sil2100: yes. in fact,most kde now ships translations with each individual source, and those l10n cover the small amount of left over things that haven't changed in a long time
<sil2100> Excellent
<cjwatson> Redeployed a bug-fixed version of the changes that broke the publisher yesterday, so keeping an eye on it.
<doko> with ruby-debugger-ruby-core-source and subversion migrated, I'm removing ruby2.3 \o/
<nacc> doko: nice!
<slangasek> woohoo
<doko> now get that node-js thing migrating ...
<cjwatson> Publisher looks fine.
<cjwatson> Just as well since I'm off out. :)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.2 => 2:8.4.0-0ubuntu7.3] (openstack, ubuntu-server)
<doko> slangasek: the recent gcc-7 upload has the backport for the armhf build failure you mentioned last week. sorry, can't remember the package name, but you can revert that -O1 workaround
<slangasek> doko: ok, I can't remember the package either ;)  I guess I'll look at -changes later to figure it out, thanks
<ginggs> is it possible to remove node-is-glob 4.0.0-1 from proposed?  it seems to break a couple of things
<ginggs> and I think node-policyfile/0.0.5-3ubuntu1 can be removed from release, it has no rdeps, and uses deprecated process.EventEmitter
<slangasek> ginggs: node-is-glob: why do we consider this a bug in node-is-glob, as opposed to a bug in the things that have not been updated to be compatible with it?
<slangasek> if the upstream answer is that the revdeps need to be updated, why not leave node-is-glob in -proposed until they're fixed (possibly next cycle)?
<slangasek> (one possible valid answer is that node-is-glob should also then have versioned Breaks against prior versions of its old revdeps)
<slangasek> ginggs: node-policyfile> the current autopkgtest failure seems to be more than just a deprecation issue.  is process.EventEmitter obsolete?  has its interface changed?  Should Debian bug #872894 have its severity raised?
<ubot5> Debian bug 872894 in src:node-policyfile "node-policyfile: autopkgtests fail with nodejs 6" [Important,Open] http://bugs.debian.org/872894
<ginggs> slangasek: re: node-policyfile first it was a warning, now it is a failure. so yes, I think the severity should be bumped
<slangasek> ginggs: if you do so I will use that as the justification for removal from bionic
<ginggs> slangasek: ok
<ginggs> slangasek: re: is-glob I don't understand why node-glob-base, node-glob-parent and node-parse-glob autopkgtests are now pulling in node-is-glob from -proposed, which then fails
<ginggs> slangasek: I bumped the severity of 872894
<tsimonq2> doko: What was decided re: src:mercurial?
<doko> tsimonq2: no idea, please see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<tsimonq2> doko: You pinged me yesterday in #ubuntu-devel ...
<doko> tsimonq2: no decision, however the autopkg tests still fail
<tsimonq2> doko: Please remove it from proposed then.
<ginggs> slangasek: node-glob-base, node-glob-parent and node-parse-glob upstreams all have issues open for months, with no progress
<tsimonq2> slangasek: peruse> So, how might I do version numbers going forward until it's synced?
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~16.04.2 => 18.2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> tsimonq2: sorry, I'm not sure I have context - last we talked about peruse was the private library, what's the versioning question?
<tsimonq2> slangasek: Someone accepted it after I screwed up and uploaded a Debian version
<tsimonq2> slangasek: Look at the version in Bionic.
<slangasek> tsimonq2: ok, so next upload add in ubuntu1 to the versioning
<slangasek> it'll still be "wrong" because it should really be 1.2+dfsg-0ubuntu1 instead of 1.2+dfsg-1ubuntu1, but it'll be less wrong
<tsimonq2> slangasek: ack, thanks.
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~17.10.2 => 18.2-0ubuntu1~17.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> arges: or rbasak: if there is time today we have a couple of queued uploads for artful and xenial proposed for cloud-init for a new SRU
<blackboxsw> our new SRU bug is https://bugs.launchpad.net/cloud-init/+bug/1759318
<ubot5> Ubuntu bug 1759318 in cloud-init "Release 18.2" [Medium,Fix released]
<blackboxsw> oops paste fail
<blackboxsw> our new SRU for cloud-init is https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1759406
<ubot5> Ubuntu bug 1759406 in cloud-init (Ubuntu) "sru cloud-init (17.2-35-gf576b2a2-0ubuntu1~16.04.1 update to 18.2-0ubuntu1~16.04.1)" [Medium,Confirmed]
-queuebot:#ubuntu-release- New sync: iotjs (bionic-proposed/primary) [1.0-1]
<LocutusOfBorg> sigh, glib2.0 needs some care, I can't really reproduce locally
<LocutusOfBorg> GLib-GIO:ERROR:../../../../../gio/tests/network-monitor.c:171:reach_cb: assertion failed (error == NULL): Host unreachable (g-io-error-quark, 37)
<LocutusOfBorg> Bail out! GLib-GIO:ERROR:../../../../../gio/tests/network-monitor.c:171:reach_cb: assertion failed (error == NULL): Host unreachable (g-io-error-quark, 37)
<LocutusOfBorg> FAIL: glib/network-monitor.test (Child process killed by signal 6)
<LocutusOfBorg> this seems a regression in some infrastructure configuration?
-queuebot:#ubuntu-release- New sync: arch-install-scripts (bionic-proposed/primary) [18-1]
<xnox> slangasek, ruby2.3 can be removed now \o/ https://bugs.launchpad.net/ubuntu/+source/ruby2.3/+bug/1759707
<ubot5> Ubuntu bug 1759707 in ruby2.3 (Ubuntu) "RM ruby2.3 superseeded by ruby2.5" [Critical,Triaged]
<slangasek> xnox: I think doko already removed it this morning
<xnox> ah
<xnox> then my local cache proxy charm is behind rsyncing the archive.
<xnox> sorry for the noise.
<slangasek> :)
<tsimonq2> slangasek: This isn't release-critical, but currently the switch to Calamares on Lubuntu Next is blocked by some bad kernel handling. https://bazaar.launchpad.net/%7Ekdeneon/livecd-rootfs-neon/bionic/revision/1363 has the details on what I think should probably be done; I can either write a script for Calamares to do lots of kernel hackery or just special case that change for Lubuntu Next. It'd
<tsimonq2> also be good to know if ubiquity is hardcoded anywhere in the tooling so I can special-case Lubuntu Next...
<tsimonq2> (because ofc Lubuntu Next isn't getting a release, yet)
<tsimonq2> slangasek: Of course this'll eventually become more urgent because Kubuntu's going to make the same move next cycle.
<slangasek> tsimonq2: I don't think that should be done at all; I think if you're going to switch installers, you should integrate with the existing interfaces provided by the other components in the distro...
<tsimonq2> slangasek: d-i?
<slangasek> that's nothing to do with d-i
<slangasek> it's casper, and livecd-rootfs
<tsimonq2> So, you don't think *what* should be done? :
<tsimonq2> *:)
<slangasek> tsimonq2: you said it has the details on what you think should probably be done, and it points to a commit that shows setting BINARY_REMOVE_LINUX=false, and I think that's a wrong solution
<tsimonq2> slangasek: Ah.
<slangasek> because that means you get an extra unused copy of vmlinuz on your image inside the squashfs which duplicates the one used to boot the image
<tsimonq2> Makes sense.
<tsimonq2> So, I'll see what code Ubiquity has hidden in install.py to do this kernel mangling correctly.
#ubuntu-release 2018-03-29
<tsimonq2> slangasek: With very similar reasoning to the removal of src:gitlab, I agree with bug 1759715 as well.
<ubot5> bug 1759715 in steam (Ubuntu) "Remove steam and add to sync blacklist" [Undecided,New] https://launchpad.net/bugs/1759715
<slangasek> tsimonq2: I have the deb installed currently and am not in a position to think more deeply about it than that at the moment
<tsimonq2> slangasek: OK.
-queuebot:#ubuntu-release- New: accepted xapp [amd64] (bionic-proposed) [1.0.4-2fakesync1]
<tsimonq2> So, just for general notation, I've added rls-bb-incoming to bug 1754174 and bug 1759732. These should be fixed before the Lubuntu 18.04 release, but I'd probably spend triple the time on these as someone who knows the code well would. If it comes down to it, I can throw patches, but it'd really be good to get some eyes from people more knowledgeable about the packages.
<ubot5> bug 1754174 in ubiquity (Ubuntu) "[Lubuntu] "Install Lubuntu" fails with several commands not found and permission denied" [Critical,Confirmed] https://launchpad.net/bugs/1754174
<ubot5> bug 1759732 in partman-auto-crypto (Ubuntu) "[Lubuntu] Having zram support means that encrypted LVM installs don't work" [Critical,Confirmed] https://launchpad.net/bugs/1759732
<tsimonq2> Meh, s/should be/need to be/ because these are release blockers.
<tsimonq2> infinity: Could c-cycle please be registered in Launchpad so I can start throwing bugs at it?
-queuebot:#ubuntu-release- New sync: puppet-module-puppetlabs-translate (bionic-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted arch-install-scripts [sync] (bionic-proposed) [18-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-puppetlabs-translate [sync] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [sync] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New binary: arch-install-scripts [amd64] (bionic-proposed/none) [18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [s390x] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [ppc64el] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-puppetlabs-translate [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [amd64] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [i386] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [arm64] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [armhf] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted arch-install-scripts [amd64] (bionic-proposed) [18-1]
-queuebot:#ubuntu-release- New: accepted iotjs [arm64] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [i386] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [s390x] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [amd64] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [ppc64el] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted iotjs [armhf] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-puppetlabs-translate [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New sync: cpp-hocon (bionic-proposed/primary) [0.1.6-1]
<LocutusOfBorg> slangasek, I found and I have a fix for dh-stripnondeterminism testsuite sadness, but I want to discuss it with you
<LocutusOfBorg> let me know if you are available
<LocutusOfBorg> (this is the last debhelper blocker)
-queuebot:#ubuntu-release- New sync: felix-resolver (bionic-proposed/primary) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [sync] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted felix-resolver [sync] (bionic-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New binary: cpp-hocon [i386] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: felix-resolver [amd64] (bionic-proposed/none) [1.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [s390x] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [ppc64el] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [amd64] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [arm64] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpp-hocon [armhf] (bionic-proposed/none) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cpp-hocon [amd64] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [armhf] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [ppc64el] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted felix-resolver [amd64] (bionic-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [arm64] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [s390x] (bionic-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted cpp-hocon [i386] (bionic-proposed) [0.1.6-1]
<LocutusOfBorg> slangasek, tltr, now perl if (eval{require Debian::Debhelper::Dh_Lib}) { requires a debian/ directory
<LocutusOfBorg> so  one can change debian/test/testsuite of strip-nondeterminism to do cp -rv t/ bin/ debian/ "$tmp"
<LocutusOfBorg> and "fix" even if it seems a bad approach to me, but is it "understandable" that require Debian::Debhelper::Dh_Lib requires actually a Debian directory where launched?
-queuebot:#ubuntu-release- New binary: facter [s390x] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: facter [ppc64el] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: facter [amd64] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: facter [i386] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: facter [armhf] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: facter [arm64] (bionic-proposed/universe) [3.10.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted facter [amd64] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New: accepted facter [armhf] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New: accepted facter [ppc64el] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New: accepted facter [arm64] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New: accepted facter [s390x] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New: accepted facter [i386] (bionic-proposed) [3.10.0-4]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-118.142] (core, kernel)
-queuebot:#ubuntu-release- New binary: libtgvoip [ppc64el] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [s390x] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [armhf] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [amd64] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [arm64] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtgvoip [i386] (bionic-proposed/universe) [1.0.3-3] (no packageset)
<blackboxsw> bdmurray: is there are chance today that we can start a cloud-init SRU  v.18.2 for artful and xenial  https://launchpad.net/ubuntu/artful/+queue?queue_state=1&queue_text=cloud-init https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=cloud-init
<bdmurray> blackboxsw: in a meeting at the moment
<blackboxsw> thx bdmurray hrm, well it actually looks like it's in proposed pocket.... just not listed yet in https://people.canonical.com/~ubuntu-archive/pending-sru.html yet. I guess I need to just wait for SRU processing.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-118.142]
<bdmurray> blackboxsw: why are there 2 uploads for artful?
<blackboxsw> bdmurray: the more recent one is the correct one (same content but the older upload leaked LP bug numbers in the debian/changelog that we shouldn't have)
<blackboxsw> so we pushed again about 5 hours later
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (artful-proposed) [18.2-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [17.1-11-ga4c9636b-0ubuntu1~16.04.1 => 18.1-1-g45564eef-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (artful-proposed/main) [17.1-11-ga4c9636b-0ubuntu1~17.10.1 => 18.1-1-g45564eef-0ubuntu1~17.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New source: linux-signed-azure (bionic-proposed/primary) [4.15.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (artful-proposed) [1:17.10.14]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.13]
<slangasek> LocutusOfBorg: I think it's reasonable to say that the debhelper library should require a debian package directory to act on; and I had started to think in that direction already on strip-nondeterminism, thanks for getting there before me
<LocutusOfBorg> slangasek, I presume you will upload?
<LocutusOfBorg> or I can do it, assuming mapreri can patch the source code in Debian too
<LocutusOfBorg> slangasek, I have it ready to upload btw :)
<slangasek> LocutusOfBorg: as I said, you got there before me.  I'm off work today and not going to get to it very soon
<LocutusOfBorg> so, have a nice day, and come back hopefully with a migrated debhelper :)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [source] (bionic-proposed) [4.15.0-1003.3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [amd64] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [armhf] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [ppc64el] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [arm64] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [s390x] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted libtgvoip [i386] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/none) [4.15.0-1003.3] (no packageset)
-queuebot:#ubuntu-release- New: rejected linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (artful-proposed) [12.2.4-0ubuntu0.17.10.1]
<tsimonq2> bdmurray: What is your reasoning for removing rls-bb-incoming from bug 1759732 without it having an assignee? It's release-critical for Lubuntu.
<ubot5> bug 1759732 in partman-auto-crypto (Ubuntu Bionic) "[Lubuntu] Having zram support means that encrypted LVM installs don't work" [Critical,Confirmed] https://launchpad.net/bugs/1759732
<tsimonq2> I thought I read the docs for this the other day, which is why I thought I'd ask.
<bdmurray> Because I targetted it to the release
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu20]
<ginggs> slangasek: regarding node-is-glob and node-is-descriptor, I think they have become entangled with nodejs, and the solution is to upload 4.0.0.REALLY.3.0.0-1 versions of them to fix the autopkgtest regressions in their deps
<ginggs> slangasek: and node-ip has no rdeps and I think it should be removed - RC debian bug #892658
<ubot5> Debian bug 892658 in src:node-ip "node-ip FTBFS with mocha 4.0.1-3" [Serious,Open] http://bugs.debian.org/892658
<ginggs> slangasek: node-gulp-coffee and node-miller-rabin autopkgtests are timing out on slower architectures, do you want to force-badtest, or do you prefer an upload with relaxed timeout?
<tsimonq2> bdmurray: ok
-queuebot:#ubuntu-release- Unapproved: landscape-client (artful-proposed/main) [16.03-0ubuntu3.17.10.2 => 16.03-0ubuntu3.17.10.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2.16.04.3 => 16.03-0ubuntu2.16.04.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu6.14.04.2 => 14.12-0ubuntu6.14.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1003.3+signed1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pacemaker (trusty-proposed/main) [1.1.10+git20130802-1ubuntu2.4 => 1.1.10+git20130802-1ubuntu2.5] (core)
-queuebot:#ubuntu-release- Unapproved: ssh-import-id (xenial-proposed/main) [5.5-0ubuntu1 => 5.5-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [18.2-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.2-0ubuntu1~16.04.1]
<blackboxsw> woot!
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.10]
#ubuntu-release 2018-03-30
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1003.3+signed1]
<LocutusOfBorg> hello guys, slangasek I think we should merge debhelper again, can I do it?
<elbrus> infinity: Laney: slangasek: juliank: not sure if I caught all the autopkgtest / pinning backlog
<elbrus> but just to be clear, why I wanted to get rid of pinning with a= is because one can have either sid or unstable, or testing or buster in ones sources.list
<elbrus> autopkgtest should do the right thing, not only for Ubuntu
<elbrus> and I don't want the logic to convert names in autopkgtest, as that is rediculous
<elbrus> slangasek: can you point me at the commit what you have now in Ubuntu after my "mess"
<elbrus> and I didn't see a note in the debian bug 893754, was that intentional, or just missed?
<ubot5> Debian bug 893754 in autopkgtest "autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt" [Normal,Open] http://bugs.debian.org/893754
<infinity> LocutusOfBorg: Leave debhelper to me.
<LocutusOfBorg> infinity, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+files/debhelper_11.1.6ubuntu1.dsc
<LocutusOfBorg> feel free to take from there
<LocutusOfBorg> if you read #debian-devel, some cherry-picks or this version are useful for us
<infinity> elbrus: I agree that it shouldn't "only work in Ubuntu", but I think we can also agree that "only works in Debian" isn't an ideal solution to that. ;)
<elbrus> infinity: I never intended that
<elbrus> I hope you didn't read that in my words anywhere
<infinity> elbrus: I know, hence the winky face.
<elbrus> sorry, missed that :(
<infinity> elbrus: I'm quite positive you didn't intend to break our use-case.  Just, y'know, oops.
<elbrus> right
<elbrus> so let's figure out together how to properly fix autopkgtest (or at least agree how it should behave)
 * infinity just typed "patch --dry-rub"...
<infinity> Cause who doesn't love slow roasted patches?
<infinity> LocutusOfBorg: DH merge uploaded.  It's byte-identical to yours except without all the translation cruft.
<infinity> elbrus: I'd love to be involved in getting to the bottom of doing this "right", but I also need sleep (and I'm on vacation, in theory), so I won't hold you hostage by my schedule.  I think juliank has a good handle on how I think the world should work.
<infinity> elbrus: (Really, "how the world should work" from my POV is "how it worked before these changes landed", which should be easy enough to sort out in a TDD fasion)
<elbrus> infinity: juliank actually helped with the current fix (and learned something new in the process :) )
<infinity> elbrus: And it may well just be that Debian and Ubuntu need divergent paths here, due to how we publish archives.  stable, testing, and unstable are full suites.  bionic, bionic-updates, and bionic-proposed are not (well, bionic is, the others are partials).
<elbrus> infinity: before these changes == unacceptable for autopkgtest from my standpoint
<infinity> elbrus: Which leads to curious differences.
<elbrus> infinity: I think I understand what you mean
 * elbrus doesn't know what TDD is
<infinity> elbrus: Test Driven Development.  ie: decide what we want the result to be, then make the code behave.
<elbrus> ack
<LocutusOfBorg> thanks infinity I wanted to remove the translation delta, but I know you redo usually the merge from scratch so I didn't loose any time with it :)
<LocutusOfBorg> I'm interested because now dh-strip-nondeterminism should be back in sync with debian
 * infinity wanders off to bed.
<elbrus> slangasek: skip my note on not updating the debian bug 893754, I just saw debian bug 894094
<ubot5> Debian bug 893754 in autopkgtest "autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt" [Normal,Open] http://bugs.debian.org/893754
<ubot5> Debian bug 894094 in autopkgtest "Pin 'release foo' matches foo-proposed in Ubuntu" [Normal,Open] http://bugs.debian.org/894094
<LocutusOfBorg> g night Adam!
-queuebot:#ubuntu-release- Unapproved: budgie-artwork (artful-proposed/universe) [0.8.3 => 0.8.3ubuntu1] (personal-fossfreedom)
<fossfreedom> ^^^ can an archive admin please can someone cancel the above upload - forgot to  put my name in the changelog correctly.
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.13.0-1013.16] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fonts-roboto (xenial-proposed/universe) [2:0~20160106-1 => 2:0~20160106-1ubuntu0.1] (personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: vagrant (xenial-proposed/universe) [1.8.1+dfsg-1ubuntu0.1 => 1.8.1+dfsg-1ubuntu0.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.13.0-1013.16]
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu3.7 => 2.20.7-0ubuntu3.8] (core)
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.15 => 2.20.1-0ubuntu2.16] (core)
#ubuntu-release 2018-03-31
<elbrus> Laney: infinity: slangasek: I think I have a way out with autopkgtest
<elbrus> I think we can put the Ubuntu line after an "if self.add_apt_pockets:" statement and the Debian line in the "else:"
<elbrus> I'm running the testsuite now, but does that look remotely sane to you?
-queuebot:#ubuntu-release- Unapproved: rejected budgie-artwork [source] (artful-proposed) [0.8.3ubuntu1]
<tsimonq2> slangasek: If you're around, bug 1760263.
<ubot5> bug 1760263 in ovito (Ubuntu) "RM: will become EOL upstream in December, not in testing" [Medium,Confirmed] https://launchpad.net/bugs/1760263
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [s390x] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [ppc64el] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [amd64] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [i386] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [armhf] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtwayland-opensource-src [arm64] (bionic-proposed/universe) [5.9.4-0ubuntu2] (kubuntu, qt5)
<elbrus> slangasek: Laney: could you verify that my latest push for autopkgtest fixes the issue for Ubuntu?
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [amd64] (bionic-proposed) [5.9.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [armhf] (bionic-proposed) [5.9.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [ppc64el] (bionic-proposed) [5.9.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [arm64] (bionic-proposed) [5.9.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [s390x] (bionic-proposed) [5.9.4-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtwayland-opensource-src [i386] (bionic-proposed) [5.9.4-0ubuntu2]
<doko> ecj needs a hint. all the *gcj* packages are already removed
-queuebot:#ubuntu-release- Unapproved: budgie-artwork (artful-proposed/universe) [0.8.3 => 0.8.3ubuntu1] (personal-fossfreedom)
-queuebot:#ubuntu-release- New sync: python-wsproto (bionic-proposed/primary) [0.11.0-2]
#ubuntu-release 2018-04-01
-queuebot:#ubuntu-release- New binary: ocrmypdf [amd64] (bionic-proposed/universe) [6.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocrmypdf [amd64] (bionic-proposed) [6.1.2-1]
-queuebot:#ubuntu-release- New: accepted python-wsproto [sync] (bionic-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New binary: python-wsproto [amd64] (bionic-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-wsproto [amd64] (bionic-proposed) [0.11.0-2]
#ubuntu-release 2019-03-25
-queuebot:#ubuntu-release- New: rejected carla [source] (disco-proposed) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- New source: carla (disco-proposed/primary) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted carla [source] (disco-proposed) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- New binary: carla [amd64] (disco-proposed/universe) [1.9.13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: carla [i386] (disco-proposed/universe) [1.9.13-0ubuntu1] (no packageset)
<ginggs> tseliot: hi, are you aware nvidia-graphics-drivers-418 is not migrating? unsatisfiable Depends: nvidia-kernel-source-418
-queuebot:#ubuntu-release- New: accepted carla [amd64] (disco-proposed) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted carla [i386] (disco-proposed) [1.9.13-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1010.12~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1010.12~16.04.1]
<fossfreedom_> hi there - anyone around that can help please?  Our (Ubuntu Budgie) disco dailies have been failing over the weekend - dont really understand why though http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/disco/daily-live-20190324.log
<fossfreedom_> given the ISO timestamps I'm guess lubuntu and Studio are similarly failing?
<acheronuk> fossfreedom_: infinity was fixing last night. Kubuntu at least worked this morning @ ~5am UK time
<fossfreedom_> ah - excellent news. cheers
<acheronuk> I would guess your will be ok on next cron, or manual trying, or beta candidate. Whichever happens soonest
<acheronuk> Xubuntu an Ubuntu dailies also fixing this morning :)
<fossfreedom_> cross fingers (and toes)
<acheronuk> I think the problem was it using mismatched versions of debian-installer in the build compared to what was in the archive to actually go in the iso
<tseliot> ginggs: hi, I thought I had fixed that
<ginggs> tseliot: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nvidia-graphics-drivers-418
<tseliot> apw: hi, can you check why nvidia-kernel-source-418 is an unsatisfiable dependency in disco, please?
<tseliot> ginggs: I wonder if the binary is not in restricted, or something
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-proposed/universe) [6.0.1-7~18.04 => 6.0.1-7ubuntu1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scilab (cosmic-proposed/universe) [6.0.1-7~18.10 => 6.0.1-7ubuntu1~18.04] (no packageset) (sync)
<apw> tseliot, seems my sweep last week managed to miss that missmatch, hmmm
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-proposed/universe) [6.0.1-7~18.04 => 6.0.1-7ubuntu1~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected scilab [sync] (bionic-proposed) [6.0.1-7ubuntu1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (bionic-proposed) [6.0.1-7ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: rejected scilab [sync] (cosmic-proposed) [6.0.1-7ubuntu1~18.04]
<acheronuk> apw sil2100: can I bring your attention to LP #1821091 so you are least aware. even if approved, I don't think we can land that before beta freeze is rolled back, but probably best you know it could be in the offing
<ubot5`> Launchpad bug 1821091 in qtbase-opensource-src (Ubuntu) "[FFe] Qt 5.12.2 update" [Undecided,New] https://launchpad.net/bugs/1821091
<acheronuk> ^^ same to other release team not on vacation
<acheronuk> mitya57: hope that seems reasonable
<tseliot> apw: ok, it should be an easy fix then, thanks
<apw> tseliot, in theory already done
<tseliot> great, thanks
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-tools-apksig [sync] (bionic-proposed) [0.8-2ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: rejected android-platform-tools-apksig [sync] (cosmic-proposed) [0.8-2ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.22 => 1.0.1ubuntu2.23] (core)
<juliank> sil2100: ^ there's the apt/trusty fixup
<juliank> a bit of noise in the .po files from changing line numbers in there
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.10 => 239-7ubuntu10.11] (core)
<sil2100> juliank: ACK, will review in some minutes
<juliank> thx
<tseliot> ginggs: 418 has just migrated :)
<ginggs> tseliot: \o/ thanks!
<tseliot> thanks apw!
<apw> tseliot, np
<coreycb> vorlon: thanks for the review! i'm fixing up the test name for masakar-monitors and uploading again. the init.in files are templates that we build init scripts from using openstack-pkg-tools' pkgos-gen-systemd-unit tool.
<coreycb> vorlon: /usr/bin/privsep-helper comes from python3-oslo.privsep. there are more details on that at: https://specs.openstack.org/openstack/oslo-specs/specs/liberty/privsep.html - the code decorated by @privsep.monitors_priv.entrypoint in masakari-monitors/masakarimonitors/utils.py is what gets executed with elevated privileges.
<coreycb> vorlon: i wouldn't be opposed to a security review on it. btw we dropped the seeding of masakari* from disco and will likely add it back early next release.
-queuebot:#ubuntu-release- New source: masakari-monitors (disco-proposed/primary) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rsyslog (xenial-proposed/main) [8.16.0-1ubuntu3 => 8.16.0-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1029.31~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted rsyslog [source] (xenial-proposed) [8.16.0-1ubuntu3.1]
<slashd> sil2100, big thanks ^ !!
-queuebot:#ubuntu-release- Unapproved: golang-1.10 (trusty-security/main) [1.10.4-2ubuntu1~14.04.1 => 1.10.4-2ubuntu1~14.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.10 [sync] (trusty-security) [1.10.4-2ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.19] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1029.31~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.23]
-queuebot:#ubuntu-release- New sync: libcompress-snappy-perl (disco-proposed/primary) [0.24+ds-1]
-queuebot:#ubuntu-release- New sync: libhtml-tidy5-perl (disco-proposed/primary) [1.04-1]
-queuebot:#ubuntu-release- New sync: libregexp-trie-perl (disco-proposed/primary) [0.02-1]
<LocutusOfBorg> some new leaf perl packages ^^
-queuebot:#ubuntu-release- New sync: libmodule-build-using-pkgconfig-perl (disco-proposed/primary) [0.02-1]
-queuebot:#ubuntu-release- New sync: liburl-search-perl (disco-proposed/primary) [0.000005-1]
-queuebot:#ubuntu-release- New sync: libsql-tiny-perl (disco-proposed/primary) [0.02-1]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.16 => 237-3ubuntu10.17] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.16 => 237-3ubuntu10.17] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.19] (core)
<mvo> hi, could an someone please reject the systemd bionic and xenial uploads from my except the latest one please? I was asked to include an extra fix for wsl so things changed a bit but the latest ones should be good now
<sil2100> mvo: on it
<juliank> mvo: systemd SRUs - now that's some scary stuff ;)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.17]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (xenial-proposed) [229-4ubuntu21.19]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.17]
<mvo> juliank: tell me about it, its not fun!
<mvo> sil2100: thank you!
<sil2100> Let me review them once I'm done with this kernel
<Eickmeyer> vorlon: Thanks for the overnight action there! Also, thanks for the typo fixes and such. I have been distracted all weekend with my son's birthday celebrations.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.11]
<acheronuk> sil2100: I think the idea now of the Qt FFe is to get it ready to land for when the beta freeze finishes, then assess the viability. I pinged earlier as a FYI, so it didn't look so much of an 'ambush' later in the week ;)
<acheronuk> wanting it to land before, but Qt release date tend to slip back :/
<acheronuk> sil2100: lets see if we can back up with evidence by beta release that it is ok to land
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.17]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.19]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu3.18.10.2 => 1.5ubuntu3.18.10.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New source: masakari-monitors (disco-proposed/primary) [7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Packageset: 165 entries have been added or removed
-queuebot:#ubuntu-release- New: rejected masakari-monitors [source] (disco-proposed) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected masakari-monitors [source] (disco-proposed) [7.0.0~b1-0ubuntu1]
<vorlon> coreycb: your explanation about the init.in files does not make me feel any better at all fwiw.  as for python3-oslo.privsep, why does this need to be an alternative at this point, vs. having the python3 package provide /usr/bin/privsep-helper exclusively?  and what other prior art is there for this use of privsep-helper in other packages, so I can compare?
<coreycb> vorlon: it probably doesn't need to be an alternative at this point. we dropped all py2 core packages in disco but did not get to all the dependencies.
<coreycb> the init.in files are fairly standard across the openstack packages
<coreycb> i'll try to find some prior-art on privsep helper.
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.9 => 1.1ubuntu1.18.04.10] (desktop-core, ubuntu-server)
<Eickmeyer> vorlon: Did you get an arm buld failure when you uploaded carla, by any chance?
<coreycb> vorlon: i don't think we have exact prior art for privsep-helper since this is a new way of limiting privilege execution - current examples that I can show you use rootwrap as described here as a prior privilege mechanism - https://specs.openstack.org/openstack/oslo-specs/specs/liberty/privsep.html#problem-description
<coreycb> vorlon: here's the neutron sudoers file for rootwrap that we currently use - https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron/tree/debian/neutron_sudoers
<coreycb> and a corresponding filter for privsep-helper - https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron/tree/etc/neutron/rootwrap.d/privsep.filters
<vorlon> coreycb: ok - but at least in principle, this sort of thing is being done across the openstack packages currently.  So the specific implementation of privsep-wrap ought to be vetted as part of any MIR for this
<coreycb> vorlon: absolutely. i'm all for this getting a security review.
<vorlon> Eickmeyer: yes.  most other archs are dep-wait because you build-depend on g++-multilib (why?), which doesn't exist on those archs
-queuebot:#ubuntu-release- New: accepted masakari-monitors [source] (disco-proposed) [7.0.0~rc1-0ubuntu1]
<vorlon> Eickmeyer: whereas armhf ftbfs because g++-multilib exists but doesn't help with the x86-specific compiler flags being hard-coded
<Eickmeyer> vorlon: Okay, that's fine. I was just checking. We don't need (or really want) arm builds for this package anyhow.
<Eickmeyer> I got the same when updating the package to the 2.0.0 final release (new tar, sans patches), which piqued my question.
<coreycb> jamespage: you'll probably want to review the use of privsep-helper in masakari-monitors as well - see d/masakarimonitors_sudoers
-queuebot:#ubuntu-release- New binary: masakari-monitors [amd64] (disco-proposed/universe) [7.0.0~rc1-0ubuntu1] (no packageset)
<Eickmeyer> vorlon: That failure won't prevent it from migrating from propsed will it?
<vorlon> Eickmeyer: no
<Eickmeyer> vorlon: Thanks. :)
<vorlon> what matters for migration is not regressing the set of supported archs
<Eickmeyer> Okay. Rosco2 and I were confused.
-queuebot:#ubuntu-release- Unapproved: ufw (bionic-proposed/main) [0.35-5 => 0.36-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: ufw (cosmic-proposed/main) [0.35-6 => 0.36-0ubuntu0.18.10.1] (core)
<jdstrand> hey, I filed an FFe for apparmor some time ago. I thought I did it right: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1817799
<ubot5`> Ubuntu bug 1817799 in apparmor (Ubuntu) "[FFe] apparmor 2.13" [Undecided,New]
<jdstrand> can someone let me know if I need to do anything else to get it on people's radar?
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [sync] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libmodule-build-using-pkgconfig-perl [sync] (disco-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted libsql-tiny-perl [sync] (disco-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [sync] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted liburl-search-perl [sync] (disco-proposed) [0.000005-1]
-queuebot:#ubuntu-release- New: accepted libregexp-trie-perl [sync] (disco-proposed) [0.02-1]
<vorlon> coreycb: lintian has a lot to say about the binary .changes file for masakari-monitors
-queuebot:#ubuntu-release- New: accepted masakari-monitors [amd64] (disco-proposed) [7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [arm64] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [ppc64el] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-tidy5-perl [arm64] (disco-proposed/universe) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-tidy5-perl [ppc64el] (disco-proposed/universe) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [armhf] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-tidy5-perl [armhf] (disco-proposed/universe) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [s390x] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-tidy5-perl [s390x] (disco-proposed/universe) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-tidy5-perl [amd64] (disco-proposed/universe) [1.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsql-tiny-perl [amd64] (disco-proposed/universe) [0.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libregexp-trie-perl [amd64] (disco-proposed/universe) [0.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liburl-search-perl [amd64] (disco-proposed/universe) [0.000005-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [amd64] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmodule-build-using-pkgconfig-perl [amd64] (disco-proposed/universe) [0.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcompress-snappy-perl [i386] (disco-proposed/universe) [0.24+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [amd64] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [i386] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [amd64] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted libmodule-build-using-pkgconfig-perl [amd64] (disco-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted libsql-tiny-perl [amd64] (disco-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [s390x] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted liburl-search-perl [amd64] (disco-proposed) [0.000005-1]
-queuebot:#ubuntu-release- New: accepted libregexp-trie-perl [amd64] (disco-proposed) [0.02-1]
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [arm64] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [ppc64el] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [arm64] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [ppc64el] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [armhf] (disco-proposed) [0.24+ds-1]
-queuebot:#ubuntu-release- New: accepted libhtml-tidy5-perl [armhf] (disco-proposed) [1.04-1]
-queuebot:#ubuntu-release- New: accepted libcompress-snappy-perl [s390x] (disco-proposed) [0.24+ds-1]
#ubuntu-release 2019-03-26
-queuebot:#ubuntu-release- New binary: snapd-glib [i386] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: progress-linux-metapackages (disco-proposed/primary) [20190225-3]
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (cosmic-proposed/universe) [0.8.10-1build1 => 0.8.11-0ubuntu0.18.10.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (bionic-proposed/universe) [0.8.10-1 => 0.8.11-0ubuntu0.18.04.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (xenial-proposed/universe) [0.8.9-0ubuntu0.16.04.1 => 0.8.11-0ubuntu0.16.04.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.5-0ubuntu1 => 2:12.0.5-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu1 => 2:13.0.2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected xdg-desktop-portal [source] (bionic-proposed) [1.0.3-0ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (bionic-proposed/universe) [1.0.3-0ubuntu0.1 => 1.0.3-0ubuntu0.2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal [source] (bionic-proposed) [1.0.3-0ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.38-2ubuntu1~18.04.1 => 8.5.39-1ubuntu1~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (cosmic-proposed/universe) [8.5.38-2ubuntu1~18.04.1 => 8.5.39-1ubuntu1~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.39-1ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: rejected tomcat8 [sync] (cosmic-proposed) [8.5.39-1ubuntu1~18.04]
<LocutusOfBorg> jbicha, reasons for ruby-gnome2 failures? also the current package in -release FTBFS in the same way... I suspect some cairo gtk3 changes, but after 4 days of debug... nothing
<LocutusOfBorg> oh... gtk3 bumped version
-queuebot:#ubuntu-release- Unapproved: tomcat8 (cosmic-proposed/universe) [8.5.38-2ubuntu1~18.04.1 => 8.5.39-1ubuntu1~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (cosmic-proposed) [8.5.39-1ubuntu1~18.04]
<bdmurray> coreycb: Could you improve the regression potential in bug 1818614?
<ubot5`> bug 1818614 in neutron (Ubuntu Cosmic) "[SRU] Various L3HA functional tests fails often" [High,Triaged] https://launchpad.net/bugs/1818614
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3.18.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.10]
<coreycb> bdmurray: yep, done
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (cosmic-proposed) [17.11.5-0~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected shadow [source] (bionic-proposed) [1:4.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu2]
<jdstrand> hey, I asked about this yesterday, but some time ago I issue a FFe for apparmor 2.13. I thought I followed the process, but no one looked at it yet: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1817799
<ubot5`> Ubuntu bug 1817799 in apparmor (Ubuntu) "[FFe] apparmor 2.13" [Undecided,New]
<jdstrand> can someone take a look?
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (bionic-proposed) [1:4.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libglvnd (disco-proposed/main) [1.1.0-1 => 1.1.1-0ubuntu1] (core)
<jdstrand> infinity: can you confirm that ^ is even on the list of things to review?
<jdstrand> infinity: hi btw :)
<jdstrand> ah, it does sho up in https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs
<jdstrand> show even
<infinity> jdstrand: The obvious question is, if it's been in progress in Debian for so long, why did we wait until post-FF to get it in Ubuntu? :)
<jdstrand> infinity: resource constraints and honestly, bug fixing there. I wanted to do it before the freeze, but there was a particular bug around profile loads that I didn't want to introduce. it was fixed after FF
<infinity> jdstrand: Ahh, and the snapd you needed didn't land until just recently, I see.
<jdstrand> infinity: I mean, it can technically wait til e opens
<jdstrand> infinity: yes, that too
-queuebot:#ubuntu-release- Unapproved: accepted libunistring [source] (bionic-proposed) [0.9.9-0ubuntu2]
<infinity> jdstrand: If your confidence level is very high, and your commitment to fixing it when it turns out you're wrong is even higher, then I'm fine with it.
<jdstrand> infinity: but wanted to get this batch of changes in for less disruption. if it is too late now, that isn't the worst thing
<jdstrand> infinity: it is and it is
<infinity> jdstrand: Just take into account the snappy team's turnaround time too, if you discover that half the bugs are theirs.
<jdstrand> heh, those could changes were pretty small. I'm confident and will work with them as needed
<jdstrand> code*
<jdstrand> jeez, type much?
<infinity> jdstrand: Is that ugly snap-confie parser error thing also fixed in newer snapd, or will everyone see that scary on upgrade?
<jdstrand> infinity: that should normally be created. I can verify in disco and file a bug and get it on their radar
<infinity> Also:
<infinity> dpkg: warning: unable to delete old directory '/etc/apparmor.d/cache': Directory not empty
<infinity> Do you need some extra magic to migrate or remove old cache contents so we're not leaving cruft around?
<cascardo> bdmurray: hey, I have just updated the last bug on the list for makedumpfile bionic SRU, could you get it looked at again, please?
<jdstrand> infinity: I saw that and something later cleans it and its gone
 * jdstrand looks to see what that is
<jdstrand> infinity: postint rm -rf's it
<jdstrand> (which is fine, the new parser recreates everything in /var/cache/apparmor
<jdstrand> )
<infinity> Would probably make more sense for preinst to rm cachedir/* but okay.
<jdstrand> I can adjust that
<infinity> Not super picky.  I just like clean upgrades, and I'm sure 3 or 4 people still watch the dpkg output. :)
<infinity> (Though depending on how and when caches are used, it might make more sense for in general to whack cachedir/* in preinst ANYWAY, so you don't have new binary and old cache before postinst generates new cache?)
<infinity> But then you'd want oldcachedir (if upgrade from << foo) AND newcachedir.
<jdstrand> the parser will ignore those and put them in /var/cache/apparmor so there isn't an issue if I see what you are getting at, but I'm already testing a fix
<infinity> jdstrand: Sure, the new parser will ignore them cause it doesn't read there, but what happens when /var/cache/apparmor contains cache that a new binary doesn't love?
<infinity> jdstrand: That was my "in general, maybe wiping it is smart anyway".
<infinity> jdstrand: And then, if that general code is there, adding a special case for "oh, and get the old cache dir too, on upgrade from old versions" has a home.
<jdstrand> infinity: we don't do that unconditionally on upgrades since the parser is smart enough to know when to invalidate
<infinity> Fair enough.
<jdstrand> and when not to
<bdmurray> cpaelzer__: https://bugs.launchpad.net/ubuntu/+source/numactl/+bug/1817258/comments/20 that'd be highly unusual. Could you explain more why you think we should release it anyway?
<ubot5`> Ubuntu bug 1817258 in numactl (Ubuntu Cosmic) ""numastat" doesn't display correct information for the guest." [High,Fix committed]
<jdstrand> infinity: so the ugly message/snapd issue is not seen. I think that was a local issue (I recall now I was working with a particularly minimal vm and was purging --force-breaksing and the like and likely removed snapd but didn't purge, so that dir was gone but the profile was on the system)
<infinity> jdstrand: Ahh, good.
<jdstrand> I'll have the preinst adjusted in a sec (missed a hidden file in my first test :)
<jdstrand> infinity: the process says you'd put it at triaged. are you still reviewing?
 * jdstrand is happy to wait, just want to upload at the right time :)
<infinity> jdstrand: Bug updated.
<jdstrand> infinity: thanks for the review :)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.11]
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.12-4ubuntu10 => 2.13.2-9ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: backports.functools-lru-cache (disco-proposed/main) [1.5-2 => 1.5-3] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted health-check [source] (bionic-proposed) [0.02.09-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (xenial-proposed) [1:4.2-3.1ubuntu5.4]
-queuebot:#ubuntu-release- Unapproved: rtkit (disco-proposed/main) [0.12-3 => 0.12-4] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rtkit [sync] (disco-proposed) [0.12-4]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.45]
<ginggs> infinity: o/ if you are handing out FFes, please LP: #1821792
<ubot5`> Launchpad bug 1821792 in nvidia-cuda-toolkit (Ubuntu) "FFe: Sync nvidia-cuda-toolkit 10.1.105-1 (multiverse) from Debian experimental (non-free) " [Undecided,New] https://launchpad.net/bugs/1821792
-queuebot:#ubuntu-release- Unapproved: python3.7 (disco-proposed/main) [3.7.3-1 => 3.7.3-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (disco-proposed) [3.7.3-1ubuntu1]
<tumbleweed> ginggs: approved
<ginggs> tumbleweed: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted backports.functools-lru-cache [sync] (disco-proposed) [1.5-3]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Disco Beta] (20101020ubuntu567) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Beta] (20190326.1) has been added
<bdmurray> infinity: How should I evaluate the snapd-glib stuff in the cosmic new queue?
<infinity> bdmurray: Ask an AA, cause you can't do anything about it?
<infinity> bdmurray: (I'll look in a bit)
<bdmurray> infinity: thanks
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Beta] (20190326.1) has been added
<bdmurray> cascardo: This makedumpfile update looks like a new upstream microrelease in which case https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases should be followed.
-queuebot:#ubuntu-release- Unapproved: accepted ufw [source] (cosmic-proposed) [0.36-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ufw [source] (bionic-proposed) [0.36-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (cosmic-proposed) [0.8.11-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Beta] (20190326.2) has been added
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (bionic-proposed) [0.8.11-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] (20190326) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Beta] (20190326.1) has been added
-queuebot:#ubuntu-release- Unapproved: apparmor-profiles-extra (disco-proposed/universe) [1.26 => 1.26ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor-profiles-extra [source] (disco-proposed) [1.26ubuntu1]
#ubuntu-release 2019-03-27
<RAOF> infinity: I believe the xenial xdg-desktop-portal SRU would be a nice chance to learn about accepting binary NEW :)
-queuebot:#ubuntu-release- Unapproved: xfce4-settings (cosmic-proposed/universe) [4.13.4-1ubuntu1 => 4.13.4-1ubuntu1.18.10.1] (xubuntu)
<RAOF> That saidâ¦ kenvandine, do you have any ideas about the ppc64el xdg-desktop-portal autopkgtest failure you've retried twice? âº
<kenvandine> RAOF: I've asked jamesh to look at it
<RAOF> Cool, ta.
<Eickmeyer> 20190326.1 for Ubuntu Studio is good to do, all checkboxes checked. :)
-queuebot:#ubuntu-release- Unapproved: xfce4-settings (xenial-proposed/universe) [4.12.0-2ubuntu1 => 4.12.0-2ubuntu1.16.04.1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: apparmor-profiles-extra (disco-proposed/universe) [1.26ubuntu1 => 1.26ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor-profiles-extra [source] (disco-proposed) [1.26ubuntu2]
<infinity> tjaalton: Any ideas about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1821820 ?
<ubot5`> Ubuntu bug 1821820 in xserver-xorg-video-intel (Ubuntu) "Cannot boot or install - have to use nomodeset" [Undecided,New]
<tjaalton> infinity: seems like a kernel regression
-queuebot:#ubuntu-release- Unapproved: firefox (disco-proposed/main) [66.0.1+build1-0ubuntu1 => 66.0.2+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<doko> apw: please could you have a look at the linux autopkg regressions? almost all archs
<apw> doko, ack
<ginggs> can we please consider hinting python-scipy and scikit-learn?  both autopkgtests pass for me locally on amd64 - nvidia-cuda-toolkit is incoming, and this should allow us to drop gcc-7
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (disco-proposed/multiverse) [10.1.105-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (disco-proposed/multiverse) [10.1.105-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: intel-mediasdk (disco-proposed/primary) [18.4.1-0ubuntu1]
<fossfreedom_> tjaalton: thx for the feedback for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1821820 ... will have a go to get the dmesg stuff later today when I get home. cheers
<ubot5`> Ubuntu bug 1821820 in xserver-xorg-video-intel (Ubuntu) "Cannot boot or install - have to use nomodeset" [Undecided,New]
<tjaalton> fossfreedom_: can you try with an external monitor?
<tjaalton> separately
<tjaalton> to see if it works
<fossfreedom_> sure
<tjaalton> also, boot without 'quiet splash' so you might even get an error trace on the external screen, or maybe not
<oSoMoN> dear release team, can you please accept firefox 66.0.2+build1-0ubuntu1 in disco-proposed?
-queuebot:#ubuntu-release- Unapproved: starpu (disco-proposed/universe) [1.2.6+dfsg-7 => 1.2.6+dfsg-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted starpu [source] (disco-proposed) [1.2.6+dfsg-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: trafficserver (disco-proposed/universe) [8.0.3+ds-1ubuntu1 => 8.0.3+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted trafficserver [sync] (disco-proposed) [8.0.3+ds-2]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-145.171] (core, kernel)
<handsome_feng> Hi, Could someone have a look at LP: #1821678, without the new version, ubuntukylin 19.04 beta will pull in gnome-shell
<ubot5`> Launchpad bug 1821678 in Ubuntu Kylin "[FFe] Please sync ukui-biometric-auth 1.0.3-2(universe) from debian(experimental)" [Critical,New] https://launchpad.net/bugs/1821678
-queuebot:#ubuntu-release- Unapproved: libunistring (cosmic-proposed/main) [0.9.10-1ubuntu1 => 0.9.10-1ubuntu1.18.10.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-145.171]
-queuebot:#ubuntu-release- Unapproved: libidn (cosmic-proposed/main) [1.33-2.2ubuntu1 => 1.33-2.2ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: libunistring (cosmic-proposed/main) [0.9.10-1ubuntu1 => 0.9.10-1ubuntu1.18.10.1] (core)
<LocutusOfBorg> apw please hint perl
<LocutusOfBorg> the problem is indeed in the testsuite, wrong files have been added in wrong specific directories
<LocutusOfBorg> -rw-r--r-- 1 locutus locutus 12306 mar 16 15:02 debian/tests/data/arm64/stretch-ndbm.dir
<LocutusOfBorg> all the "*ndbm.dir" are 16 bytes, so I presume a copy-pasta problem (specially because they have same md5sum as others in the same directory), since they are new tests, they are broken because of a wrong test, I forwarded this to Debian, difficult to check if my fix works or not, autopkgtests takes eons for perl... hint?
<LocutusOfBorg> versioned is fine
-queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.56-0ubuntu1 => 0.09.57-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (disco-proposed) [0.09.57-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.0~rc1-0ubuntu1 => 2:14.0.0~rc1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.0.1-1ubuntu5 => 1:3.32.0.1-1ubuntu6] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (disco-proposed/main) [3.32.0-1 => 3.32.0-1ubuntu1] (desktop-core, desktop-extra) (sync)
<handsome_feng> Hi, Does anyone know if I respin the iso, will it based on the new seeks which I uploaded recently?
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu2 => 2:13.0.2-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.5-0ubuntu2 => 2:12.0.5-0ubuntu3] (openstack, ubuntu-server)
<handsome_feng> Sorry, s/seeks/seeds/g
-queuebot:#ubuntu-release- Unapproved: libxmlb (disco-proposed/main) [0.1.6-2 => 0.1.8-1] (desktop-core) (sync)
<fossfreedom_> handsome_feng: should be ok - assuming that your meta package created from the seeds has found its way into the release pocket.
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.13.2-9ubuntu2 => 2.13.2-9ubuntu3] (core)
<handsome_feng> fossfreedom_, Thank you!
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu3]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (disco-proposed/main) [1.1.1+bzr982-0ubuntu20 => 1.1.1+bzr982-0ubuntu21] (desktop-core)
<juliank> ^ this fixes the raise StopIteration issues
<juliank> :)
<juliank> It has less failing tests than the current one
<juliank> :)
-queuebot:#ubuntu-release- Unapproved: pbuilder (disco-proposed/universe) [0.230.2 => 0.230.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pbuilder [sync] (disco-proposed) [0.230.3]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] has been updated (20190327)
-queuebot:#ubuntu-release- Unapproved: python-sievelib (disco-proposed/universe) [1.1.1-1 => 1.1.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-sievelib [source] (disco-proposed) [1.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (disco-proposed) [10.1.105-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (disco-proposed) [10.1.105-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (bionic-proposed) [17.11.5-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: javatools (disco-proposed/universe) [0.72.6 => 0.72.6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted javatools [source] (disco-proposed) [0.72.6ubuntu1]
<infinity> LocutusOfBorg: We were intentionally not hinting perl, since a fixed upload should be on the way.
<infinity> LocutusOfBorg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925179
<ubot5`> Debian bug 925179 in perl "perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility" [Important,Open]
<LocutusOfBorg> ok infinity I was just trying to help in making it migrate, so looks like my effort was useless :D
<LocutusOfBorg> but it has been a nice learning opportunity
<infinity> LocutusOfBorg: proposed-migration isn't a game whose goal is to make things migrate at all costs.
<infinity> (And I wish people would stop treating it that way)
<LocutusOfBorg> mitya57, I'm stealing your qtwebkit merge, unless you want to do it, I want this fixed :) https://bugs.launchpad.net/ubuntu/+source/sigil/+bug/1755311
<ubot5`> Ubuntu bug 1755311 in sigil (Ubuntu) ""Warning: libpng warning: iCCP: known incorrect sRGB profile"" [Undecided,New]
<infinity> Having test regressions in a core package that historically never fails tests isn't useful.
<LocutusOfBorg> infinity, if the bug is in the testsuite and a testsuite only bug, and can be fixed in the next debian upload...
<LocutusOfBorg> I was trying to avoid a ton of autopkgtestsuites
<infinity> LocutusOfBorg: We want a green baseline for the release, which means a new upload anyway, which means more tests.
<infinity> And we're in no rush to have the current one in.
<LocutusOfBorg> ok, I understand your point
<LocutusOfBorg> btw do you have some clue for ruby failures on armhf? I suspect alignment issues...
<LocutusOfBorg> ruby-jquery-ui-rails and ruby-devise
<LocutusOfBorg> I'm tempted to do a -O0, to see if it helps
<infinity> LocutusOfBorg: I'm not fluent in ruby backtraces, but Bus Error is almost always alignment.  Dropping optimisation probably won't help.
<LocutusOfBorg> because the failure is in rails?
<infinity> No, because optimisation rarely affects alignment.
<LocutusOfBorg> I remember fixing something like that in the past with -O0, but I might be wrong
<infinity> Of course, there was also once upon a time some talk of punting rails and all its rdeps as an unmaintainable mess that most actual ruby users in the world get from gems instead of debs.
<infinity> rbasak: ^-- What ever came of that?
<rbasak> I intend to write to ubuntu-devel@ about that this week.
-queuebot:#ubuntu-release- Unapproved: android-platform-tools-apksig (cosmic-proposed/universe) [0.8-2~18.04 => 0.8-2ubuntu1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-tools-apksig [sync] (cosmic-proposed) [0.8-2ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (disco-proposed/universe) [5.212.0~alpha2-19ubuntu1 => 5.212.0~alpha2-21ubuntu1] (kubuntu, qt5)
<LocutusOfBorg> mitya57, ^^ this is the one in the queue...
<mitya57> LocutusOfBorg: thanks!
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (disco-proposed/multiverse) [1.0.0+git20180821.99bd997-2build1 => 1.0.0+git20180821.99bd997-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted caffe-contrib [source] (disco-proposed) [1.0.0+git20180821.99bd997-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: eztrace-contrib (disco-proposed/multiverse) [1.1-8-3build1 => 1.1-8-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted eztrace-contrib [source] (disco-proposed) [1.1-8-3build2]
-queuebot:#ubuntu-release- Unapproved: hwloc-contrib (disco-proposed/multiverse) [1.11.12-3ubuntu1 => 1.11.12-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hwloc-contrib [source] (disco-proposed) [1.11.12-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: pycuda (disco-proposed/multiverse) [2018.1.1-3build1 => 2018.1.1-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pycuda [source] (disco-proposed) [2018.1.1-3build2]
-queuebot:#ubuntu-release- Unapproved: starpu-contrib (disco-proposed/multiverse) [1.2.6+dfsg-6build1 => 1.2.6+dfsg-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted starpu-contrib [source] (disco-proposed) [1.2.6+dfsg-6ubuntu1]
<bdmurray> infinity: were you going to have a look at the snapd-glibs in cosmic new queue?
<infinity> bdmurray: I sure were.
-queuebot:#ubuntu-release- Unapproved: apparmor (disco-proposed/main) [2.13.2-9ubuntu3 => 2.13.2-9ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu4]
-queuebot:#ubuntu-release- Unapproved: znc (disco-proposed/universe) [1.7.2-1 => 1.7.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted znc [sync] (disco-proposed) [1.7.2-2]
<Ukikie> â sync fixes a CVE, has a Debian unblock bug.
<ginggs> doko: i think this is done now https://people.canonical.com/~ubuntu-archive/transitions/html/libgfortran.html anything else needed to drop gcc-7?
-queuebot:#ubuntu-release- New: accepted snapd-glib [amd64] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: accepted snapd-glib [armhf] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: accepted snapd-glib [ppc64el] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: accepted snapd-glib [arm64] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: accepted snapd-glib [s390x] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- New: accepted snapd-glib [i386] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
#ubuntu-release 2019-03-28
-queuebot:#ubuntu-release- Unapproved: snapd-glib (disco-proposed/main) [1.47-0ubuntu1 => 1.47-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+4-1ubuntu1 => 11.0.3+4-1ubuntu2] (core)
<Trevinho> anyone in the SRU team could review syncs for unity in bionic and xenial? https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
<Trevinho> use this tool to review if you want to the process in classic way :)
<bluesabre> Does it look like we're going to have any respins, or do the current images look like they'll be the beta release images?
<valorie> we found very few bugs so far in kubuntu
<bluesabre> nice, xubuntu likewise seems A-OK. Planning to mark it ready when I get up tomorrow.
-queuebot:#ubuntu-release- Unapproved: collectd (bionic-proposed/universe) [5.7.2-2ubuntu1 => 5.7.2-2ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (disco-proposed) [1.47-0ubuntu2]
-queuebot:#ubuntu-release- New sync: r-cran-lwgeom (disco-proposed/primary) [0.1-5+repack-1]
<handsome_feng> Hi, could anyone in release team help to upload ukui-greeter which fix LP: #1822014 before beta release?
<ubot5`> Launchpad bug 1822014 in Ubuntu Kylin "ukui-greeter failed to launch on ubuntukylin 19.04 beta iso" [Critical,Confirmed] https://launchpad.net/bugs/1822014
<handsome_feng> The new version of ukui-greeter is stored at: https://launchpad.net/~ubuntukylin-members/+archive/ubuntu/1904updates
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+4-1ubuntu2]
<doko> ginggs: I'm moving the tracker. Don't want to drop gcc-7 before we get the bionic update in place
-queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (disco-proposed/universe) [8.0.0-3 => 8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [amd64] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [ppc64el] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [i386] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [s390x] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [arm64] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [armhf] (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjdk-12 (disco-proposed/universe) [12.0.0-2 => 12.0.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-12 [source] (disco-proposed) [12.0.0-3]
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (disco-proposed/universe) [2.0.4-1 => 2.0.5-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [amd64] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [armhf] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [ppc64el] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [arm64] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [s390x] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [i386] (disco-proposed) [8.0.0+git20190314-0ubuntu1]
<acheronuk> handsome_feng: without that ukui-greeter fix, your beta iso will be useless?
<handsome_feng> acheronuk: Yes... :(
<acheronuk> vorlon apw infinity ^^
<acheronuk> Other release team are away I think?
<willcooke> heh, I was just going to say that.  Thanks for picking it up acheronuk
<handsome_feng> acheronuk, willcooke : Thank you all!
-queuebot:#ubuntu-release- Unapproved: gdcm (disco-proposed/universe) [2.8.8-7ubuntu1 => 2.8.8-9ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (disco-proposed/main) [2.5.3-4ubuntu1 => 2.5.5-1ubuntu1] (ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> yay!!! ruby CVE fixes ^^
-queuebot:#ubuntu-release- Unapproved: cups-filters (disco-proposed/main) [1.22.2-1 => 1.22.3-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (disco-proposed/main) [11.0.3+4-1ubuntu2 => 11.0.3+4-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (disco-proposed) [11.0.3+4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ant (disco-proposed/universe) [1.10.5-2ubuntu1 => 1.10.5-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ant [source] (disco-proposed) [1.10.5-3]
<jdstrand> hi! apparmor was granted it's FFe by infi nity a couple days ago. after some iterations on its new-in-Ubuntu, Debian-introduced autopkgtests, it is now migratable
<jdstrand> it isn't migrating due to "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<doko> afaik it's beta release today
<jdstrand> I was gonna say I thought I remembered that
<doko> jdstrand: did you see the firewalld autopkg test regressions?
<jdstrand> doko: yes and I filed a bug for the desktop team: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1821596
<ubot5`> Ubuntu bug 1821596 in firewalld (Ubuntu) "firewalld ipset autopkgtest failures" [High,Confirmed]
<jdstrand> basically it failed for two reasons: 1.8.2 iptables and it needs newer ipset
<doko> ahh, ok
<jdstrand> I did the updates to firewalld so it didn't require iptables, but knew that it would still fail for ipset. seb128 already was working on the ipset bits, so handed back off to him
<jdstrand> (didn't require iptables 1.8*)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Beta] has been marked as ready
<acheronuk> handsome_feng: by the way, "fix committed" in a bug usually means it's been uploaded to the archive but not migrate to release pocket yet. So probably not good to set that status until its really done, as at a glance people will just assume it doesn't need sponsoring any more
<handsome_feng> acheronuk: Thanks, I will change the status now
<handsome_feng> Oh, acheronuk has done that, Thanks acheronuk!
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: gigolo (disco-proposed/universe) [0.4.90-1 => 0.4.91-0ubuntu1] (ubuntustudio, xubuntu)
<bluesabre> I didn't see the all flavors beta release note anywhere, but here's the Xubuntu release note in case I'm not around later today: https://wiki.xubuntu.org/releases/19.04/release-notes
-queuebot:#ubuntu-release- Unapproved: ant (cosmic-proposed/universe) [1.10.5-2ubuntu1~18.10 => 1.10.5-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ant [sync] (cosmic-proposed) [1.10.5-3~18.04]
-queuebot:#ubuntu-release- Unapproved: ukui-biometric-auth (disco-proposed/universe) [1.0.2-1 => 1.0.3-2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- New source: intel-opencl-clang (disco-proposed/primary) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (disco-proposed/main) [26ubuntu1 => 27ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (disco-proposed/universe) [19ubuntu1 => 20ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (disco-proposed) [20ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (disco-proposed) [27ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-intervaltree-bio (disco-proposed/universe) [1.0.1-3 => 1.0.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-intervaltree-bio [source] (disco-proposed) [1.0.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11.0.2+9-3ubuntu1~18.10.1 => 11.0.2+9-3ubuntu1~18.10.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.16-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (cosmic-proposed) [11.0.2+9-3ubuntu1~18.10.2]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [11.0.2+9-3ubuntu1~18.04.1 => 11.0.2+9-3ubuntu1~18.04.2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: hovercraft (disco-proposed/universe) [2.6-2 => 2.6-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hovercraft [source] (disco-proposed) [2.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-10 [source] (bionic-proposed) [10.7-0ubuntu0.18.04.1]
<rbasak> ^ I'm just working through postgresql MREs that I didn't finish on my shift yesterday
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-10 [source] (cosmic-proposed) [10.7-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.0-1ubuntu1 => 19.0.1-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: boost1.67 (cosmic-proposed/main) [1.67.0-7 => 1.67.0-7ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted boost1.67 [source] (cosmic-proposed) [1.67.0-7ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: node-external-editor (disco-proposed/universe) [2.0.4+dfsg-1 => 2.0.4+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-opencv (disco-proposed/universe) [6.0.0+git20180416.cfc96ba0-2 => 6.0.0+git20180416.cfc96ba0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-jschardet (disco-proposed/universe) [1.6.0+dfsg-1 => 1.6.0+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-external-editor [sync] (disco-proposed) [2.0.4+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-opencv [sync] (disco-proposed) [6.0.0+git20180416.cfc96ba0-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-jschardet [sync] (disco-proposed) [1.6.0+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: libdatetime-timezone-perl (disco-proposed/universe) [1:2.23-1+2018i => 1:2.23-1+2019a] (kubuntu, mythbuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-carrierwave (disco-proposed/universe) [1.3.1-1 => 1.3.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-colorator (disco-proposed/universe) [1.1.0-1 => 1.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-classifier (disco-proposed/universe) [1.3.4-2 => 1.3.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-carrierwave [sync] (disco-proposed) [1.3.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-colorator [sync] (disco-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: ruby-doorkeeper-openid-connect (disco-proposed/universe) [1.5.2-1 => 1.5.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-classifier [sync] (disco-proposed) [1.3.4-3]
-queuebot:#ubuntu-release- Unapproved: ruby-coveralls (disco-proposed/universe) [0.8.22-1 => 0.8.22-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-globalid (disco-proposed/universe) [0.3.6-2 => 0.4.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (disco-proposed/universe) [2.1.1-2 => 2.1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-model-tokenizer (disco-proposed/universe) [1.0.1-1 => 1.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-version-sorter (disco-proposed/universe) [2.1.0+dfsg-1build2 => 2.2.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-coveralls [sync] (disco-proposed) [0.8.22-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-globalid [sync] (disco-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-openssl [sync] (disco-proposed) [2.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-doorkeeper-openid-connect [sync] (disco-proposed) [1.5.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-version-sorter [sync] (disco-proposed) [2.2.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-model-tokenizer [sync] (disco-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.2+13-1ubuntu0.18.04.4 => 11.0.2+9-3ubuntu1~18.04.2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.2]
<infinity> handsome_feng: Why were you looking for a release team member to sponsor your package?  Literally any MOTU can upload that package. :/
<handsome_feng> emm, because it is beta freeze? and I need the package to get into the archive before beta release
<infinity> handsome_feng: If you found a sponsor last night, then asked the release team for an FFe to let it in, it would have gone faster. :)
<infinity> handsome_feng: Well, and it's bugfix-only, so no need for an FFe.
<infinity> handsome_feng: Anyhow, since no one else seemed to catch on to that detail and upload for you, I've just done so.
<infinity> handsome_feng: Hopefully, you'll be able to test a respin in a couple of hours?
-queuebot:#ubuntu-release- Unapproved: ukui-greeter (disco-proposed/universe) [1.1.7-2 => 1.1.8-0ubuntu1] (ubuntukylin)
<handsome_feng> infinity: Thank you so much, I will test it! even i am sleepy...
-queuebot:#ubuntu-release- Unapproved: accepted ukui-greeter [source] (disco-proposed) [1.1.8-0ubuntu1]
<infinity> handsome_feng: I'll respin for you when it migrates.
<handsome_feng> infinity: Thanks a looooooooot!
<Eickmeyer> Found a nasty little UX bug in Ubiquity for Studio. Not a complete show stopper, but definitely something I'd like to get fixed before final. (bug 1822134)
<ubot5`> bug 1822134 in Ubuntu Studio "Ubuntu Studio Installation - Black Text on Dark Gray" [High,Confirmed] https://launchpad.net/bugs/1822134
<infinity> Eickmeyer: You say bug, I say hard-mode installer.
<infinity> Eickmeyer: For the hardcore gamer in your life.
<Eickmeyer> infinity: HAHAHAHAHAHA!!!!
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Beta] has been marked as ready
<Eickmeyer> It's not impossible to use, just a little inconvenient for looking at the header & footer. ;)
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.6.3-0ubuntu1 => 1:3.6.3-0ubuntu1.1] (mozilla)
-queuebot:#ubuntu-release- Unapproved: mongodb (cosmic-proposed/universe) [1:3.6.3-0ubuntu1 => 1:3.6.3-0ubuntu2.1] (mozilla)
-queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.96-0ubuntu2 => 0.96-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.96-0ubuntu0.18.10.1 => 0.96-0ubuntu0.18.10.2] (core)
<handsome_feng> infinity: Can I request a rebuild now? I see ukui-greeter has migrated to release in https://launchpad.net/ubuntu/+source/ukui-greeter
<infinity> handsome_feng: Rebuild is already in progress.
<handsome_feng> oh, thanks!
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntukylin/+build/160475
<handsome_feng> Got it, :)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] has been updated (20190328)
<infinity> handsome_feng: ^
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (disco-proposed) [0.96-0ubuntu3]
<handsome_feng> \o/, I will download it now and then have a test
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (disco-proposed) [5.212.0~alpha2-21ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (disco-proposed) [1.1.1+bzr982-0ubuntu21]
-queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (disco-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.96-0ubuntu0.18.04.1 => 0.96-0ubuntu0.18.04.2] (core)
<bdmurray> LocutusOfBorg: which libunistring do you really want reviewed for cosmic?
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (bionic-proposed) [0.96-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (cosmic-proposed) [0.96-0ubuntu0.18.10.2]
-queuebot:#ubuntu-release- Unapproved: netplan.io (disco-proposed/main) [0.96-0ubuntu3 => 0.96-0ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.96-0ubuntu0.18.10.1 => 0.96-0ubuntu0.18.10.2] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.96-0ubuntu0.18.04.1 => 0.96-0ubuntu0.18.04.2] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Beta] has been marked as ready
<handsome_feng> infinity, acheronuk: Thank you all! and good night! :)
<acheronuk> infinity: yeah, I know I could have just put that kylin upload in the queue as a new MOTU, but am I being a bit cautious with the new permissions ;)
<acheronuk> <handsome_feng: I see you left the room, but for the log, you are welcome :)
<tsimonq2> acheronuk: msttcorefonts merge next? ;)
<Eickmeyer> acheronuk picked a heck of a week to become MOTU. XD
<valorie> ha!
<Eickmeyer> Question: is there a separate artwork freeze? If it's not too late (even after beta goes out), I'd like to add a wallpaper I made to ubuntustudio-look: http://ubuntustudio.org/wp-content/uploads/2019/03/1fe8/ubuntustudio_disco_dingo_1080.jpg
<tsimonq2> Eickmeyer: There is no such freeze.
<valorie> that is a rock 'em sock 'em wallpaper!
<tsimonq2> https://wiki.ubuntu.com/DiscoDingo/ReleaseSchedule
<Eickmeyer> tsimonq2: Does it fall under UI feeze then?
<tsimonq2> Nope.
<Eickmeyer> \o/
<tsimonq2> It falls under the same exception that has allowed flavors to push Ubiquity slideshows several days before release. :P
<Eickmeyer> When I get home, that's getting added to the ubuntustudio-look package as part of ubuntustudio-wallpaper
 * Eickmeyer should also update the Ubiquity slideshow
<tsimonq2> (Disclaimer: I'm not a member of the release team.)
<Eickmeyer> tsimonq2: Understood, but you've got your finger on the pulse.
<tsimonq2> heh
<Wimpress> infinity: Are you waiting on the Ubuntu Desktop testcases to be completed and the image marked ready?
<infinity> Wimpress: Also scratching my head over a source ISO generation issue, but mostly your thing, yes.
<Wimpress> infinity: I chatted with Will Cooke, he says the Ubuntu Desktop images can be marked ready.
<Wimpress> Kindly requests you mark them ready on his behalf.
<infinity> Wimpress: Mmkay.
<Wimpress> Thanks.
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Disco Beta] has been marked as ready
#ubuntu-release 2019-03-29
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.96-0ubuntu0.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.96-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Builds: 29 entries have been added, updated or disabled
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Cosmic 18.10, Disco Beta | Archive: FF, DIF | Disco Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (disco-proposed) [66.0.2+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (disco-proposed) [3.32.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [source] (disco-proposed) [2.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [sync] (disco-proposed) [1:3.32.0.1-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (disco-proposed) [0.96-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: tzdata (disco-proposed/main) [2018i-2 => 2019a-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (disco-proposed) [2019a-1]
-queuebot:#ubuntu-release- Unapproved: accepted gdcm [source] (disco-proposed) [2.8.8-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (disco-proposed) [1.22.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-biometric-auth [sync] (disco-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted libxmlb [sync] (disco-proposed) [0.1.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted gigolo [source] (disco-proposed) [0.4.91-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted progress-linux-metapackages [sync] (disco-proposed) [20190225-3]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [sync] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdatetime-timezone-perl [sync] (disco-proposed) [1:2.23-1+2019a]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [source] (disco-proposed) [2.5.5-1ubuntu1]
-queuebot:#ubuntu-release- New binary: progress-linux-metapackages [amd64] (disco-proposed/universe) [20190225-3] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [amd64] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [ppc64el] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [i386] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [s390x] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [arm64] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lwgeom [armhf] (disco-proposed/universe) [0.1-5+repack-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted progress-linux-metapackages [amd64] (disco-proposed) [20190225-3]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [arm64] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [i386] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [s390x] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [amd64] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [ppc64el] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lwgeom [armhf] (disco-proposed) [0.1-5+repack-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.5]
<LocutusOfBorg> bdmurray, latest is better :) the first one didn't have the removal of asneeded in rules file, I prefer to revert also that one
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati (disco-proposed/main) [1:19.0.0-1 => 1:19.0.1-0ubuntu1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: libdrm (disco-proposed/main) [2.4.97-1 => 2.4.97-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected libunistring [source] (cosmic-proposed) [0.9.10-1ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-settings [source] (cosmic-proposed) [4.13.4-1ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libidn [source] (cosmic-proposed) [1.33-2.2ubuntu1.1]
<LocutusOfBorg> tjaalton, ^^ please also do libunistring for cosmic if you can
<LocutusOfBorg> same patch same failure
<tjaalton> going through the queue..
<LocutusOfBorg> thanks!
<LocutusOfBorg> if you have questions please go on irc, not email if possible, so I can quickly address them
-queuebot:#ubuntu-release- Unapproved: accepted libidn [source] (bionic-proposed) [1.33-2.1ubuntu1.2]
<tjaalton> these were simple
<LocutusOfBorg> :D
-queuebot:#ubuntu-release- Unapproved: accepted libunistring [source] (cosmic-proposed) [0.9.10-1ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (cosmic-proposed) [1:3.6.3-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (bionic-proposed) [1:3.6.3-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted collectd [source] (bionic-proposed) [5.7.2-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-settings [source] (xenial-proposed) [4.12.0-2ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (xenial-proposed) [0.8.11-0ubuntu0.16.04.1]
<jdstrand> hello. aiui, the beta image is released. I'm looking at update_excuses and see that apparmor (and apparmor-profiles-extra) both pass everything. apparmor says Invalidated by dependency. then: Depends: apparmor perl (not considered). I looked at perl and it had two regressions: autopkgtest for perl/5.28.1-5: arm64 ppc64el
<jdstrand> so, I retried those. is anyone looking at perl 5.28.1-5?
<jdstrand> the failing tests were touched in 5.28.1-5 it seems: Include arch-specific data for NDBM and GDBM autopkgtests. (Closes: #923409)
<jdstrand> so this may be a bad test
<jdstrand> https://launchpad.net/ubuntu/+source/perl/5.28.1-5
<jdstrand> 5.28.1-5 came in 12 days ago. I'm not sure who requested the sync or is looking after it
<jdstrand> but it is entangling things in proposed
<jdstrand> hrmmm, seems others retried the tests too (vorlon, jbicha)...
<jdstrand> and they didn't pass
<cjwatson> you can see who requested the sync in the publishing history
<cjwatson> https://launchpad.net/ubuntu/+source/perl/+publishinghistory says vorlon
<jdstrand> ah vorlon
<cjwatson> and I've seen discussion about it in scrollback, so poke through logs
<jdstrand> I went to the Done queue and didn't see it :)
<cjwatson> 16:51 <infinity> LocutusOfBorg: We were intentionally not hinting perl, since a fixed upload should be on the way.
<cjwatson> 16:52 <infinity> LocutusOfBorg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925179
<ubot5`> Debian bug 925179 in perl "perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility" [Important,Open]
<cjwatson> jdstrand: ^- that
<jdstrand> ack, thanks
<jdstrand> seems like, yes, bad tests, but there is no -6 yet
<jdstrand> vorlon: what is your current thinking wrt perl's migration? ^
-queuebot:#ubuntu-release- Unapproved: libapache2-mod-auth-mellon (disco-proposed/main) [0.14.1-1 => 0.14.2-1] (ubuntu-server) (sync)
<mdeslaur> libapache2-mod-auth-mellon is a security update ^
-queuebot:#ubuntu-release- Unapproved: php7.2 (disco-proposed/main) [7.2.15-0ubuntu2 => 7.2.15-0ubuntu3] (ubuntu-desktop, ubuntu-server)
<infinity> jdstrand: -6 is being uploaded and synced tomorrow.
<infinity> Given that I have the Debian maintainer's assurance of that now, maybe I could badtest -5 to untangle other things.
<infinity> Didn't want to before, cause we very much don't want to ship with a non-green perl in the release pocket.
-queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu567 => 20101020ubuntu568] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (disco-proposed) [20101020ubuntu568]
-queuebot:#ubuntu-release- Unapproved: accepted php7.2 [source] (disco-proposed) [7.2.15-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-mellon [sync] (disco-proposed) [0.14.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (disco-proposed) [2.4.97-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati [source] (disco-proposed) [1:19.0.1-0ubuntu1]
<rbalint> could someone please review: https://code.launchpad.net/~rbalint/ubuntu-seeds/+git/ubuntu/+merge/365253
<vorlon> jdstrand: the Debian maintainer was supposed to be working on a fix for the autopkgtest regressions and I wasn't going to do extra work to beat him to it.  If it's not done by Monday, I think either xnox or I will pick it up
-queuebot:#ubuntu-release- Unapproved: kmod (disco-proposed/main) [25-1ubuntu2 => 25-1ubuntu3] (core)
<infinity> vorlon: See 10 lines up.
<infinity> tjaalton: See the last comment on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795857
<ubot5`> Ubuntu bug 1795857 in linux (Ubuntu) "enable CONFIG_DRM_BOCHS" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: rejected kmod [source] (disco-proposed) [25-1ubuntu3]
<rbalint> can i have a fairly late ffe, please? : LP: #1822341
<ubot5`> Launchpad bug 1822341 in ubuntu-meta (Ubuntu) "[FFE] Please add ubuntu-wsl binary package" [Undecided,New] https://launchpad.net/bugs/1822341
<tjaalton> infinity: cascardo tested it, aiui
<tjaalton> replied to the kernel patch on k-t
<cascardo> I will add to the bug as well
<tjaalton> thanks
<rbalint> autopkg keeps failing on a.u.c, but passes locally http://autopkgtest.ubuntu.com/packages/o/octave-interval/bionic/amd64
<rbalint> can i do something somthing with that?
<rbalint> tjaalton, or could you please let wslu sru-s to release as they can't be responsible?
<tjaalton> rbalint: no release on afriday ;)
<tjaalton> *a friday
<rbalint> tjaalton, ack :-(
<jdstrand> vorlon: ack, thanks. wfm
-queuebot:#ubuntu-release- Unapproved: libapache2-mod-auth-mellon (disco-proposed/main) [0.14.2-1 => 0.14.2-1ubuntu1] (ubuntu-server)
<Ukikie> Hello!  So there's a new bugfix release of a very minor package seeded in Xubuntu, it's a perl script but I want to get it in because it fixes deb822 sources parsing.  If it is 3 files changed, 145 insertions(+), 69 deletions(-), including manpage and changelog I don't really have any hope of getting this in, do I?
<infinity> Ukikie: If it's only bugfixes, go for it.  If it's featureful too, file an FFe.
-queuebot:#ubuntu-release- Unapproved: update-manager (disco-proposed/main) [1:19.04.3 => 1:19.04.4] (core)
#ubuntu-release 2019-03-30
<Ukikie> infinity: Cool, thanks!
-queuebot:#ubuntu-release- Unapproved: inxi (disco-proposed/universe) [3.0.32-1-1 => 3.0.33-1-0ubuntu1] (ubuntu-budgie, ubuntu-mate, ubuntustudio, xubuntu)
<Ukikie> ...Why are Budgie and MATE using this?
<Eickmeyer> Ukikie: I don't even know why it's in Ubuntu Studio. I guess because we have Pidgin installed by default?
<Ukikie> Why would Pidgin do it?  I figured Studio would have it as they tend to copy Xubuntu on some things anyway.
<Eickmeyer> Ukikie: Well, bad assumption. What IRC client is installed by default?
<Eickmeyer> Ukikie: Not your assumption, mine.
<Ukikie> Xubuntu doesn't really have one by default, we dropped xchat and never added hexchat.
<Ukikie> Specifically, opted not to.
<Eickmeyer> Our chat redirects go to the webchat. So, I'm trying to figure out how inxi is even in a seed if that's the case.
<Ukikie> I'm guessing your seed lists it?
<krytarik> Eickmeyer: Inxi != Irssi >_>
<Eickmeyer> Ahhhh...
<Ukikie> http://people.canonical.com/~ubuntu-archive/seeds/ubuntustudio.disco/desktop
<Eickmeyer> Ukikie: I see it. Still think it's odd.
<Ukikie> ...I mean, you guys added it, don't look at me with those funky eyes. :>
<Eickmeyer> It's in Xubuntu's seed too.
<valorie> it's tiny!
<valorie> and useful
 * valorie dl'd and installed it
<valorie> I wouldn't touch irssi with a 10-foot pole though
<valorie> <3 Konversation
<Eickmeyer> I'm a Quassel guy myself, but you already knew that.
<krytarik> At least.. oh there it is. >_>
<Ukikie> quassel-data recommends/suggests it.
<Ukikie> valorie: inxi -r is a great tool to look at your enabled repos, only one I know that has deb822 support.
<valorie> it's a nice tool sometimes when helping users too
<valorie> even if they don't have it installed, it takes only a moment to do so
<valorie> as long as the box in question is online
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-look (disco-proposed/universe) [0.58 => 0.59] (ubuntustudio)
<Eickmeyer> infinity: ^ Just a wallpaper I made and got a lot of great feedback.
-queuebot:#ubuntu-release- Unapproved: materia-gtk-theme (disco-proposed/universe) [20190201-1 => 20190201-1ubuntu1] (ubuntustudio)
#ubuntu-release 2019-03-31
-queuebot:#ubuntu-release- Unapproved: elementary-xfce (disco-proposed/universe) [0.13.1-1 => 0.13.1-1ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: flatpak (disco-proposed/universe) [1.2.3-1 => 1.2.4-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (disco-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- Unapproved: shibboleth-sp (disco-proposed/universe) [3.0.3+dfsg1-1 => 3.0.4+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shibboleth-sp [sync] (disco-proposed) [3.0.4+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: kylin-greeter (disco-proposed/universe) [18.04.2 => 19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kylin-greeter [source] (disco-proposed) [19.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (disco-proposed/universe) [18.10.1 => 19.04.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-icon-theme (disco-proposed/universe) [0.19 => 0.20] (ubuntustudio)
<Eickmeyer> ^ Just to facilitate a dark theme of our icons.
-queuebot:#ubuntu-release- Unapproved: perl (disco-proposed/main) [5.28.1-5 => 5.28.1-6] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted perl [sync] (disco-proposed) [5.28.1-6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (disco-proposed) [19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-icon-theme [source] (disco-proposed) [0.20]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-look [source] (disco-proposed) [0.59]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (disco-proposed) [1:19.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted elementary-xfce [source] (disco-proposed) [0.13.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted materia-gtk-theme [source] (disco-proposed) [20190201-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-mellon [source] (disco-proposed) [0.14.2-1ubuntu1]
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (disco-proposed/universe) [19.04.0] (ubuntukylin)
#ubuntu-release 2020-03-23
<cpaelzer> migth I ask a SRU team member for https://code.launchpad.net/~paelzer/britney/hints-ubuntu-xenial-pg-update-march-2020/+merge/380811
<cpaelzer> that is the only one holding back a xenial update for postgres
<cpaelzer> well it might hold up more than that, but of that I know
<LocutusOfBorg> hello seb128 libhandy sync?
<seb128> LocutusOfBorg, hey, feel free if you want?
<LocutusOfBorg> ack! I wanted to check the diff with you before
<LocutusOfBorg> I see your changes merged differently in debian
<LocutusOfBorg> lets see if autopkgtests are green
 * Laney eyes icu and eveything a bit
<jamespage> please can the ceph 14.2.7 updates in eoan UNAPPROVED be rejected - 14.2.8 has been out a while now so not worth putting users through two sets of updates
<rbalint> Laney, could you please eye LP: #1868500, too for systemd? :-)
<ubot5> Launchpad bug 1868500 in golang-github-prometheus-client-golang (Ubuntu) "Please remove binaries for 0.9.2-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1868500
<Laney> rbalint: would love to, but not in ubuntu-archive
<Laney> :'(!
<rbalint> ah, my bad, doko then?
<sil2100> jamespage: done
<sil2100> rbalint: I guess I could take a look
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (eoan-proposed) [14.2.7-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (eoan-proposed) [14.2.7-0ubuntu0.19.10.1]
<jamespage> sil2100: ta
<rbalint> sil2100, thanks, please!
<Laney> why does this node-chokidar test work when I run it manually but not when it's triggered by the worker :(
<Laney> even from the same machine
<sil2100> rbalint: commented on the bug with a question, if you could take a look
<rbalint> sil2100, thanks, checking
<ahasenack> hi release team, I'd like to update bind9 to 9.16.1 (from 9.16.0), here is the FFe bug with details on what changed: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1868272
<ubot5> Ubuntu bug 1868272 in bind9 (Ubuntu) "FFe: bind9 9.16.1 update" [Undecided,New]
<coreycb> hello release team, I'd like to upload python-decorator 4.4.2 (currently 4.3.0). it's mostly bug fixes with one slight new feature that is backward-compatible. here's the delta of commits: https://paste.ubuntu.com/p/nkGmDRxjkF/  -- the new version is needed by new versions of python-openstacksdk
<stgraber> can an ubuntu-release team member look at https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1867541 please?
<ubot5> Ubuntu bug 1867541 in lxcfs (Ubuntu) "[FFe] LXCFS 4.0 LTS" [Undecided,New]
-queuebot:#ubuntu-release- New source: pydrive (focal-proposed/primary) [1.3.1-0ubuntu1]
<rbalint> Laney, could you please check the systemd hint review again?
-queuebot:#ubuntu-release- New binary: libinih [amd64] (focal-proposed/universe) [48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinih [s390x] (focal-proposed/universe) [48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinih [ppc64el] (focal-proposed/universe) [48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinih [arm64] (focal-proposed/universe) [48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinih [armhf] (focal-proposed/universe) [48-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libinih [amd64] (focal-proposed) [48-1]
-queuebot:#ubuntu-release- New: accepted libinih [armhf] (focal-proposed) [48-1]
-queuebot:#ubuntu-release- New: accepted libinih [s390x] (focal-proposed) [48-1]
-queuebot:#ubuntu-release- New: accepted libinih [arm64] (focal-proposed) [48-1]
-queuebot:#ubuntu-release- New: accepted libinih [ppc64el] (focal-proposed) [48-1]
<mfo> sil2100, hey Lukasz.  If you still have a chance (sorry, I see it's almost 5PM there) the util-linux SRU for bionic has a autopkgtest regression failure on mysql-5.7 that's unrelated to the upload (confirmed by running w/ the version in the updates pocket), so if it's at all possible to release it based on that info, or maybe later this week, that would be nice :)  thanks!
<sil2100> mfo: hey! I have a few meetings right now, but I'll look into that once I'm done with those ;)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/main) [1.0.0-0ubuntu4~18.04.3 => 1.0.0-0ubuntu4~18.04.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (eoan-proposed/main) [1.0.0-0ubuntu7 => 1.0.0-0ubuntu7.1] (no packageset)
<rbalint> sil2100, could you please take a look at these, too? ^
<Eickmeyer> Hello all. I have a bug 1868280 opened, and teward and I would like some clarification since there seems to be some disagreement from other flavor leads about whether or not a simple theme update even needs a UIFe/FFe since it doesn't contain significant color changes.
<ubot5> bug 1868280 in materia-gtk-theme (Ubuntu) "[FFe] [UIFe] Please update materia-gtk-theme to 20200320 (latest release)" [Undecided,New] https://launchpad.net/bugs/1868280
<mfo> sil2100, ack, thanks!
<Eickmeyer> So, if we can get that one question answered, whether or not we even need that FFe/UIFe bug, then that would be nice. It'd be something we can simply take off of the release team's plate.
<teward> Laney: sil2100: ^ re: materia-gtk-theme if one of you gets a minute
<teward> (you were both around recently, hence the ping)
<dannf> does enabling the build of a new utility from a source package require an FFe (adds lib deps)? i filed one at LP: #1868174 in case it does
<ubot5> Launchpad bug 1868174 in mstflint (Ubuntu) "[FFe] mstflint: enable mstreg command" [Undecided,New] https://launchpad.net/bugs/1868174
-queuebot:#ubuntu-release- New binary: ceph [amd64] (focal-proposed/main) [15.1.1-0ubuntu1] (desktop-core, ubuntu-server)
<sil2100> Eickmeyer, teward: I'll try looking into that today or tomorrow straight in the morning o/
<Eickmeyer> sil2100: The question is even if the FFe/UIFe bug is even necessary. There seem to be some disagreements.
<ahasenack> hi release team, python-geoip2 mir is done (https://people.canonical.com/~ubuntu-archive/component-mismatches.html), task is marked "in progress" but there is nothing else to do on my side
<ahasenack> vorlon`: that was part of that seed change
<ahasenack> "that seed change" = https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/380547
<Laney> Eickmeyer: If you have a documentation team then you should consult with them. Otherwise, don't bother imho
<Laney> rbalint: Sorry, missed your message, will try to look if possible today
<Eickmeyer> Laney: Yeah, there's no documentation changes whatsoever on that one.
<Eickmeyer> teward: ^
<teward> ack
<teward> Laney: so JFDI then?
<Laney> Eickmeyer: It doesn't mean 'there is no documentation in the change'.
<Laney> It means that the change doesn't affect the documentation, i.e. if there are screenshots then they would be broken.
<Eickmeyer> Laney: No screenshots are broken by this change.
<Laney> You don't have to answer me on this change, I'm giving you the toolbox to answer for yourself. :-)
<Eickmeyer> Ok, cool.
<Eickmeyer> This does remind me, though, that I need to start working on release notes. ;P
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (eoan-proposed) [1.0.0-0ubuntu7.1]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.4]
<Eickmeyer> Laney: so, to reiterate teward's question: JFDI?
<Laney> You can do if you decide it doesn't need an exception
<Eickmeyer> Laney: Thanks.
<teward> Laney: we JFDI and uploaded, it's been accepted and is being processed.
<teward> thanks for peeking at it :)
<teward> OH I need to bother you on other things too :P)
<teward> but that can wait until post-release
<ahasenack> hi release team, I'd like to update bind9 to 9.16.1 (from 9.16.0), here is the FFe bug with details on what changed: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1868272
<ubot5> Ubuntu bug 1868272 in bind9 (Ubuntu) "FFe: bind9 9.16.1 update" [Undecided,New]
<ahasenack> sil2100: ^ if you can
<cpaelzer> an SRU member around to consider merging https://code.launchpad.net/~paelzer/britney/hints-ubuntu-xenial-pg-update-march-2020/+merge/380811 ?
<ahasenack> stgraber: could you perhaps please take a look at the bind9 ffe above?
<stgraber> ahasenack: yeah, will take a look. You don't have anyone on the server team who's on the release team do you? I'd have some FFEs to trade :)
<ahasenack> hah, there's a thought
<ahasenack> what are the requisites?
<ahasenack> we have MIR, SRU
<ahasenack> not release
<bryce> stgraber, josh mentioned you were available to help with removing php-horde-*?  https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1868281  Steve made good progress Friday but it's a long list of packages.
<ubot5> Ubuntu bug 1868281 in php-horde (Ubuntu) "Please remove php-horde and php-horde-* from focal" [Undecided,New]
<bryce> stgraber, I am trying to rework my list to just the php-horde items needed to unblock php-defaults, but the whole php-horde-* stack will need to go eventually
<stgraber> ahasenack: granted
<ahasenack> stgraber: as is, without reverting upstream's decision on those pthread locks?
<ahasenack> fwiw debian took the same route
<stgraber> ahasenack: right, focal has the needed glibc bits, so no need to undo upstream's change
<ahasenack> cool, thanks
<stgraber> and I'm not super fond of random userspace having their own implementation of bits like that :)
<ahasenack> that's so true
<ahasenack> I watched a bind9 presentation the other day, where they were talking about this development cycle
<ahasenack> and "code cruft"
<ahasenack> they had many things implemented by themselves, because early OSs didn't have the features they needed
<ahasenack> think, I don't know, vax/vms
<ahasenack> old solaris, that kind of stuff
<ahasenack> and they took this 9.16 cycle to start to get rid of that
<stgraber> bryce: if you can comment with the list of packages that still need to go away, that'd be helpful
<bryce> stgraber, ok will do
<bryce> stgraber, I've posted the updated dependency tree of all php-horde-* packages.
<bryce> stgraber, I'm working on identifying the specific priorities to remove, that should let php-defaults migrate, but the dependency tree is a bit tricky.
<mwhudson> uh should our autopkgtest infra set all of http_proxy, HTTP_PROXY, no_proxy, NO_PROXY etc etc
<stgraber> bryce: that's a lot of packages :)
<bryce> stgraber, indeed :-/
<bryce> like I said, I'm working on making a narrower list but the dependency network is pretty thick
<bryce> stgraber, also I think there might be a bit of circular dependency with php-horde itself
<stgraber> bryce: since the goal is to remove php-horde and php-horde-* I'm currently checking whether there are any rdepends or r-build-depends outside of that set
<stgraber> bryce: if not, I'd just nuke the entire set
<bryce> stgraber, that would be great
<bryce> I haven't spotted anything outside this set
<stgraber> what we don't want is to cause breakage outside of php-horde* but if there's nothing outside of those that rdepends or build-depends on it, then it should be fine
<bryce> right
<stgraber> just running a loop of reverse-depends and reverse-depends -b to make sure
<stgraber> yeah, nothing outside of that set is going to break
<stgraber> bryce: and you've confirmed that this is all the php-horde-* packages?
<bryce> stgraber, correct
<stgraber> bryce: all in the release pocket or are there some that need nuking from proposed too?
<bryce> stgraber, I believe php-horde-* only has stuff in released, but I wouldn't swear by it.
<bryce> looking...
<stgraber> nuking from release pocket now
<bryce> php-horde-image is in proposed
<stgraber> ah, will need to do a special run for that one then
<bryce> also php-horde-icalendar
<bryce> those two are only ones I'm spotting on update_excuses.html
<stgraber> yeah, the package index agrees with that
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [source] (bionic-proposed) [0.175~18.04.1]
<bryce> stgraber, thanks :-)
<stgraber> np, I just hope I didn't break anything :) getting a bit rusty
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1017.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1017.18~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1077.87] (kernel)
#ubuntu-release 2020-03-24
<teward> anyone on the archive team alive at the moment?  need to check that a NEW package for Studio this late in the cycle will still get reviewed in a timely manner
<Eickmeyer> ^ namely within the next week due to beta freeze.
<Eickmeyer> No FFe needed, it's not going in a seed.
<stgraber> depends on the complexity of the package I guess
<stgraber> there are only 3 packages in the queue right now, so it's not like there's a huge backlog
<stgraber> but the same folks reviewing those also tend to be handling a lot of other things for Ubuntu
<Eickmeyer> stgraber: It's a set of 4 audio reverb plugins that are in the form of standalone app, vst plugins, and lv2 plugins.
<Eickmeyer> Not too complex, I'd hope. Only took me a day to package.
<teward> stgraber: i'm about to upload it after I verify Eickmeyer hasn't botched the copyright again
<teward> but if that checks out it just needs ack'ed from NEW and binNEW
<teward> stgraber: you can relax for right now though
<teward> Eickmeyer still has some work to do :P
<Eickmeyer> oof
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-3 => 1.3.9-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-3 => 1.3.9-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-3 => 1.3.9-3] (core)
-queuebot:#ubuntu-release- New source: dragonfly-reverb (focal-proposed/primary) [3.0.0-0ubuntu1]
<teward> stgraber: ^ in case you get bored :P
<teward> otherwise it can sit for anyone.  Not seeded so probably can sit in Universe.
<teward> (at least, not seeded this cycle)
<RAOF> teward: You can prod me on Thursday if no-one's got to it yet.
-queuebot:#ubuntu-release- New binary: weston [s390x] (focal-proposed/universe) [8.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [ppc64el] (focal-proposed/universe) [8.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [amd64] (focal-proposed/universe) [8.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [arm64] (focal-proposed/universe) [8.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [armhf] (focal-proposed/universe) [8.0.0-1] (xorg)
<seb128> hey there, could someone review https://code.launchpad.net/~seb128/britney/update-libgphoto-version/+merge/381091
<seb128> (I just resubmitted the one which was waiting for some days with the right target vcs, would be nice if launchpad was getting the default right)
-queuebot:#ubuntu-release- New: accepted weston [amd64] (focal-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [armhf] (focal-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [s390x] (focal-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [arm64] (focal-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [ppc64el] (focal-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1017.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1077.87]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1017.18]
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [ppc64el] (focal-proposed/universe) [1.185ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [arm64] (focal-proposed/universe) [1.185ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted ceph [amd64] (focal-proposed) [15.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (focal-proposed/universe) [1.185ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [i386] (focal-proposed/universe) [1.185ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (focal-proposed) [1.185ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (focal-proposed) [1.185ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [arm64] (focal-proposed) [1.185ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [ppc64el] (focal-proposed) [1.185ubuntu2]
<rbalint> Laney, could you please revisit https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/381008 ?
<Laney> ok
<rbalint> Laney, i can take a straight no, then I cherry-pick the fix and push systemd throught autopkgtest again
<Laney> rbalint: what's that additional hint? not much explanation on it :(
<Laney> rbalint: can you prep that additional upload in a silo anyway?
<rbalint> Laney, it is not worth the cycles
<rbalint> Laney, i don't like binary copies to the archive because it is harder toverify them
<rbalint> Laney, prometheus-alertmanager is broken in the archive
<Laney> well you get the confidence of knowing the tests work
<rbalint> Laney, i've already tested the fix locally and also accepted upstream
<Laney> ok, let's go for the cherry-pick then if you prefer that way
<Laney> I can merge prometheus-alertmanager
<Laney> 's hint (not the package!)
 * Laney checks it fails in release alone
<rbalint> Laney,no i prefer the green light for systemd as it is and landing the cherry-pick with other fixes
<rbalint> Laney, because is one more day of testing in release pocket
<Laney> ok, how about this then as a compromise
<Laney> you prep the upload and have it ready to dput
<Laney> I'll merge your hint, then as soon as it migrates you upload the next thing
<rbalint> Laney, that's ok
<rbalint> Laney, thanks
<Laney> and on that next one you get no hinting >:)
<Laney> (for armhf)
<rbalint> sure
<Laney> ok, lemme know when you're good
<rbalint> Laney, i've it ready but netplan.io needs a rerun because it is not badtested anymore, i've just triggered the tests
<rbalint> Laney, i have the upload in ppa:rbalint/scratch2 , it seems we can wait to get a confirmation for armhf
<Laney> apw: sil2100: fancy giving thoughts on https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/381098 ?
<Laney> hope is that it makes fetching results a little bit faster ...
<sil2100> Laney: oh
<sil2100> Let me look in a moment
<Laney> merci!
<Laney> I'm not very fluent in httplib2 though, so comments genuinely welcome
<Laney> probably would have used urllib3 or requests but neither are installed on snakefruit and this is so
<cjwatson> python-requests is but not python3-requests
<cjwatson> We should really get python3-requests installed on snakefruit
<Laney> I've not got a huge problem with asking, just went with what was there :-)
<Laney> if it's a strong enough recommendation to prefer using that then I could request requests
<cjwatson> I definitely prefer requests where at all possible, but maybe that's just me
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1036.38] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1076.81] (kernel)
<LocutusOfBorg> Laney, https://bileto.ubuntu.com/#/ticket/3989 :)
<LocutusOfBorg> it might be good
<Laney> LocutusOfBorg: looks like doko has synced it already anyway ...
<Laney> doko: we had a ffe underway for unicode-data :(
<doko> ugh, I just saw the unresolvable build dependencies
<LocutusOfBorg> no problem, I can no-change rebuild and publish?
<Laney> sure
<LocutusOfBorg> thanks
<kanashiro> if someone can take a look I have a removal request here for src:ruby-concurrent-ext : https://bugs.launchpad.net/ubuntu/+source/ruby-concurrent-ext/+bug/1868729
<ubot5> Ubuntu bug 1868729 in ruby-concurrent-ext (Ubuntu) "[RM] Removal request of ruby-concurrent-ext/1.0.5-1build2 from Focal" [Undecided,New]
<kanashiro> ubuntu-archive ^
<doko> looking ...
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1036.38]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1076.81]
<Laney> I got IS to install requests, so I'll change that MP to use that
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-3]
-queuebot:#ubuntu-release- New: accepted pydrive [source] (focal-proposed) [1.3.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: pydrive [amd64] (focal-proposed/universe) [1.3.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: evolution (bionic-proposed/universe) [3.28.5-0ubuntu0.18.04.1 => 3.28.5-0ubuntu0.18.04.2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (eoan-proposed) [5.4.0-0ubuntu5.2]
-queuebot:#ubuntu-release- Unapproved: accepted sip4 [source] (bionic-proposed) [4.19.7+dfsg-1ubuntu0.1]
<rbalint> Laney, systemd/armhf passed in the silo, please merge the hints
-queuebot:#ubuntu-release- Unapproved: accepted sip4 [source] (xenial-proposed) [4.17+dfsg-1ubuntu0.1]
<rbalint> Laney, i'll upload the next update right after it migrates, but at the moment current one waits for netplan.io/arm64 to finish
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted vala [source] (bionic-proposed) [0.40.19-0ubuntu1]
<Laney> oh, oops, I didn't notice that it failed to push, thanks sil2100!
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [214.1-1~ubuntu19.04.1 => 215-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [214.1-1~ubuntu19.10.1 => 215-1~ubuntu19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [215-1~ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [214.1-1~ubuntu18.04.1 => 215-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [215-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [215-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: landscape-client (eoan-proposed/main) [18.01-0ubuntu9.2 => 18.01-0ubuntu9.3] (ubuntu-server)
-queuebot:#ubuntu-release- Packageset: Removed geoip from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libnetaddr-ip-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libsocket6-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed linux-5.4 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed mozjs60 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ruby2.5 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libipc-run3-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added nv-codec-headers to i386-whitelist in focal
<doko> something/someone is continuously giving back the gnutls28 3.6.11.1-2ubuntu3 build on all archs. any ideay why?
<doko> sforshee: reopened 1864992, still seen in autopkg tests
<sforshee> doko: it's still not a kernel issue
<sforshee> it's a depmod issue
<doko> should a tasked added for depmod?
<sforshee> depmod is from kmod, which is what the bug is targeted at
<sforshee> oh it's literally a symlink to /bin/kmod
<doko> ok, trying to merge kmod to suppress that warning
<ahasenack> hi release team , I have another Ffe for you, to enable the libfido2 and libcbor MIRs which will unblock openssh from migration, and we will have an openssh with U2F support in focal: https://bugs.launchpad.net/ubuntu/+source/libcbor/+bug/1868609
<ubot5> Ubuntu bug 1868609 in libcbor (Ubuntu) "FFe: update to 0.6.0 (MIR requirement)" [Undecided,New]
<ahasenack> stgraber: if you can^ I think at this time it's only you around, or tomorrow sil2100
<RikMills> vorlon: are you about? hope things are ok
<RikMills> cjwatson: would you maybe have time to review kpeoplevcard in NEW?
<RikMills> I have asked Andrew, but fear he may not have time, which is understandable
<powersj> RikMills, I believe vorlon to be out this week
<RikMills> powersj: ok, thanks
<RikMills> any AA then :)
<RikMills> as we are living in 'interesting times' I am not taking anything as read
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-20.24] (core, kernel)
<sarnold> hello release team, it appears that debian is going to have some rust package churn, I thought this may be useful to know about before it happens https://paste.ubuntu.com/p/bBBjjFpSJd/
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-20.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-20.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-20.24] (core, kernel)
<cjwatson> RikMills: Not at the moment, sorry
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-20.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-20.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-20.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-20.24]
#ubuntu-release 2020-03-25
-queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [1.3.3-0ubuntu1~18.04.1 => 1.3.3-0ubuntu1~18.04.2] (no packageset)
<LocutusOfBorg> apw, hello, can you please trigger the forget past passes hint for camitk? it is NBS everywhere except amd64 autopkgtest for camitk/4.1.2-4build1: amd64: Pass, arm64: Regression â» , armhf: Regression â» , i386: Regression â» , ppc64el: Regression â» , s390x: Regression â»
<LocutusOfBorg> # libinsighttoolkit4 is only supported on amd64 now, this triggers
<LocutusOfBorg> # dependencies on other architectures to remainin DEPWAIT.  Hint
<LocutusOfBorg> # tests as needed.
<LocutusOfBorg> force-badtest camitk/4.1.2-4/arm64 camitk/4.1.2-4/armhf camitk/4.1.2-4/i386 camitk/4.1.2-4/ppc64el camitk/4.1.2-4/s390x
<LocutusOfBorg> this can then be removed
-queuebot:#ubuntu-release- New: accepted pydrive [amd64] (focal-proposed) [1.3.1-0ubuntu1]
<Laney> sil2100: gonna try the requests thing I think
<Laney> sorry if proposed-migration dies a bit :-)
<Laney> (done)
<Laney> seems to be working
-queuebot:#ubuntu-release- New binary: clevis [amd64] (focal-proposed/universe) [12-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted clevis [amd64] (focal-proposed) [12-1ubuntu1]
<sil2100> First focal language packs building o/
<sil2100> (will have to re-upload the ckb ones, since they were missing from the packageset again
<sil2100> )
-queuebot:#ubuntu-release- Packageset: Added language-pack-ckb to langpack in focal
-queuebot:#ubuntu-release- Packageset: Added language-pack-ckb-base to langpack in focal
-queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-ckb to langpack in focal
-queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-ckb-base to langpack in focal
-queuebot:#ubuntu-release- Unapproved: ceph (eoan-proposed/main) [14.2.4-0ubuntu0.19.10.2 => 14.2.8-0ubuntu0.19.10.1] (desktop-core, ubuntu-server)
<Eickmeyer> xnox: Who tagged ubuntustudio-installer with bug 1851346?
<ubot5> bug 1851346 in ubuntustudio-live (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<sforshee> doko: ping on bug 1866882, this is still causing linux autopkgtest failures on s390
<ubot5> bug 1866882 in llvm-toolchain-10 (Ubuntu) "segfault in libllvm-10 when building kernel bpf selftests on s390" [High,Confirmed] https://launchpad.net/bugs/1866882
<doko> sforshee: please use LLVM on s390x for now
<sforshee> doko: do you mean llvm-9?
<xnox> Eickmeyer:  i meant ubuntustudio-live => because i believe the bug might be in the extra studio plugin, rather than in ubiquity itself
<Eickmeyer> xnox: Well, maybe, but that plugin is part of ubiquity, is it not?
<xnox> Eickmeyer:  no, it is shipped by ubuntustudio-live source code, not in the ubiquity source code.
<xnox> from ubiquity's point of view it is a 3rd-party plugin which it loads and uses, but has no control if it is working correctly with new ubiquity or is buggy =)
<Eickmeyer> xnox: Well, it was working properly up to 19.10, and we had no idea we even had control over that.
<Eickmeyer> Basically, what's happening is the mechanism I described in the bug report.
<doko> sforshee: yes
<Eickmeyer> stgraber: Can I enlist your help? Your name is all over the code of https://launchpad.net/ubuntustudio-live, and I have no idea what I'm doing. RE: bug 1851346
<ubot5> bug 1851346 in ubuntustudio-live (Ubuntu Focal) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346
<juliank> Eickmeyer: i have that bug in my committed lane fwiw
<juliank> Eickmeyer: need to figure out if that's a side effect from the autoremove changes in ubiquity or not
<Eickmeyer> juliank: xnox seems to think it's the plugin's fault, so he put the ball in our court. Feels like a "this is not our problem" issue.
<juliank> Eickmeyer: I'd expect this to like not happen anymore, but not produce a useful result either (that is, ubiquity now removes autoremovable packages at end of install, so they should not be autoremovable after reboot)
<juliank> Eickmeyer: maybe don't do a blanket single commit import from bzr, and import it properly?
<juliank> Eickmeyer: so that commit history is preserved?
<Eickmeyer> juliank: I tried....
<Eickmeyer> It failed.
<juliank> Eickmeyer: maybe rbalint can help, he likes converting bzr to git repos
<Eickmeyer> Got a ton of python errors from it.
<juliank> :D
<Eickmeyer> I mean, if someone wants to do a --force on it, be my guest. (rbalint, if you're reading this).
<teward> #bzr-is-pain, convince me otherwise :P
<Eickmeyer> ^ Agreed. Change my mind.
<rbalint> Eickmeyer, hi :-)
<Eickmeyer> rbalint: Hey there!
<rbalint> Eickmeyer, which repo are we talking about ?
<Eickmeyer> https://launchpad.net/ubuntustudio-live
<rbalint> https://wiki.ubuntu.com/UbuntuDevelopment/MigratingFromBzrToGit
<rbalint> Eickmeyer, let me check it
<Eickmeyer> I hate how that ^ didn't come up in a Google search.
<xnox> Eickmeyer:  not quite, it is not trianged
<rbalint> Eickmeyer, maybe i'm not good at SEO :o)
<xnox> Eickmeyer:  i didn't remove ubiquity task from the bug
<Eickmeyer> xnox: I realize that, but if it really is the plugin's fault, then the ball is in our court. Ideally, this needs to be resolved before Beta.
<rbalint> Eickmeyer, would you like to give it a try and maybe convert other repos or would you like me to convert it?
 * Laney gently redirects you all to #ubuntu-devel
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (eoan-proposed) [18.01-0ubuntu9.3]
<ahasenack> hi release team
<ahasenack> I mistakenly uploaded a package without the FFe approval
<ahasenack> stgraber: ^
<ahasenack> https://bugs.launchpad.net/bugs/1868609
<ubot5> Ubuntu bug 1868609 in libcbor (Ubuntu) "FFe: update to 0.6.0 (MIR requirement)" [Undecided,New]
<ahasenack> should it be removed?
-queuebot:#ubuntu-release- New binary: libcbor [amd64] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: libcbor [ppc64el] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: libcbor [i386] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: libcbor [s390x] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
<ahasenack> ^that one, good that it's stuck because of the new package that resulted from the soname change
<locutus_> ahasenack, according to upstream changelog no new features are added?
-queuebot:#ubuntu-release- New binary: libcbor [arm64] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: libcbor [armhf] (focal-proposed/universe) [0.6.0-0ubuntu1] (i386-whitelist)
<locutus_> but why no debian bug with patch or upload?
<ahasenack> it's part of a mir, and I was changing the package to conform to the mir requirements
<ahasenack> I'll submit to debian still, just did the same for libfido, part of the same mir
<ahasenack> about the release notes, it has the usual "BREAKING" and "WARNING" remarks that triggered my FFe warning
<locutus_> yes, but I mean, FFe is for new features, that package seems to be a bugfix update, not a FFe
<locutus_> breaking change because a bugfix changed soname, and the old soname was wrongly detected as 0.0, while the new one is "correct"
<locutus_> but still a bugfix to me?
<ahasenack> I usually error on the side of caution
<ahasenack> and there was this "All cbor_new_ and cbor_build_ functions will now explicitly return NULL
<ahasenack> when memory allocation fails"
<ahasenack> part of a fix, one could argue
<ahasenack> but let's argue in the FFe :)
<locutus_> still a bugfix, for a package that has no reverse-dependencies :)
<ahasenack> it has one, libfido2
<ahasenack> also part of the mir
<locutus_> so, no even risk of breaking reverse-deps
<ahasenack> quite the team
<ahasenack> I'll need an archive admin anyway
<locutus_> yep, so just check libfido2 for that api change, and I think we are happy to go?
<ahasenack> and, if it's really just bug fixes, even easier for the release team (although they might have their hands full)
<ahasenack> locutus_: wait, are you in the release team?
<ahasenack> libfido is fine
<locutus_> nope, I'm just to avoid giving them too much work :)
<ahasenack> I actually added tests to both packages (was a MIR requirement)
<ahasenack> yeah, there is that
<locutus_> I would explictly add something to the bug, with references to this conversation
<ahasenack> but I hope the ffe description, mp, all that, makes an AA feel better when looking at this
<locutus_> and upstream changelog, saying that they are bugfixes that changed the API, but no new features
<locutus_> doko, ^^
<ahasenack> I added these details to the bug (upstream changelog, highlighted what I think are the biggest changes)
<ahasenack> and also that there is only one rdep
<locutus_> nice :) I hope this will make the approval process smooth
<locutus_> g night
-queuebot:#ubuntu-release- New: accepted libcbor [amd64] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcbor [armhf] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcbor [ppc64el] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcbor [arm64] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcbor [s390x] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcbor [i386] (focal-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1080.90] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1080.90]
<bryce> alright, I think php7.3 can safely be removed now - LP: #1869087 - could an archive admin take a look?
<ubot5> Launchpad bug 1869087 in php7.3 (Ubuntu) "Remove "php7.3" from Focal, which has transitioned to php7.4" [Undecided,New] https://launchpad.net/bugs/1869087
<powersj> \o/
#ubuntu-release 2020-03-26
-queuebot:#ubuntu-release- New binary: gcc-9-cross-mipsen [ppc64el] (focal-proposed/universe) [3+c1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Packageset: 6799 entries have been added or removed
<handsome_feng> Hi, could someone in release team take a look at those ukui FFEs when you have time before Beta freeze? LP: #1868571 LP: #1868688 , Thanks in advance!
<ubot5> Launchpad bug 1868571 in ukui-control-center (Ubuntu) "[FFe] Sync ukui-control-center 2.0.1.1-2 (universe) from Debian unstable(main)" [Undecided,New] https://launchpad.net/bugs/1868571
<ubot5> Launchpad bug 1868688 in peony (Ubuntu) "[FFe] Sync peony 2.1.0 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1868688
-queuebot:#ubuntu-release- New binary: gcc-9-cross-mipsen [amd64] (focal-proposed/universe) [3+c1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-mipsen [amd64] (focal-proposed) [3+c1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-mipsen [ppc64el] (focal-proposed) [3+c1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel)
-queuebot:#ubuntu-release- New binary: gcc-defaults-mipsen [amd64] (focal-proposed/universe) [1.186.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-defaults-mipsen [amd64] (focal-proposed) [1.186.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1006.6]
<seb128> could someone review/merge https://code.launchpad.net/~seb128/britney/updated-graphite-version/+merge/381225
<seb128> updating the i386 graphite hint to the build1 upload done recently
<apw> seb128, is that not a candidate for force-reset-test ?
<apw> seb128, as i assume we expect it to be bad until it gets better (which may not be expected)
<seb128> apw, probably but I don't know how force-reset-test works so I did what I know :-)
<seb128> apw, if you want to do the right thing (and tell me how I request a force-reset next itme) that would be welcome
<apw> seb128, so it is the exact same syntax so "force-reset-test graphite2/1.3.13-11/i386"
<apw> meaning this version marks a new baseline of always-failed, so fail is now acceptable until it succeeds
<seb128> ah ok, I didn't know that was in the hints, I though that was a command to give to the state machine or something
<seb128> apw, do you want me to update the mp?
<apw> seb128, no it is a very new hint type, sure
<apw> any kicking-the-can scenario should be consisdered for this
<seb128> right, that makes sense
<Laney> juliank: weren't you going to write down some documentation for the hint types somewhere?
<seb128> are those thin documented... thanks Laney :)
<juliank> Laney: hmm yeah
<seb128> apw, https://code.launchpad.net/~seb128/britney/updated-graphite-version/+merge/381225 updated to be a foirce-reset-test now
<seb128> apw, thanks, can you also merge for me? I don't have the right to push there
<apw> seb128, done
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1007.7] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1006.6] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1007.7]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1006.6]
<seb128> apw, thanks
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-94.95] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1077.82] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-94.95] (core, kernel)
<doko> Reverse-Depends
<doko> * ruby-marisa                   (for libruby2.5)
<doko> * ruby-svn                      (for libruby2.5)
<doko> * ruby-xapian                   (for libruby2.5)
<doko> kanashiro: ^^^
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1077.82]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1060.64] (kernel)
<kanashiro> doko, those packages are still in proposed, I'll check the autopkgtest failures
<kanashiro> doko, src:marisa and src:xapian-bindings just need to retrigger autopkgtest (they were executed against ruby2.5 not ruby2.7), but src:subversion is now blocked because of a src:mercurial failure in armhf
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-94.95~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-94.95~16.04.1] (kernel)
<doko> kanashiro: mercurial fails way too often
<kanashiro> doko, already requested retriggers for all of them
<ahasenack> hi release team, anyone around? I have an FFe for libcbor, which is being MIRed, and which, together with libfido2 (already uploaded), will unblock openssh
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/libcbor/+bug/1868609
<ubot5> Ubuntu bug 1868609 in libcbor (Ubuntu) "FFe: update to 0.6.0 (MIR requirement)" [Undecided,New]
<ahasenack> sil2100: apw: Laney: if you have a moment please
<sil2100> ahasenack: I'll take a look
<handsome_feng> Hi, release team, could you take a look at those ukui FFEs when you have time? LP: #1868571 LP: #1868688 , Thanks and sorry for bother.
<ubot5> Launchpad bug 1868571 in ukui-control-center (Ubuntu) "[FFe] Sync ukui-control-center 2.0.1.1-2 (universe) from Debian unstable(main)" [Undecided,New] https://launchpad.net/bugs/1868571
<ubot5> Launchpad bug 1868688 in peony (Ubuntu) "[FFe] Sync peony 2.1.0 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1868688
-queuebot:#ubuntu-release- New source: python-django-pyscss2 (focal-proposed/primary) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New source: python-pyscss2 (focal-proposed/primary) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1060.64]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-94.95~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-94.95~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1037.41] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1037.41~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1037.41~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1037.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-94.95]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-94.95]
<cpaelzer> apw: sil2100: stgraber: Laney: I wanted to ask if one of you would have time for the qemu portion of the FFe in 1866866
<cpaelzer> jfh: ^^ FYI
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1057.60] (no packageset)
<jfh> cpaelzer: I agree, since time is progressing, it would be good to get a decision from the release team on the affected qemu component in LP 1866866
<ubot5> Launchpad bug 1866866 in qemu (Ubuntu) "[FFe] Please accept patches for secure guest feature" [High,New] https://launchpad.net/bugs/1866866
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1057.60]
<stgraber> so my personal opinion is that this is way too many changes way too late and that we should not do this
<stgraber> but if another release team member wants to go through all the changes and convince themselves that it's safe, I won't stand in the way
 * rbasak is looking at the containerd SRU in the Bionic queue
<juliank> Laney: Rebuilding focal adt images
<Laney> why?
<juliank> Laney: because they had an issue and were not rebuild for two weeks, and cause all sort of kmod errors
<juliank> Laney: I gotta check why
<Laney> yeah, please debug why the daily script isn't working
<juliank> Laney: I know we created two servers with the same name, and then it did not know which one to use :)
<juliank> Laney: maybe it failed two weeks ago and did not clean up the failed instances
<juliank> we'll see
<Laney> if that's the case then some robustification is needed
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (bionic-proposed) [1.3.3-0ubuntu1~18.04.2]
<jfh> stgraber: well, I agree that this is late - especially the qemu part - but that is the reason why there is this FFe at all
<jfh> the kernel and the s390-tools side of things are done - now qemu is the missing piece ...
<jfh> discussions on that started early - but it unfortunately took a while on getting it accepted - the almost all of the ocde is arch specific and is not active by default, an opt in is needed
<juliank> Laney: So build-adt-image-all-clouds exits with 0 even if all builds failed
<juliank> Laney: That's not super helpful
<juliank> Laney: And I'm not sure the create-nova image thingy is failing correctly
<juliank> Laney: Certainly setup-testbed is failing, I guess the | ssh pipes exits with 1, and the script is set -e?
<juliank> so this needs two things
<juliank> (1) build-adt-image-all-clouds needs to fail on failure
<juliank> (2) the other thing needs to clean up instances it creates on exit
<juliank> I guess for (1) maybe it could just check if the images it's supposed to create exist when it finishes
<Laney> I did do some robustness fixes in the wip/mojo-juju-2 branch but I'm not sure how applicable they would be to master
<Laney> there it's driven by a systemd unit called 'ensure-adt-image@'
<rbalint> ubuntu-archive, please unblock kodi: LP: #1868499
<ubot5> Launchpad bug 1868499 in kodi (Ubuntu) " Please remove s390x binaries for 2:18.5+dfsg1-0ubuntu3 with all reverse dependencies" [Undecided,New] https://launchpad.net/bugs/1868499
<juliank> Laney: do we have monitoring for that yet?
<Laney> for stg?
<juliank> because um, we want to get notified about such failures I guess
<Laney> or for build-adt-image on prod?
<juliank> stg
<Laney> ah, no, but as it happens I actually prodded the IS ticket about that today!
<juliank> like, it's nice there's a service that fails, but if nothing tells us it's failing we are where we are now :)
<juliank> ah good
<Laney> If they do what I suggested then we'll get an ubuntu-release.kpi.ubuntu.com grafana thingy to upload metrics into
<kanashiro> doko, ahasenack triggered the mercurial autopkgtest for me to make subversion migrate but it still fails, could you please take a look at it since you are the last uploader?
<kanashiro> marisa and xapian-bindings already migrated to the release pocket btw
<juliank> doko, Laney so we are up-to-date wrt autopkgtest images everywhere except amd64 on lgw which exceeded quotas
<juliank> I'll try to run create-nova-image-new-release manually
<juliank> take #2
<juliank> ugh
<juliank> running with -x now
<juliank> it failed _somewhere_
<juliank> with -x, i should at least know which line it stopped running at
<juliank> heisenbug it seems
<juliank> doko, Laney images should be fixed now
<sforshee> doko, mwhudson: I'm seeing the glibc pwd/tst-getpw test fail in autopkgtest on arm64/armhf, is this a known issue?
<ahasenack> ubuntu-archive: hi, if you could please let libcbor0.6 through, it's a new soname, hence the NEW package. FFe bug linked in the changelog
<mwhudson> sforshee: i don't think so
<sforshee> mwhudson: I'm seeing it when testing the focal-proposed kernel, but looking at the test I think it's unlikely to be a kernel regression
<mwhudson> sforshee: well this version of glibc has passed several times: https://autopkgtest.ubuntu.com/packages/glibc/focal/arm64
<sforshee> mwhudson: yes, I saw. I tried it on an arm64 box too and it passed with the -proposed kernel, so I'm not sure what to think about it
<sforshee> unless it's some weird setup in autopkgtest where there's a user defined for all the ids it's testing
<mwhudson> that would be pretty eccentric
-queuebot:#ubuntu-release- New sync: gcc-10-cross-mipsen (focal-proposed/primary) [2+c1]
<mwhudson> original exit status 223
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [sync] (focal-proposed) [2+c1]
<mwhudson> i wonder if the failing uid checks are setting errno
<mwhudson> because 65535 - 30ish valid uids modulo 256==223 is kinda plausible
<mwhudson> if only the test logged what errno was :)
<mwhudson> sforshee: not sure how to debug this at this distance
<mwhudson> sforshee: i guess i can patch the test to be more verbose, upload it, wait for it to build, run the test against my ppa...
<mwhudson> alternatively might be able to reproduce in canonistack
<sforshee> mwhudson: yeah, I was hoping to be able to reproduce it but no such luck
<mwhudson> sforshee: certain people can run things in production infrastructure, i'm not one of them though
<sforshee> Laney might be able to help
<mwhudson> Laney, vorlon, juliank, none of them are around now i expect
<bryce> ubuntu-archive: php7.3 can removed at your convenience - LP: #1869087.  I examined the rdepends and unless I'm doing it wrong there appear to be no rdepends remaining.  I suspect it's good to go at this point.
<ubot5> Launchpad bug 1869087 in php7.3 (Ubuntu) "Remove "php7.3" from Focal, which has transitioned to php7.4" [Undecided,New] https://launchpad.net/bugs/1869087
<doko> bryce: ta, nice!  can I pester you about the php-mockery autopkg test failures?
<doko> php7.3 removed
<bryce> doko, thanks, glad to see that gone
<doko> could you look at php-mockery?
<bryce> doko, hm, what does it need?
<doko> ENOCLUE: http://autopkgtest.ubuntu.com/packages/p/php-mockery/focal/arm64
<doko> on all archs
<doko> Class 'DOMDocument' not found
<bryce> doko, offhand that sounds like one of the issues that comes up from the phpunit transition.  I'd suggest retriggering php-mockery with phpunit/8.5.2-1ubuntu1 and sphinx/1.8.5-7ubuntu1
<bryce> and maybe php-redis/5.1.1+4.3.0-1 too, looks like that's also in proposed
<bryce> doko, if you'd like I can do those retriggers for you?
<doko> bryce: now done
<ahasenack> doko: are you able to help with a i386 badpkg issue? ruby-zip became a _all.deb in 2.0.0, and it's now failing i386 autopkgtests
<ahasenack> we already edded Multi-Arch: foreign to it
<ahasenack> no go in the bileto tries
<ahasenack> https://bileto.ubuntu.com/excuses/3994/focal.html
<ahasenack> is it a case for an all badtest on i386?
<doko> ahasenack: no, requires ubuntu-release people
<ahasenack> ok
<ahasenack> kanashiro: ^
<ahasenack> kanashiro: https://launchpad.net/~ubuntu-release/+members#active
<kanashiro> all the packages under ruby-zip in excuses page are ignoring failures in i386
<ahasenack> kanashiro: maybe prepare a branch in the meantime
<ahasenack> to take advantage of timezone
<kanashiro> ahasenack, makes sense
<ahasenack> kanashiro: do you know where to do that?
<kanashiro> ahasenack, hints-ubuntu repo, right? I just need to learn bzr again :)
<ahasenack> I know that feeling
<ahasenack> there is always a catch, the mp target is not the default
<ahasenack> I always go back to an old mp to check
<ahasenack> kanashiro: https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
<kanashiro> ahasenack, thanks, appreciated :)
-queuebot:#ubuntu-release- Packageset: 6799 entries have been added or removed
<ahasenack> if the diff is huge, the target is wrong :)
<kanashiro> got it
<ahasenack> bryce: was that php7.3?
<bryce> ahasenack, sorry?
<ahasenack> 6799 entries
<ahasenack> don't panic :)
<bryce> ah yeah lots of php7.3 packages sprouted daisies today
<ahasenack> kanashiro: add a link to our bileto run
<ahasenack> kanashiro: I'll leave it be
<ahasenack> https://bileto.ubuntu.com/excuses/3994/focal.html
<ahasenack> and explain we added multi-arch foreign in that run
<kanashiro> ahasenack, ok
<ahasenack> checking puppet now
<ahasenack> I think it's still the old run
<ahasenack> yeah, from 1553 utc
<Eickmeyer> Archive Admins: I have an entirely NEW package in queue for Focal that has been sitting for about 3 days now. With Beta fast approaching, can this get pushed though?
<kanashiro> ahasenack, here is the MP: https://code.launchpad.net/~lucaskanashiro/britney/hint-ruby-zip-i386/+merge/381275
<juliank> sforshee: i retried against release pocket glibc, maybe it fails there too, it's possible something else regressed
<juliank> sforshee: Unfortunately I'm out until Monday, so I won't be able to do much else
<RAOF> Eickmeyer: that's dragonfly-reverb?
<Eickmeyer> RAOF: Yes.
<RAOF> I'll look at it this morning.
<Eickmeyer> Sounds good. :)
<ahasenack> sil2100: upstream libcbor released 0.6.1 with the soname change we adopted in 0.6.0
<ahasenack> I'll see to it tomorrow
<Ukikie> xnox: Thanks for asking #debian-ftp about the license issue.
<mwhudson> https://code.launchpad.net/~mwhudson/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/381277 if there's a release team person around
<RAOF> Eickmeyer: Why are you never uploading simple packages? ð
<Eickmeyer> RAOF: Ha! Believe it or not, this was one of the "simpler" ones. :P
<Eickmeyer> You should've seen me a year ago with lsp-plugins.
<RAOF> Maybe could the audio upstreams embed fewer fonts as strings in their C++ source files?
<Eickmeyer> Sure would be nice, but I think people are paranoid about not having a "consistent" look by relying on a font as a dependency.
<RAOF> Because I'm not sure whether doing that with an OFL font actually passes copyright muster?
<Eickmeyer> I'm pretty sure it does. Not the first time NotoSans has distributed with a package.
<RAOF> (One of the OFL clauses is âyou cannot distribute a derivative under any other licenseâ, which might be problematic)
<RAOF> Could they just, you know, copy the font file to a known location and then load that?
<RAOF> ð¤·
<Eickmeyer> I think when it comes to that, a derivitive of the font isn't what's being distributed. It's the actual font.
<RAOF> It's absolutely clear that distributing NotoSans-Regular.ttf is fine by the license.
<RAOF> It's less clear that taking NotoSans-Regular.ttf, encoding it as a char const*, embedding it in the output and then distributing that output is fine by the license.
<RAOF> (Also, NotoSans_Regular.ttf.cpp is not exactly the preferred form of modification ð)
<Eickmeyer> Are they actually modifying the font itself?
<RAOF> I don't know. I don't know how they've generated NotoSans_Regular.ttf.cpp (it does not appear to be generated by any of the build scripts?)
<Eickmeyer> As I look at the file, it seems to just be the font renamed, but I could be wrong.
<RAOF> Unless you mean modified in the copyright sense, then, yes, they have: they've taken the binary bytes of the .ttf file and encoded them as `0xâ¦` hex in the cpp file.
<RAOF> The cpp file is undoubtedly a derivative of the font file.
<Eickmeyer> That's not good. I'll have to inform upstream.
<RAOF> Well, âundoubtedlyâ is maybe a bit strong. I strongly suspect that it is, but I don't know, because I don't know what it's content is, other than 2MB of char const*.
<RAOF> I'm just assuming based on the filename and variable name that it's an encoding of NotoSans-Regular.ttf ;)
<Eickmeyer> Yeah, hard to tell.
<Eickmeyer> I'm looking at their github issues to see if they have an open/closed issue about it, and there doesn't appear to be.
<Eickmeyer> I can ask someone.
<RAOF> I'll keep reviewing the package, but I'd need to ask around on the team before accepting it with this font weirdness.
-queuebot:#ubuntu-release- New binary: what-is-python [amd64] (focal-proposed/main) [3] (no packageset)
<RAOF> Huh. Why do the binary packages Provide: lv2-plugin, vst-plugin, etc?
<Eickmeyer> RAOF: Because they are lv2 plugins and vst plugins. That can be removed, if necessary. You'd find that common in a lot of audio plugin packages.
<Eickmeyer> Also, a bit of an answer on the Noto Sans issue: it might be actually Apache licensed?
<Eickmeyer> RAOF: per https://fonts.google.com/specimen/Noto+Sans
<Eickmeyer> RAOF: Here's how the .cpp file is generate: `xxd -i common/NotoSans/NotoSans-Regular.ttf`
<Eickmeyer> We could, theoretically, patch to remove the file and regenerate it using debian/rules, but I feel like that's reinventing the wheel.
<RAOF> We'd only do that if we were going to use the archive version of NotoSans rather than the shipped version.
<Eickmeyer> Is that necessary?
<Eickmeyer> RAOF: Per the Linux Audio Developers (#lad): xxd would qualify as a rather strict form of not being modified, it almost modifies the font data less than including it in an email attachment.
<RAOF> It doesn't really matter whether or not the font is modified; the OFL is perfectly happy for you to modify the font.
<Eickmeyer> Ok
<RAOF> The question is whether embedding the font in the binary this way makes the binary a derivative of the font.
<Eickmeyer> In the opinion of those I've talked to, the answer is no.
<RAOF> Really? I'm not a lawyer by any means, but âthing is literally copied into your binaryâ seems pretty open-and-shut that you binary is a derivative work?
<Eickmeyer> I'm asking.
<Eickmeyer> RAOF: Per Dr. Robin Gareus (one of the main developers behind Ardour and x42-plugins): it's like statically linking against a lib. the compound inherits the license.derivative, no. compound, yes
<RAOF> What does compound mean in this case? Because statically linking a lib definitely makes you a derivative work by the AA's understanding of copyright.
<RAOF> (That's why the copyright of the libraries you use matters at all, as opposed to the âmere aggregationâ involved in shipping a CD with a bunch of binary packages on it)
<Eickmeyer> Audio plugins use static-linked libraries all the time as it's standard/commond practice when developing audio plugins. You'll see the same thing in x42-plugins.
<RAOF> Yeah, that's fine. And they're derivative works of those libraries.
<RAOF> Because the licenses are compatible.
<RAOF> But the OFL's license states that you can only distribute derivatives under the OFL.
<Eickmeyer> So, I've been linked to this particular entry of the OFL FAQ: https://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL-FAQ_web#2a57c6bb
<Eickmeyer> I'm not 100% that's the question here though.
<RAOF> Yeah, that's not quite the question.
<RAOF> This would be 100% fine if they were shipping NotoSans_Regular.ttf.
<RAOF> I'm not sure if it's still fine if they take NotoSans_Regular.ttf, and then embed it in their binary.
<Eickmeyer> Look at the next question down (1.21). I think that's what is relevant here.
<Eickmeyer> RAOF ^
<RAOF> Maybe?
<RAOF> I did see that; if anything, that suggests that maybe they should be renaming the fonts?
<Eickmeyer>  "Alternatively if you directly add a font under the OFL to the font folder of your firmware without modifying or optimizing it you are simply bundling the font like with any other software collection, and do not need to make any further changes."
<RAOF> Right, but that's what they're not doing.
<Eickmeyer> It is what they're doing, if it's going unmodified into a .cpp file.
<RAOF> They're not shipping it in a font folder (which I agree would be totally fine).
<RAOF> Is a .cpp file a font folder? ð
<RAOF> It's not; they're (very slightly) changing the format, and it's now not separable from the binary.
<Eickmeyer> That was just an example. The principle is shipping it unmodified inside a binary, such as firmware.
#ubuntu-release 2020-03-27
<RAOF> Maybe?
<RAOF> Firmware has the distinction that it's often a binary only in the same way that ubuntu-desktop.iso is a binary.
<RAOF> But, hey! Copyright is weird and a stupid thing to apply to software.
<Eickmeyer> I'd argue a .cpp library file is the same when xxd is used to encode it.
<RAOF> That's certainly an argument you could make. I'm not convinced either way.
<RAOF> Ah. That's where the rest of those things are going. Artwork.cpp is also generated the same wayâ¦
<RAOF> Is it difficult to get filesystem access from lv2 plugins or something?
<Eickmeyer> It depends. They're basically libraries that exist in a path for digital audio workstations and plugin hosts.
<Eickmeyer> RAOF: But, basically, yes, plugins don't typically have filesystem access.
<Eickmeyer> In fact, that's one reason we don't ship any snaps in Ubuntu Studio.
<RAOF> Hm. Was this originally in Debian? Is there value in including the old changelog entries (from a non-official Debian archive?)
<Eickmeyer> It wasn't originally in Debian, but a French Debian derivitive. I tried to eliminate the old changelog entries that were in French but the person who put them there (in French) objected vocally.
<Eickmeyer> So, I translated them, but Lintian didn't like the translated form.
<RAOF> Heh. Ok.
<RAOF> You use a debian/copyright generator, don't you. That's why it's so granular? :)
<Eickmeyer> Actually, I took what was already there and hand-wrote most of it. :D
<Eickmeyer> I had to take special care to add the dpf/* items since that was a git submodule that had to be repacked.
<RAOF> Ok. Time to go and renew my license. I think the rest is ok (although it's a little weird that both the dragonfly-reverb metapackage and the packages it depends on Provide: lv2-plugin and vst-plugin)
<Eickmeyer> RAOF: Have fun. License renewals: I don't envy you.
<teward> RAOF: i was pinged.
<teward> and am playing catchup
-queuebot:#ubuntu-release- Unapproved: containerd (eoan-proposed/universe) [1.3.3-0ubuntu1~19.10.1 => 1.3.3-0ubuntu1~19.10.2] (no packageset)
<RAOF> Eickmeyer: Actually, the other thing I'd like to have in there is some documentation as to regenerate the various embedded files would be nice - the various Artwork.cpp files and NotoSans_Regular.ttf.cpp.
<RAOF> I don't think I'd block on that, but it's the sort of thing that'd be really nice for anyone who actually wanted to take us up on our offer of being able to modify all our source packages :)
-queuebot:#ubuntu-release- New binary: gcc-10-cross-mipsen [ppc64el] (focal-proposed/universe) [2+c1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-10-cross-mipsen [amd64] (focal-proposed/universe) [2+c1] (no packageset)
<cpaelzer> hi ubuntu-archive geoip geoip-database and python-geoip are listed as "source and binary movement to universe". This is intentional (we switched to v2) and I'd ask if one of you could please do the change?
<cpaelzer> ahasenack: ^^ FYI
<seb128> cpaelzer, hey, demoted now!
<cpaelzer> thanks!
<cpaelzer> rbasak: if you are around it would be nice to ack and push https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/ubuntu/+merge/381289 so that later someone can do the associated demotion and allow the new stable dpdk to migrate
<sil2100> RikMills[m], valorie: hey! So I have created the FocalUpgrades page on https://help.ubuntu.com/community/FocalUpgrades - could you make sure the Kubuntu upgrade section is good?
<RikMills> sil2100: thanks for that. yes will get that done soonish
 * sil2100 hugs RikMills 
<RikMills> grr. I guess libreoffice tests don't very much like it migrating from proposed to release half way through an 8 hr test run!
<rbasak> cpaelzer: done
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [amd64] (focal-proposed) [2+c1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [ppc64el] (focal-proposed) [2+c1]
-queuebot:#ubuntu-release- New: accepted what-is-python [amd64] (focal-proposed) [3]
<seb128> could someone look at bug #1868927?
<ubot5> bug 1868927 in shared-mime-info (Ubuntu) "FFe: Sync shared-mime-info 1.15-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1868927
<seb128> I'm not convinced a FFe is required, it's mostly bugfixes but still since it's up for one I would rather no by pass r-t
<Laney> seb128: you can sync that one
<seb128> Laney, thanks
<doko> sil2100, apw: please ignore the ruby2.5 autopkg test triggered by libffi, we are going to remove ruby2.5 before the release
-queuebot:#ubuntu-release- New binary: pydoctor [amd64] (focal-proposed/universe) [19.11.0+git20200303.47424e7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pydoctor [amd64] (focal-proposed) [19.11.0+git20200303.47424e7-1]
-queuebot:#ubuntu-release- New binary: rpmlint [amd64] (focal-proposed/universe) [1.11-0.2] (no packageset)
<kanashiro> ubuntu-archive: when someone has some time I requested a removal for ruby2.5 here: https://bugs.launchpad.net/ubuntu/+source/ruby2.5/+bug/1869365
<ubot5> Ubuntu bug 1869365 in ruby2.5 (Ubuntu) "[RM] Removal request of ruby2.5/2.5.7-1ubuntu4 from Focal" [Undecided,New]
-queuebot:#ubuntu-release- New: accepted rpmlint [amd64] (focal-proposed) [1.11-0.2]
<doko> done
-queuebot:#ubuntu-release- New source: oem-somerville-three-eyed-raven-meta (focal-proposed/primary) [20.04~ubuntu1]
<Laney> that ^ is for NEWing to main please, under the exception listed in the referenced bug
<coreycb> hello, please can someone reject python-pyscss2 and python-django-pyscss2 from the focal new queue? upstream horizon moved back to the original deps so these are no longer needed.
<cpaelzer> ubuntu-archive: hiho there is dpdk-doc as "Binary only movements to universe" - as well as as for "libnginx-mod-http-geoip"
<cpaelzer> both are intentional and I wanted to ask if someone could do these moves
<cpaelzer> dpdk would also free it up in proposed migration to move before the next level of freezes next week
<Eickmeyer> RAOF: I'll open an issue with upstream about that.
<Eickmeyer> RAOF: https://github.com/michaelwillis/dragonfly-reverb/issues/66
<gitbot> michaelwillis issue 66 in dragonfly-reverb "Packaging for Ubuntu" [Open]
<xnox> kanashiro:  release team cannot remove packages, normally RM bugs should add ~ubuntu-archive as subscriber
<xnox> kanashiro:  and AA did that already now
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1046.51] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1079.89] (kernel)
-queuebot:#ubuntu-release- New binary: poppler [s390x] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [amd64] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [armhf] (focal-proposed/main) [0.86.1-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (focal-proposed) [0.86.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (focal-proposed) [0.86.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (focal-proposed) [0.86.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (focal-proposed) [0.86.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (focal-proposed) [0.86.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (focal-proposed) [0.86.1-0ubuntu1]
<wxl> looks like something is not working right with the iso building todayâ¦ temporary glitch? https://launchpadlibrarian.net/471010607/buildlog_ubuntu_focal_amd64_lubuntu_BUILDING.txt.gz
<cjwatson> Yes, should be fixed now
<cjwatson> (Rolled back anyway - we haven't completely worked out the underlying cause yet)
<wxl> ^ bashfulrobot that affects you, too, so trigger a rebuild on your images
<wxl> thanks cjwatson
<bashfulrobot> wxl I appreciate hte heads up!
<kanashiro> xnox, ok, I did subscribe ~ubuntu-archive
<valorie> sil2100: thanks for doing that
<valorie> will test shortly
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Beta] (20200327.1) has been added
-queuebot:#ubuntu-release- New: rejected python-django-pyscss2 [source] (focal-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-pyscss2 [source] (focal-proposed) [2.0.0-0ubuntu1]
<teward> Laney: re: gpaste that came over the sponsors list, I took that up and synced it - it's currently sitting in proposed :)
<teward> since I saw you ID that there's no need for FFe
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.41 => 2.525.42] (desktop-core)
<xnox> kanashiro:  ok cool, sorry that i missread things
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Beta] (20200327) has been added
<Eickmeyer> Huh. I didn't think we were going to start seeing beta builds until after beta freeze, but oh well.
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1046.51]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1079.89]
-queuebot:#ubuntu-release- Unapproved: mstflint (eoan-proposed/universe) [4.11.0+1-1 => 4.13.3+2-2~ubuntu19.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mstflint (bionic-proposed/universe) [4.8.0-2 => 4.13.3+2-2~ubuntu18.04.1] (no packageset) (sync)
#ubuntu-release 2020-03-28
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Beta] (20200327) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Beta] has been updated (20200328)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Beta] (20200328) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Beta] (20200328) has been added
#ubuntu-release 2020-03-29
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal Beta] has been updated (20200328)
-queuebot:#ubuntu-release- New binary: libmypaint [amd64] (focal-proposed/universe) [1.5.1-1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New binary: libmypaint [s390x] (focal-proposed/universe) [1.5.1-1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New binary: libmypaint [ppc64el] (focal-proposed/universe) [1.5.1-1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New binary: libmypaint [arm64] (focal-proposed/universe) [1.5.1-1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- New binary: libmypaint [armhf] (focal-proposed/universe) [1.5.1-1] (ubuntustudio, xubuntu)
<ginggs> would someone please 'force-reset-test r-cran-processx/3.4.2-1/s390x' ? it has regressed in -release
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- New: accepted libmypaint [amd64] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted libmypaint [armhf] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted libmypaint [s390x] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted libmypaint [arm64] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted libmypaint [ppc64el] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- New sync: mypaint (focal-proposed/primary) [2.0.0-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal Beta] has been updated (20200329)
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-bluetooth-quick-connect (focal-proposed/primary) [10-3]
-queuebot:#ubuntu-release- New sync: rabbitvcs (focal-proposed/primary) [0.18-1]
<Eickmeyer> Release Team: We (Ubuntu Studio) have been waiting for bug 1803924 to be fixed for two years now, and it looks as though that is finally happening. With that, we want it back in Ubuntu Studio's seed.
<ubot5> bug 1803924 in MyPaint "Gimp conflict with MyPaint" [Unknown,New] https://launchpad.net/bugs/1803924
<Eickmeyer>  With Beta Freeze tomorrow, will that 1) Require a FFe, and if so 2) Can I get a PROMISE that it will get looked at/approved in time for beta freeze?
-queuebot:#ubuntu-release- New binary: lilypond [amd64] (focal-proposed/universe) [2.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pysnmp4-apps [amd64] (focal-proposed/universe) [0.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pysnmp4-mibs [amd64] (focal-proposed/universe) [0.1.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted lilypond [amd64] (focal-proposed) [2.20.0-1]
-queuebot:#ubuntu-release- New: accepted python-pysnmp4-mibs [amd64] (focal-proposed) [0.1.3-2]
-queuebot:#ubuntu-release- New: accepted python-pysnmp4-apps [amd64] (focal-proposed) [0.3.2-2]
<valorie> Eickmeyer: I see nothing in the BR showing that the 2.0.0 version fixes the issue
<valorie> probably good to add testing info if you have it
<jbicha> valorie: the fix is https://salsa.debian.org/multimedia-team/libmypaint/-/commit/4202d6631
<Eickmeyer> ^ I was just about to... thanks, jbicha.
<valorie> cool
<Eickmeyer> jbicha: Is there a sync request on this?
<jbicha> Eickmeyer: the new libmypaint is landing in focal now. mypaint is in the NEW queue
<Eickmeyer> jbicha: Excellent. I still want a response from the release team. I really want to JFDI, but I know I'll get torn a new one for doing it.
<Eickmeyer> Basically, I need a FFe exception, considering how close to beta freeze this is, I can't count on the formal FFe process which I've met with little success in the past as they've largely gone completely ignored.
<Eickmeyer> Just timing is difficult right now.
<jbicha> this is a pretty simple case now :)
<Eickmeyer> jbicha: I realize that, but we removed it from the Studio seed because of the conflict. I can put it back, but I fear that needs a FFe.
-queuebot:#ubuntu-release- New binary: logging-tree [amd64] (focal-proposed/universe) [1.8.1-0.1] (no packageset)
