#ubuntu-release 2010-09-27
<cjwatson> could somebody review mountall?  I ran the "mountpoint is a symlink to another mountpoint" handling past Keybuk and got a "looks sane"; the other changes are a few lines each and easily eyeballable
<cjwatson> I uploaded sysvinit and mountall intending them to be reviewed as a pair, but unfortunately only sysvinit has been accepted
<cjwatson> slangasek: linux-linaro and linux-meta-linaro are a lot of what's left in component-mismatches.  Should they be seeded or demoted?
<cjwatson> I've looked through the python-gnome2-desktop NBS listing (which also effectively covers python-gnomeprint).  They're all false positives due to ored dependencies, with the exception of labyrinth (filed bug 648469) and memaker (fix uploaded).
<ubot4> Launchpad bug 648469 in labyrinth (Ubuntu Maverick) (and 1 other project) "depends on NBS python-gnome2-desktop (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/648469
<cjwatson> oh my.  http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev is not going to be fun.
<cjwatson> is anyone at all driving that transition?
<cjwatson> looks like libopensync0-dev -> libopensync-dev, opensync-1.0.pc -> libopensync.pc (which will entail a load of reautotooling) and probably some more ...
<ogra> oh, cdimage has new CSS
<ogra> a bit out of bounds with the content though
<slangasek> cjwatson: linux{,-meta}-linaro> demoted; I thought doko was already taking care of this?
<wgrant> cjwatson: bigjools wants your blessing for the queue admin permission granularity extensions. Could you record your approval on bug #648611?
<ubot4> Launchpad bug 648611 in soyuz "Queue admin permissions need pocket and status granularity (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/648611
<mvo> I sponsored mesa based on the FFe discussed in #631413 - it has quite a bit of churn :/
<mvo> it seems that if we decided to go with that branch we should go all the way instead of shiping a snapshot, but I can not say that I feel really great about it (from a releae-management POV)
<mvo> fwiw I tested it on my intel arrandale and it was fine there
<cjwatson> ogra: yes, I've reported the poor layout and Matt Nuzum is supposed to be doing something about it
<ogra> nice
<cjwatson> slangasek: thanks
<cjwatson> wgrant: done
<ogra> btw, i jusr discovered that i missed to seed u-boot-linaro-omap3-beagle ... just a warning that i just replaced u-boot-omap3 with it since you guys are cleaning up component mistmatches
<ogra> (it will likely show up there soon)
<wgrant> cjwatson: Thanks.
<ogra> (removal bug is filed too as bug 648616)
<ubot4> Launchpad bug 648616 in u-boot-omap3 (Ubuntu Maverick) (and 1 other project) "please remove u-boot-omap3 from the archive, it got replaced by u-boot-linaro (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/648616
<cjwatson> did whoever reviewed debconf ensure that it behaves appropriately when unconfigured?
<cjwatson> slangasek: the linux-linaro demotion doesn't seem to be taking; I'm going to try promoting it to main and then demoting it again in the hope that that will take
<cjwatson> the database is right but it hasn't been published
<cjwatson> doko_: this libopensync-plugin-gnokii rebuild isn't enough; notice how it's also listed in http://people.canonical.com/~ubuntu-archive/NBS/libopensync0-dev.  Rejecting it
<cjwatson> doko_: same goes, I suspect, for all your opensync uploads :-(
<cjwatson> doko_: surely they need to be converted to the current development package
<cjwatson> 02:19 <cjwatson> looks like libopensync0-dev -> libopensync-dev, opensync-1.0.pc -> libopensync.pc (which will entail a load of reautotooling) and probably some more ...
<doko_> cjwatson: yes =)
<doko_> had the old package still installed :/
<cjwatson> ok, rejecting them all then, sorry - probably best not spend buildd time in duplicate at the moment
<wgrant> cjwatson: Does linux-linaro have any arch-indep packages?
<wgrant> If so, you've just destroyed them.
<wgrant> Ah, it appears not. Good.
<cjwatson> why would I have?
<wgrant> Reverting an unpublished override eats arch-indep binaries.
<cjwatson> wgrant: lovely ...
<wgrant> cjwatson: Yes.
<wgrant> cjwatson: Why do you think the demotion hadn't worked? You overrode it a couple of minutes into last hour's publisher.
<wgrant> So it should be publishing right around now.
<cjwatson> wgrant: and I'd overridden it an hour or two before that, and slangasek an hour or two before that.
<wgrant> Soyuz only knows about one 59 minutes ago.
<wgrant> And it just published now.
<cjwatson> 09:21 <slangasek> cjwatson: linux{,-meta}-linaro> demoted; I thought doko was already taking care of this?
<wgrant> So change-override didn't do anything. Do you have output from a run before an hour ago?
<cjwatson> insufficient screen scrollback, sorry
<wgrant> Hmmm.
<cjwatson> well, sorry if I reverted the override unnecessarily; I can put it back later today
<wgrant> It seems to have happily returned to main now.
<wgrant> So a further universe override should work fine.
<cjwatson> should I wait 'til this publisher run finishes?
<wgrant> But I am intrigued as to why change-override didn't do anything the first two times.
<wgrant> Doesn't matter, no.
<cjwatson> hang on, if it just published now, then that override was the one that put it back to main
<cjwatson> the output of change-override when I tried to override to universe said that it was already in universe
<wgrant> cjwatson: The universe and main overrides just published together.
<cjwatson> oh
<wgrant> In a few minutes the main one will supersede the universe one.
<cjwatson> I've overridden it back to universe, then
<cjwatson> which hopefully will actually work
<wgrant> It has worked, yep.
<cjwatson> I mean publish :-)
<doko> cjwatson: any idea why springlobby doesn't have build records for armel and powerpc?
<cjwatson> %spring: i386 amd64                                                   # x86 specific, needs java5 and hardware accellerated OpenGL
<cjwatson> %springlobby: i386 amd64                                              # Depends on spring
<cjwatson> (Packages-arch-specific)
<cjwatson> that's straight from Debian
<doko> cjwatson: hmm, I did look at bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
<stgraber> Riddell: ping
<Riddell> hi stgraber
<stgraber> Riddell: did you get my mail regarding langpack issues affecting Edubuntu and Kubuntu ?
<Riddell> don't think so
<Riddell> ah, there it is, /me reads
<stgraber> it's kind of an issue as it makes Edubuntu and Kubuntu DVD to fail to build completely :(
<Riddell> stgraber: pitti and cjwatson were discussing that earlier in #u-d
<Riddell> 11:43 < cjwatson> or we could exclude those language packs from the build
<stgraber> oh, ok, didn't see it (just woke up) :)
<Riddell> seemed to be the conclusion
<Riddell> I don't know how to exclude them from the seeds though
<stgraber> no idea, in our case we use a regexp to match everything, so we might need some cjwatson magic (would the blacklist work for that ?) to solve the issue
<stgraber> I clearly don't mind shipping RC with a few missing kde langpacks as long as I at least have a build to release ;)
<cjwatson> I can deal with it
<cjwatson> regexps can support that kind of thing if you're sufficiently devious
<stgraber> cjwatson: I'd appreciate it, thanks.
<doko> ScottK: bug #648773
<ubot4> Launchpad bug 648773 in ufc (Ubuntu) (and 1 other project) "FFe: sync ufc and dolfin from unstable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/648773
<cjwatson> doko: debconf fails to build, and I'm concerned about changing helpers at this point since debconf.py has very specific requirements (it absolutely has to work even when unconfigured).  Would it be possible to have an upload that reverts the use of dh_python2/3 and just fixes the python3 module path?
<doko> cjwatson: ok, will look at it. might require a python-central merge from unstable. will know later
<zul> can someone accept the new mysql-cluster upload it contains the proper fix for mysqlclient collision bug
<cjwatson> zul: err ... same version as what's already in the archive?
 * cjwatson thinks LP could stand to have rejected that one
<zul> cjwatson: umm
<zul> cjwatson: crap...never mind
<seb128> hello there
<seb128> I think you will not like that but glib update coming
<seb128> it's breaking quite some abi and api and even dropping some
<seb128> do you want a bug with the debdiff, NEWS, rational etc?
<seb128> basically those are api added during the unstable cycle they decided were wrong and dropped before GNOME 2.32
<seb128> they are updating the GNOME 2.32 according to the changes
<cjwatson> I think we should search the archive for uses of such API
<seb128> it's very likely that nothing else is using those api
<cjwatson> we don't have time to react in any less organised way
<seb128> do we have an easy way to do that?
<cjwatson> probably not, find a DC machine with an archive and unpack it
<seb128> kees, ^
<seb128> I think you did grepping for api some time ago for dx
<seb128> do you have an easy setup for that?
<seb128> ok
<seb128> bug #648877
<ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
<seb128> has a summary of the changes and a debdiff for review
<cjwatson> ubiquity 2.4.3 fixes livefs build failures with 2.4.2; would appreciate review
<doko_> cjwatson: could you have a look at http://paste.ubuntu.com/501506/ for gcc-4.4 (and maybe for gcc-4.5 too)
<cjwatson> looks ok to me
<doko_> ok, finishing my test build and veryfing that plplot builds again
<seb128> is there anybody in charge of the release or who can be pinged for reviews?
<seb128> until when do we have for changes?
 * Riddell doing reviews
<raphink> hi guys
<raphink> the most recent berkeley DB is 4.8 in maverick/main
<raphink> would it be a good idea to have db5.0 in universe?
<raphink> I have the package ready
<raphink> (and tested in production)
<raphink> anyone here?
<cjwatson> raphink: I think new packages in universe are probably not a good idea at this point; there's too little time to fix them if they turn out to have problems
<raphink> ok
<raphink> thanks
<kees> seb128: hello!
<kees> seb128: yeah, I can do another search; I have a local copy of the archive. what's the api?
<seb128> kees, hey
<seb128> g_application
<seb128> g_application*
<kees> seb128: ok, checking
<seb128> thanks
<slangasek> cjwatson: sorry, when I said "demoted" I meant "should be demoted", not "I've demoted them" - so yours was the first override, I think :)
<cjwatson> slangasek: ah - gotcha
<Riddell> in https://wiki.kubuntu.org/ReleaseCandidateProcess where it says Modify debian-cd/CONF.sh to set OFFICIAL="Release Candidate"  where is that file?
<Riddell> /srv/cdimage.ubuntu.com/debian-cd/CONF.sh looks likely
<cjwatson> bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd/
<cjwatson> edit it there please, then 'bzr pull' in /srv/cdimage.ubuntu.com/debian-cd
<cjwatson> I've mucked around with scary regexes in the Kubuntu and Edubuntu DVD seeds to exclude the broken language packs for now
<cjwatson> should be reverted after the new base language packs arrive post-RC
<stgraber> cjwatson: thanks
<seb128> kees, still grepping?
<kees> seb128: yup.
<seb128> ok
<kees> seb128: so far, glib2.0 glibmm2.4 totem
<kees> (I'm past "t" in main, universe will probably take until tomorrow)
<seb128> kees, can you put the list on bug #648877
<ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
<seb128> once it's past the main set
<kees> seb128: sure thing
<seb128> thanks!
<kees> seb128: oh, finished main. I've updated the bug
<seb128> kees, thanks
<kees> np
<seb128> cjwatson, skaet, slangasek: could you review the glib update?
<seb128> cjwatson, skaet, slangasek: could you review the glib update?
<seb128> ups
<seb128> bug #648877
<ubot4> Launchpad bug 648877 in glib2.0 (Ubuntu) "2.25.16 glib update (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/648877
<ScottK> cjwatson or slangasek: Could I have a respin of Kubuntu desktop live on i386?  We'd like to test the latest ubiquity on an actual ISO (just to be sure as soon as possible it's working).
<skaet> seb128,  looking...
<seb128> skaet, thanks
<ScottK> slangasek and cjwatson: unping.
<Riddell> seb128: did you work out a way to check that the ABI changes to glib don't affect anything?
<seb128> Riddell, kees is grepping the archive for those abi, there is only totem and glibmm using it in main
<seb128> and those are going to be updated today as part of GNOME 2.32
<ScottK> How about Universe?
<seb128> grep still running
<ScottK> OK
<Riddell> seb128: thanks, I'll accept
<seb128> but I would be surprised if something out of GNOME was using it
<seb128> those api have been adding in the maverick cycle
<kees> ScottK: I'll have universe in about 10 hours, I think
<seb128> and they have broken the abi every second week
<ScottK> You'll update those too, right?
<seb128> I think nothing out of GNOME started using them
<seb128> yes
<ScottK> Cool.
<seb128> ScottK, thanks
<Riddell> I feel unqualified to review linux-mvl-dove, anyone able to tell me what I'm looking for?
<Rubidium_> hi, is a Debian freeze-exception enough to get one for Ubuntu's Maverick release as well? It'd would be just syncing some packages unmodified from Debian testing. I'm personally not using Ubuntu and the last time I installed Ubuntu to make debdiffs they were never used although that was for an after-release CVE vulnerability.
<Rubidium_> http://lists.debian.org/debian-release/2010/09/msg01824.html is the "ack" of Debian's release team and one of the bugs that are fixed is listed in http://qa.ubuntuwire.com/bugs/rcbugs/
<cjwatson> depends - we're later in our release process than Debian is, but it can be possible.  please file sync requests for each one separately (https://wiki.ubuntu.com/SyncRequestProcess) and we'll look at them
<Daviey> Hi release team!  Just as a "heads up", i'm hoping to get one more upload of eucalyptus in tonight... ETA ~2 hours. :/
<Daviey> The package will be ready before then... but trying to test it.. and as it's an upgrade bug.. takes a while to reproduce
<robbiew> Daviey: heh...trying to influence the freeze again, aye? ;)
<Daviey> robbiew, Yeah, can we have the freeze tomorrow instead - then i can go to bed? :D
<superm1> can someone from @ubuntu-release take a look over the ubiquity upload I just did (2.4.4), ideally to make the RC candidate disks?
<superm1> oh there's a bot that does that and lets people know, cool
<ScottK> superm1: Accepted.
<superm1> thx
#ubuntu-release 2010-09-28
<robbiew> one hour left :)
<Daviey> ^^ eucalyptus... and with plenty of time to spare, eh robbiew ? :)
<robbiew> heh...yeah "plenty"
<Daviey> :P
 * robbiew is more interested in seeing if an ubuntu-font package makes it
<stgraber> robbiew: I hope you weren't expecting everything to be built by midnight ? :)
 * Daviey goes home for that day.. thanks :)
<Daviey> robbiew, I thought sabdfl mentioned on a bug that it "might be worth waiting"?
<robbiew> ack...but things change ;)
<Daviey> Have fun.... o/
<Riddell> morning
<ara> good morning!
<Riddell> I'll accept the font
<Riddell> which means CD candidates won't be built for a couple of hours
<ara> Riddell, do you want me to prepare the tracker for RC?
<Riddell> ara: what does that involve?
<ara> Riddell, I mean, just to clean the old milestone, create the new one, change the message. So you can start posting RC images whenever they are ready
<Riddell> ara: yes please
<ara> Riddell, OK, done. Tracker is ready :-)
<smoser> hi all. i've just found https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/649591
<ubot4> Launchpad bug 649591 in mountall (Ubuntu) "mountall spins eating cpu when 'nobootwait' option exists in fstab (affects: 1) (heat: 8)" [Critical,Confirmed]
<smoser> which is somewhat critical.
<Riddell> hmm, gtk failed on all but i386, lovely
<Riddell> cjwatson: able to look at that mountall bug?
<smoser> cjwatson, i can get you (or anyone) access to an instance that demonstrates it, but i have to go to bed.
<ev> Could I trouble whomever is up to look at bug 649597 ?  ubiquity-slideshow-ubuntu 27 is sitting in the queue, and if possible and there's still time left, I'd like to squeeze it into the RC.
<ubot4> Launchpad bug 649597 in ubiquity-slideshow-ubuntu (Ubuntu) "Everything exception request for ubiquity-slideshow-ubuntu 27 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/649597
<ev> assuming we haven't begun spinning CDs
<ev> and there it is :)
<ara> :)
<Riddell> ev: accepted
<Riddell> I wonder if I should be running the publisher manually
<Riddell> sadly, I don't remember how
<ev> Riddell: you rock!
<cjwatson> Riddell: uh, hang on, I just woke up and was dealing with kids
<cjwatson> smoser's investigations certainly have a smoking gun at the end of them.  I'll get you something as soon as I'm vaguely compos mentis
 * Riddell wonders where the release notes draft wiki page should be
<cjwatson> MaverickMeerkat/TechnicalOverview?
<Riddell> yes, thanks
<cjwatson> my current suspicion is http://paste.ubuntu.com/501999/ but I REALLY want to run this through something that isn't my brain for testing
 * cjwatson tries to set up some kind of test harness
<cjwatson> ok, initial test program hangs, good
<cjwatson> mountall fix uploading
<cjwatson> ogra: https://bugs.launchpad.net/bugs/649327
<ubot4> Launchpad bug 649327 in ubuntu-cdimage "OMAP3 preinstalled image lack partition table, bootloaders (affects: 1) (heat: 6)" [Undecided,New]
<cjwatson> that one yours?
<smoser> cjwatson, your fix was removal of the i-- ?
<smoser> as suggested in the pastebin ?
<cjwatson> yes
<smoser> i've got a test program here that passes when that fix applied. but fails otherwise
<smoser> (just some bit of verification)
<cjwatson> it was moving the next option back, but then stepping back when it shouldn't, which took it to the preceding comma; that then infinite-looped because it was repeatedly doing strncmp(...,...,0) which always succeeds
<cjwatson> so I guarded against j being 0 as well, since that happens if e.g. you have a double comma in fstab options
<cjwatson> full fix was http://paste.ubuntu.com/502011/
<cjwatson> smoser: yes, I have a test program here too
<smoser> i can't seem to make it fial with double comma
<smoser> but i'll trust you.
<smoser> thank you cjwatson
<cjwatson> previous code failed here with 'defaults,,comment=cloudconfig'
<cjwatson> the function in question, BTW, is removing mountall's private options before passing them on to mount
<smoser> i'm gonna sleep some.  a job is polling archive for mountall 2.19 and then starting new RC ec2 builds.
<smoser> my code must be buggy then, that string doesn't hang here. http://paste.ubuntu.com/502012/
<ogra> cjwatson, yep, fixed already
<ogra> cjwatson, we just didnt get any image builds due to arch all/any skew
<ogra> cjwatson, was caused by u-boot-linaro-omap3-begale not being in main
 * ogra waits for the archive to settle down to trigger a new build
<cjwatson> smoser: oh, right, it goes round the loop again and does another memmove and then unsticks itself
<cjwatson> I don't know whether that's better or worse.  it has the effect of sanitising the double comma
<cjwatson> I think I prefer being more literal, which is what my 2.19 upload will do
<smoser> so mountall 2.19 will get into archive sometime soon ish ? its in the unapproved queue now.
<cjwatson> awaiting revew
<cjwatson> review
<cjwatson> since Riddell asked me to look at it, I assume he won't spin images without it
<Riddell> accepted
<cjwatson> ta
<cjwatson> some work to do to get the universe even remotely installable I see.
<cjwatson> ... and by the universe I mean main ...
<Riddell> cjwatson: what problems do you see?
<cjwatson> loads of FTBFS, mostly transient
<cjwatson> I'm working through them but it will take a couple of hours to clear everything I'd say, more on powerpc
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html is giant
<cjwatson> mostly that period when libglib2.0-bin was uninstallable completely killed us
<Riddell> yes, powerpc is not happy.  glib and gtk are a pain but I think sorted now for main arches
<cjwatson> not quite
<cjwatson> libgnome, evolution-data-server still to build, libgnomeui can't even start yet
<Riddell> sorry I mean for kubuntu bits which is where I'm starting for the sake of simplicity
<cjwatson> ah, fair enough
<cjwatson> if you want to supervise that I can let you know when the other stuff is ready
<cjwatson> armel is still having trouble with gtkish things
<cjwatson> not quite as far behind as powerpc is
<cjwatson> I must say, qa.ubuntuwire.com/ftbfs is gorgeous these days
 * Riddell runs publisher by hand to get mountall in
<Riddell> hmm, that was suspiciously fast
<Riddell> but no mountall, how do I know when it's able to be published?  seems fine on launchpad https://edge.launchpad.net/ubuntu/+source/mountall/2.19/+build/1978060
<\sh> hmm..regarding my available updates from just now, ubuntu-desktop wants to be removed, including totem*, evince, ubuntu-private-fonts
<cjwatson> Riddell: want me to do it?
<cjwatson> \sh: we know about this on non-i386 architectures, please don't ask about it for a few hour
<cjwatson> s
<Riddell> cjwatson: well am I doing something wrong?
<\sh> cjwatson: k
<cjwatson> Riddell: I don't know, you didn't send the log to the usual file
<Riddell> running  /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.publish-ftpmaster
<cjwatson> did you set LPCONFIG?
<Riddell> ftpmaster
<cjwatson> and did you use the redirections from the crontab?
<Riddell> no
<cjwatson> why not?
<cjwatson> they're really useful
<cjwatson> means that other people can see what's going on
<Riddell> ok I'll mind and do that
 * cjwatson pokes around for mountall
<cjwatson> can you put the publisher log somewhere?
<wgrant> It looks to be at least partly published.
<cjwatson> indeed
<cjwatson> we don't seem to have Packages files for it though
<wgrant> I am having massive packet loss to the UK at the moment, so it will take me a moment to poke around...
<wgrant> I wonder if process-accepted.py ran, but not publish-distro.py.
<wgrant> That almost matches the timing.
<cjwatson> mountall 2.19/{amd64,armel,i386} is in DONE, which is consistent with that theory
<cjwatson> definitely not on disk though
<wgrant> What's the publication status?
<cjwatson> where do I see that?
<wgrant> https://launchpad.net/ubuntu/maverick/i386/mountall
<cjwatson> Pending
<wgrant> Is the last entry Published or Pending?
<wgrant> And can my ISP break their international routing for the third time this evening?
<cjwatson> 2.18 Published, 2.19 Pending
<wgrant> Hm. So it sounds like publish-distro.py didn't get anywhere. Logs would be nice.
<cjwatson> Riddell: not sure what happened, but at this point it's probably most economical to turn the cron job back on and wait for it, maybe?
<Riddell> second run  http://people.canonical.com/~jriddell/tmp/publisher
<Riddell> cjwatson: ok
<wgrant> Err.
<cjwatson> you don't have LPCONFIG set properly.
<wgrant> mkdir: cannot create directory `/srv/launchpad.net/ppa': Permission denied
<wgrant> That's a little suspicious.
<cjwatson> LPCONFIG=ftpmaster-publish
<cjwatson> LPCONFIG=ftpmaster is wrong for this
<cjwatson> be sure to copy things carefully from the crontab
<wgrant> Be glad there were no custom uploads...
<cjwatson> will this have harmed any PPA publications?
<wgrant> Shouldn't have. That's a separate cron job.
 * wgrant looks closer.
<wgrant> It could have gone a little badly if there were d-i or dist-upgrader uploads. But otherwise it broke before it started doing anything on disk.
<wgrant> I wonder why that config is like that, though. It doesn't make much sense.
<cjwatson> it changed a few months back (maybe as long ago as a year?)
<cjwatson> used to share a config with ftpmaster scripts
<wgrant> Yeah, the old copy of the configs I have doesn't have ftpmaster-publish.
<ara> Riddell, do we have an ETA of the first images?
<Riddell> ara: kubuntu live are building now
<ara> Riddell, OK, thanks. And ubuntu?
<ara> after that? or are we waiting for something else?
<Riddell> ara: ubuntu desktop still has a bunch of problems
<ara> Riddell, OK, thanks for the update
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html <- about that far away from working
<Riddell> looks like we're good now on amd64 except vim and those language packs
<seb128> gtk finished building on armel which should fix most of the GNOME issues
<seb128> those were an arch all any mismatch on gtk
<Riddell> yay
<Riddell> didrocks: it's your ISOs you're delaying :)
<cjwatson> seb128: yes, I'm tracking it
<cjwatson> it's not quite that simple as there's libgnome on top etc. etc.
<didrocks> Riddell: ok, getting there it in a couple of minutes :)
<Riddell> doko: OOo not for RC I presume?
<doko> Riddell: yes, when else?
<Riddell> doko: after RC
<Riddell> since we're already making images for RC
<persia> And OOo takes *forever* on some architectures...
<doko> not longer than gtk/gnome
<persia> Fair.
<Riddell> well they got in some hours before the deadline, this is too late whatever timezone we're counting
<cjwatson> telepathy-gabble is dep-wait, is there going to be a new telepathy-glib?  (I hope not for RC though)
<Riddell> seb128: ^^
<chrisccoulson> cjwatson, no new telepathy-glib for RC
<chrisccoulson> i couldn't get the new version to build yesterday (and the current version also won't build with the new vala either)
<Riddell> so the package needs to be removed from the archive?
<cjwatson> ... uh?
<cjwatson> that's unlikely to help matters, there's an old telepathy-gabble which is still good
<cjwatson> if we can get a new telepathy-glib after RC then it should work out OK
<Riddell> that's how much sympathy I have for obscure packages that don't build :)
<cjwatson> Task: ubuntu-desktop, edubuntu-desktop, ubuntu-netbook
<cjwatson> must be some new Kubuntu definition of "obscure" ;-)
<chrisccoulson> i was thinking the same ;)
<chrisccoulson> there's quite a bit of stuff in gnome that uses it
<cjwatson> joking aside it's important that it's resolved one way or another for release
<chrisccoulson> ok, i'll have to find someone who knows more about vala, so they can figure out why vapigen fails to create the bindings now
<didrocks1> Riddell: new unity in the pending queue
<Riddell> do I have to do anything to make EC2 images?
<cjwatson> 09:49 <smoser> i'm gonna sleep some.  a job is polling archive for mountall 2.19 and then starting new RC ec2 builds.
<cjwatson> suggests not
<Riddell> so I have to look out for them appearing somewhere to add to the ISO tracker?
<Riddell> didrocks1: no immediate sign of it
<didrocks> Riddell: ok, just keep me in touch :)
<Riddell> ah, there she is
<Riddell> unity is written in vala?
<Riddell> didrocks: you don't want to keep it as a separate patch, just direct in the .diff.gz?
<didrocks> Riddell: yeah, unity is in vala and upstream is using bzr
<Riddell> ok, accepted
<didrocks> Riddell: so bzr merge is the easiest way to pick patchs in the packaging branch :)
<didrocks> thanks Riddell!
<seb128> Riddell, cjwatson, chrisccoulson: ups sorry about that, telepathy-gabble is the jabber provider for the default im client
<seb128> so yeah we need to fix that after rc
<ara> hey guys, have you experience in Maverick that after using a USB key it is not longer recognized?
<ara> it happens twice (with two differnet usb keys) in the last 10 days
<cjwatson> hmm, the most recent kernel upload is more recent than the most recent debian-installer upload.  I think I should upload debian-installer to sync up.  Riddell?
<cjwatson> (should have spotted this last night, sorry)
<Riddell> mm, fooey
<Riddell> but yeah, go ahead
<Riddell> how do I remove the alternates from the iso tracker?
<cjwatson> Riddell: check them in the main display and press "Disable selection"
<Riddell> oh aye
<Riddell> ah, marjo, I'm to ask you something
<Riddell> Notify Marjo Mercado to begin ReleaseValidationProcess
<Riddell> Notify Marjo Mercado and ask for re-certification on test hardware
<ara> Riddell, what test case(s) should Kubuntu Mobile i386 have?
<Riddell> ara: just live session
<ara> Riddell, OK, sorry, adding it know
<mvo> ara: you did do another upgrade test on the mini9 with dpkg from -updates without any changes in the time, right?
<mvo> ara: its odd, I get similar results on my hdd based system, its a bit scary how slow it is :/
<charlie-tca> Did we build xubuntu RC images for testing?
<ara> mvo, yes, I did
<Riddell> charlie-tca: not yet, we will shortly
<charlie-tca> Thank you
<ara> mvo, one was 10.04.1 directly to Maverick, the other was, 10.04.1 + dpkg from updates -> Maverick
<ara> mvo, both similar times
<mvo> ara: thanks!
<marjo> Riddell, fader: ack on Notify Marjo Mercado to begin ReleaseValidationProcess
<marjo>  Notify Marjo Mercado and ask for re-certification on test hardware
<ttx> Riddell: any ETA for ubuntu-server RC candidates ?
<Riddell> just need to check d-i is in place
<Riddell> building ubuntu-server..
<highvoltage> Riddell: hi! could you perhaps add edubuntu i386/amd64 to http://iso.qa.ubuntu.com/ ?
<Riddell> highvoltage: mm, it's not built
<Riddell> highvoltage: given how broken gnome was when those were built I wouldn't trust them
<highvoltage> Riddell: ah, I'm installing todays image and it seems just fine. perhaps the gnome brokenness is just not all that visible
<Riddell> highvoltage: looks broken to me http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/edubuntu-dvd/20100928/livecd-20100928-amd64.out
<Riddell> ttx: ubuntu-server is up
<ttx> Riddell: thanks
 * Riddell wonders who thought purple was a good idea for unvisited links colour in the new ubuntu cdimage index page
<stgraber> I'm fine having them rebuilt, though live session was fine and the installed system looked ok too ...
<highvoltage> stgraber: it's weird, according to those logs the system you installed earlier should've looked broken, especially if it didn't have edubuntu-artwork or breath-icon-theme installed, and yet it looked fine in your image
<stgraber> ok, found the issue ;)
<Riddell> if the live fs doesn't built it uses an older one
<stgraber> yeah, I just noticed that. I thought it used to fail completely before and wouldn't appear on cdimage
<highvoltage> heh, so much for my recent testing then :)
<ttx> Riddell: I just pushed a change from smoser to the cloud images seed, to restore installation of tasksel in them
<ttx> Riddell: I guess we need to wait for tat to be taken into account before generating the cloud images
<ttx> Riddell: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick/revision/1755
<Riddell> ttx: I guess so but I'm afraid I've no idea how cloud images are made
<ttx> oh, I know how they are made
<ttx> but I suspect we need a germinate run in between
<ttx> which might require a manual push
<cjwatson> you're probably right
<cjwatson> would anyone like to own up to /srv/cdimage.ubuntu.com/debian-cd-2 on antimony and what the point of it is?
<Riddell> cjwatson: oh that'll be me, I messed up with the original
<cjwatson> ttx: no point in the manual push until after the next cron.germinate run
<Riddell> I committed to /srv/cdimage.ubuntu.com/debian-cd
<Riddell> rather than /srv/cdimage.ubuntu.com/bzr/debian-cd  and now they've diverged
<cjwatson> so do I need to fix anything up?
<ttx> cjwatson: when that would be ?
<Riddell> cjwatson: work out how to get /srv/cdimage.ubuntu.com/debian-cd merging happily from /srv/cdimage.ubuntu.com/bzr/debian-cd
<cjwatson> ttx: an hour from now or so
<cjwatson> Riddell: what's wrong with bzr pull --overwrite, if you just want to throw away the inappropriate commits to /srv/cdimage.ubuntu.com/debian-cd?
<Riddell> that sounds promising
<ttx> cjwatson: perfect
<cjwatson> it should never be a merge
<ttx> thanks
<Riddell> cjwatson: let me try
<smoser> ok. i will come back in ~ 1 hour and ask for manual push.
<Riddell> that did the trick, thanks
<Riddell> charlie-tca: you're up!
<charlie-tca> Thanks!
<doko> hi, please could somebody approve new packages / syncs from universe? see bug #642344
<ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 1 other project) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 398)" [High,Confirmed] https://launchpad.net/bugs/642344
<cjwatson> doko: yes, those should be fine.  could you please file a separate sync request for libhibernate3-java using requestsync?  that way I can use our automatic tools to process that one and it's very much less work
<cjwatson> actually, hm
<cjwatson> maybe I can just open a task and nobble sync-helper a bit
<cjwatson> never mind
<seb128> cjwatson, skaet, Riddell: what sort of uploads will you review between the rc and release?
<seb128> is it worth uploading GNOME 2.32 tarball where we have 2.31.92 when changes are only translations and version update to a stable number?
<seb128> tarballs
<seb128> there is a small stack of 2.31.92 to 2.32 updates which have only translations updates
<seb128> the benefit would be to have the translations imported for the next langpack export (though that will probably for -updates later on) and have stable version number which is a minor detail
<seb128> I'm just trying to figure if we should bother uploading those this week or target SRU updates later on
<cjwatson> translations updates to 2.32 should be fine
<Riddell> seb128: I'd be fine with that, it helps upstream with debugging to have a well kent version number
<seb128> ok, we will queue those then, thanks
<kenvandine> i have a "sort of upload" too, gwibber 2.32.0, no change from 2.31.95-0ubuntu2, incorporates the patch included in 2.31.95-0ubuntu2 and the version number bump
<cjwatson> I'm not sure I'd bother with things that are purely version number bumps
<cjwatson> I don't know what sort of buildd contention we're going to have
<kenvandine> i would prefer using the stable version... for bug triaging, etc
<kenvandine> useful
<kenvandine> but certainly nothing urgent
<cjwatson> understood, and you can certainly upload it, but acceptance will be conditional on how much other stuff is going on
<kenvandine> yeah, it is uploaded already
<kenvandine> thx cjwatson
<smoser> <smoser> ok. i will come back in ~ 1 hour and ask for manual push.
<smoser> this is me returning and asking for a manual push of germinate data to fix bug 649833
<ubot4> Launchpad bug 649833 in cloud-init (Ubuntu) "uec images motd suggests tasksel, but tasksel not installed (affects: 1) (heat: 8)" [Medium,Fix committed] https://launchpad.net/bugs/649833
 * Riddell wonders how to do a manual push of germinate data
 * smoser wonders if he's asking for the right thing
<davmor2> Riddell: carefully?
<Riddell> cjwatson: can you enlighten us?
<cjwatson> I'd rather do it ... :-)
<cjwatson> it's pretty delicate
<cjwatson> and I always have to look up the details on the fly
<cjwatson> must submit an LP change at some point to make it easier
<cjwatson> actually, sod it.  the easiest way is simply to accept some leaf package that doesn't matter for the CD builds.  I will find a suitable one and do that.
<cjwatson> I don't like running bits of the publisher manually when I don't have to
<Riddell> highvoltage, stgraber: edubuntu syncing now
<mvo> can someone reject my python-apt upload please?
<seb128> mvo, done
<mvo> thanks seb128
<CardinalFang> Hi all.  I own a proposal to merge desktopcouch 0.6.9-0ubuntu1 to Maverick.  This is a new minor source release to fix two problems:  1) raw couchdb-accessing objects we helped create for clients didn't know how to reconnect when couchdb crashes.  2) Ubuntu One's credentials now use the official Ubuntu SSO OAuth creds, and the old two-legged hardcoded-consumer will no longer work for new accounts.
<highvoltage> Riddell: thank you
<cjwatson> CardinalFang: can it wait until after RC at this point?  We've already started building candidate images
<CardinalFang> cjwatson, I don't wish to cause a respin, so it can wait.  If we find a reason to respin, please do include it the, though.
<CardinalFang> "then"
<cjwatson> Riddell: ^-
<Riddell> got it
<doko> cjwatson: updated bug #642344, working around "main"
<ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 3 other projects) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/642344
<doko> ttx: ^^^
<ttx> doko: I'm ok with it... that's better than not having spring at all, I guess
<ttx> more to push onto JamesPage's java housekeeping natty spec
<doko> ok, thanks
<highvoltage> Riddell: still syncing? I see http://cdimage.ubuntu.com/edubuntu/dvd/20100928.1/ is still quite empty
<highvoltage> Riddell: ah, it's there now :)
<smoser> cjwatson, so how will i knw when that push has been done (for task updates)
<Riddell> highvoltage: these DVDs aren't small
<cjwatson> smoser: apt-get update; apt-cache show tasksel | grep ^Task:
<cjwatson> (it should be done)
<smoser> thanks
<Daviey> Hey!  Just so i understand the process now.. Should debdiff's be on bug reports for ack by the release team... or bake in the queue for review?
<doko> seb128, cjwatson: http://people.canonical.com/~ubuntu-archive/NBS/python-gnome2-desktop
<doko> but even stuff in main depends on it ...
<seb128> stuff in main being one source
<seb128> we can rebuild it after rc
<doko> ok, for python-ubuntuone-client ubuntuone-client-gnome python-gnome2-desktop awn-applets-python-extras this is an alternative dependency
<doko> bzr-gtk labyrinth need to be fixed
<Riddell> Daviey: uploading should be ok
<doko> seb128: could the desktop team take care of?
<Daviey> Riddell, great, thanks
<seb128> doko, it's in universe, could we let that to motus?
<seb128> dinner bbl
<doko> seb128: nbs is not motu stuff, unfortunately
<cjwatson> doko: I filed a bug about labyrinth ... oh, you got there?
<cjwatson> https://bugs.edge.launchpad.net/ubuntu/+source/labyrinth/+bug/648469
<doko> yeah, somewhat faster then the desktop team ...
<ubot4> Launchpad bug 648469 in labyrinth (Ubuntu Maverick) (and 1 other project) "depends on NBS python-gnome2-desktop (affects: 1) (heat: 6)" [High,New]
<cjwatson> accepted, can you close that bug please?
<cjwatson> doko: actually, contrary to what you said above, the MOTU representative in the release team has been mentioning NBS issues for some weeks now
<cjwatson> the other packages listed in http://people.canonical.com/~ubuntu-archive/NBS/python-gnome2-desktop are false positives
<cjwatson> I checked through them all the other day
<cjwatson> well, except for bzr-gtk but that's only a recommends
<cjwatson> still ought to be fixed of course
<doko> ahh, ok
<cjwatson> release team> I meant "release meeting" above
<doko> anyway, both uploaded, can be removed when these are ain the archive
<doko> cjwatson: can I remove packages, if they are only recommended?
<cjwatson> it's probably better to fix it
<cjwatson> bzr-gtk isn't on CDs I think, let me check
<doko> python-gnomeprint can go, if python-gnome2-desktop is gone
<doko> no, all universe
<cjwatson> universe doesn't mean not on CDs
<cjwatson> (since there are non-Canonical-supported CDs)
<cjwatson> anyway, accepted
<ara> cjwatson, the alternate installation takes very very long in kvm, is that expected?
<cjwatson> it hasn't seemed unreasonable to me
<Riddell> ARM images take almost as long to build as DVDs
<cjwatson> how long are we talking about?
<seb128> doko, <doko> yeah, somewhat faster then the desktop team ...
<seb128> doko, not a very constructive comment
<seb128> doko, and no, we don't have the ressources to investigate all the universe ftbfs
<doko> come on, was you reply constructive?
<seb128> how was it not constructive?
<seb128> "no we don't have ressources to investigate universe issues we still have main ones to work on"
<ara> cjwatson, it started one hour ago, and it is on its 65%
<cjwatson> that sounds plausible enough given the ext4 nonsense
<cjwatson> nobody's come up with a decent fix for that yet
<ara> cjwatson, OK, thanks
<ttx> cjwatson: we'll probably need another seed fix for bug 650566
<ubot4> Launchpad bug 650566 in foomatic-db-engine (Ubuntu Maverick) (and 1 other project) "print-server task is not installable on Maverick RC (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/650566
<cjwatson> commit it and I'll find a universe package to push through the queue at the appropriate time
 * ttx is confused by cjwatson's black magic, but doesn't really want to understand
<cjwatson> it's not actually all that complicated
<cjwatson> germinate is run separately from the main publisher, after it
<cjwatson> but the output of germinate is fed back into the publisher, so there's some hysteresis going on
<cjwatson> in practice it always stabilises, but it takes an extra publisher run to do so sometimes
<cjwatson> the publisher only runs for any given suite if it thinks it has something to do
<cjwatson> unfortunately, nothing tells it that it has something to do if the germinate output changes
<cjwatson> one can work around this by stopping the automatic publisher runs and running it with a command-line option to publish a suite anyway
<cjwatson> but it's easier to simply push a random package through so that it has something real to do
<cjwatson> thus, we often like to keep a couple of reasonable but uncritical universe/multiverse packages in the queue during frozen periods, for this purpose
<ttx> cjwatson: makes sense, thanks for the explanation :)
<ttx> will commit I soon as I get serverteam peer review on it
<cjwatson> your proposed change looks fine to me
<cjwatson> foomatic-filters is probably what's actually wanted and foomatic-db-compressed-ppds depends on that already
<ttx> yes, I think this seed could use some refactoring :)
<ttx> will commit then
<ttx> interestingly enough, this was caught early on by the automated ISO testing framework, Hudson-based, that JamesPage and mathiaz have been working on
<ttx> cjwatson: done
<ttx> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick/revision/1756
<mathiaz> hi - I've just upload a fix for eucalyptus to maverick
<mathiaz> and ttx fixed a problem in the seed which lead to cups not working in the installer
<mathiaz> The later will require a -server iso respin
<mathiaz> and I'd like to have the new eucalyptus included in it
<mathiaz> so - could the eucalyptus package be accepted in maverick?
 * ttx eods
<doko> Riddell: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<doko> do you want to seed these?
<cjwatson> doko: please leave those alone
<cjwatson> doko: I temporarily unseeded them to work around uninstallability
<cjwatson> doko: we'll fix it after RC
<doko> ok
<cjwatson> mathiaz: accepting
<cjwatson> (since we have to respin anyway for print-server)
<cjwatson> Riddell: server should be respinnable after the next publisher run or when eucalyptus 2.0+bzr1241-0ubuntu4 binaries are published, whichever is later
<cjwatson> I suspect the binaries won't make it in time for the next publisher, so it might be more like two hours
<mathiaz> cjwatson: thanks!
<GrueMaster> Can someone kick off the armel images?  There is nothing pending in the build queue (i think) and we could use some images.  Or do I need to wait til tomorrow?
 * cjwatson is leaving image spins to Riddell, since he hasn't left instructions
<cjwatson> 20:39 <Riddell> ARM images take almost as long to build as DVDs
<cjwatson> was the last thing he said ...
<NCommander> cjwatson: hate to be a pain, but we need images spun for initial testing on ARM, and the crontab is currently completely disabled since we've stepped into manual mode. Am I allowed to do manual spins for ARM?
<NCommander> ^- or any of the release team
<cjwatson> Riddell is in charge
<cjwatson> and hasn't left instructions, so I don't want to preempt him
<cjwatson> you could SMS him if you're desperate, I suppose
<NCommander> cjwatson: will do
<GrueMaster> It's a timezone thing.  I'm in UTS-8 (PST), and would rather start testing now as opposed to doing nothing today and scrambling tomorrow to test 3 images on 4 systems for Thursday am release.
<Riddell> NCommander: hi
<Riddell> NCommander: I just did kubuntu image on ARM
<Riddell> it says success so I guess that's good
<Riddell> GrueMaster: ^^
<Riddell> http://cdimages.ubuntu.com/kubuntu/ports/daily-preinstalled/20100928/
<GrueMaster> heh.  Well, it's something.  :P
<Riddell> something?  bah, no gratitude around here
<NCommander> Riddell: what are the rules for doing a manual spin. I *really* need Tobin unblocked
<NCommander> Riddell: just poke you or?
<Riddell> NCommander: poking me is good, what do you want next?
<NCommander> Riddell: full set of armel ubuntu-netbook please?
<NCommander> :-)
<Riddell> Calling command: /home/buildd/bin/BuildLiveCD -f ext3 -s omap -d maverick ubuntu-netbook
<Riddell> Calling command: /home/buildd/bin/BuildLiveCD -f ext3 -s omap4 -d maverick ubuntu-netbook
 * NCommander hopes acorn stays up
<NCommander> Riddell: you forgot dove
<Riddell> Calling command: /home/buildd/bin/BuildLiveCD -s dove -d maverick ubuntu-netbook
<Riddell> NCommander: that's two building on acorn now, do we really want that?
<Riddell> or will they block successfully?
<NCommander> Riddell: no, omap4 is on sycamore, omap is on acorn
<NCommander> dove will properly block (at least it should)
<NCommander> (dove is also on acorn)
<Riddell> yes
<GrueMaster> Hrm, someone turned on kubuntu netbook on iso tracker.  And we aren't spinning imx51 images this cycle.
 * GrueMaster will fix
<GrueMaster> or maybe not?
<Riddell> GrueMaster: I disabled imx51
<Riddell> GrueMaster: but otherwise it would be nice to have kubuntu images tested
<GrueMaster> I'm downloading them now.  Almost done.
<Riddell> http://kubuntu.pastebin.com/aAEQ5NFL  well that's not good
<Riddell> NCommander: I killed acorn and sycamore
<Riddell> is that normal?
<NCommander> Riddell: yeah
<NCommander> :-/
<NCommander> Crap
<NCommander> Now we need IS
<Riddell> fooey
<NCommander> Riddell: (I think this is the first time sycamore has ever fallen over however)
<Riddell> NCommander: can you ping IS?
<NCommander> Riddell: I got a live image failure, are you sure the boxes are dead?
<NCommander> Riddell: (also, libgtk upload broke the world :-/)
<Riddell> well didn't it fail because the boxes are dead
<Riddell> I can't ping acorn.buildd
<NCommander> Riddell: your not supposed to be able to AFAIK
<NCommander> Riddell: it'sup, I can telnet to it on port 22
<NCommander> Riddell: I'm investigating why the livefs build fell over, the dependencies look resolvable ...
<NCommander> Riddell: can you re-attempt a armel+dove ubuntu-netbook respin? I think it will succeed now (its grinding steadly away here, and managed to resolve dependencies)
<Riddell> can do
<Riddell> acorn.buildd starting at Tue Sep 28 22:14:57 UTC 2010
<Riddell> Calling command: /home/buildd/bin/BuildLiveCD -s dove -d maverick ubuntu-netbook
<elmo> hey release folks, the cdimage mirrors are close to flatlining again
<cjwatson> removed a couple of slightly-older image directories.  don't know if it will have done much good but may help for a bit.  bedtime ...
<mathiaz> Riddell: hi
<mathiaz> Riddell: do you know if -server isos should be respun now?
<Riddell> let me look
<mathiaz> Riddell: IIUC eucalyptus  Show details     2.0+bzr1241-0ubuntu4  has been published
<mathiaz> Riddell: I don't know if the seed change for cups has also been publish
<Riddell> I don't see the new  eucalyptus on the ftp mirror on antimony yet
<mathiaz> Riddell: ok
<mathiaz> Riddell: can you check if the seed change is available?
<Riddell> ah but eucalyptus is on the ftp mirror on cocoplum
<Riddell> so I think that's ok
<mathiaz> Riddell: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick/revision/1756
<mathiaz> Riddell: ^^ this is what we're looking for to fix cups installation in RC
<Riddell> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/print-server  that still has foomatic-filters-ppds
<cjwatson> the seed change will be fine
<cjwatson> that germinate output is generated less frequently than the archive is published
<cjwatson> you need to look at the Packages files if you want to confirm
<cjwatson> anyway, confirmed, the seed change is available
<cjwatson> (zcat ~/ubuntu/dists/maverick/main/binary-i386/Packages.gz | grep-dctrl -PX foomatic-filters-ppds)
<Riddell> and I can just do   apt-cache show foomatic-filters-ppds | grep Task
<cjwatson> yes
<cjwatson> it's probably only just been published if I'm doing my maths right, might not be on external mirrors yet
<Riddell> building server
<cjwatson> but cdimage should see it fine
<cjwatson> actually, no, wrong maths, the seed change will have been published an hour ago
<Riddell> mathiaz: do you care about ports?
<mathiaz> Riddell: ports == non amd64, i386?
<Riddell> mathiaz: yes
<mathiaz> Riddell: nope - I don't care about ports
<mathiaz> Riddell: -server isos are actually not tested (even build?) for non-{amd64, i386}
<cjwatson> they're built
<cjwatson> quite useful to have fairly minimal ISOs for all architectures
<cjwatson> well, the ISO isn't minimal, but the default installation from it is, I mean
 * mathiaz nods
<mathiaz> Riddell: what's the impact of waiting for ports?
<mathiaz> Riddell: ie - how long?
<Riddell> mathiaz: ports are done separately so it doesn't affect the main builds
<mathiaz> Riddell: ok - could spin a -server iso build for amd64 and i386 now that eucalyptus and the seed fixes are published?
<GrueMaster> We don't test server on armel, so don't bother trying.
<Riddell> mathiaz: -server is building
<mathiaz> Riddell: o^5 - Thanks!
<GrueMaster> nevermind.  Apparently persia wants them.
<Riddell> there's always one who has to be difficult :)
 * NCommander hopes now that we're reaching the point that we can eventually retire the ports/mainline architecture distinction
<NCommander> */dream*
<Riddell> I'm rather amazed that sparc images still get built
<NCommander> Riddell: they aren't
<NCommander> We have some stale ones though tha tI keep forgetting to euthanize
<Riddell> they get built every day, I doubt the contents are very up to date
<NCommander> Riddell: .....
<NCommander> Riddell: no they aren't
 * NCommander just rechecked
<Riddell> what's this then? http://cdimage.ubuntu.com/ports/daily/20100928/
<GrueMaster> 21-aug-2010
<NCommander> :-)
<Riddell> mmm
<Riddell> ok, you win
<NCommander> :-)
<NCommander> Riddell: feel free to remove them
#ubuntu-release 2010-09-29
<Riddell> hum, well server is built but is failing to appear at http://cdimage.ubuntu.com/ubuntu-server/daily/20100928.2/
<Riddell> I wonder if that's the mirrors full up
<Riddell> ooh there it is
<Riddell> mathiaz: images up http://cdimage.ubuntu.com/ubuntu-server/daily/20100928.2/
<mathiaz> Riddell: \o/ - thank ya!
 * stgraber just noticed this morning's -meta change including the ubuntu font ...
<stgraber> I'll be pushing a new edubuntu-meta change refreshing our dependencies to include it
<Riddell> is it really that important?  it's not set as default or anything
<stgraber> well, currently it means that our DVD has it in the live environment as we derive from Ubuntu but installing from a minimal system won't because edubuntu-meta is out of sync
<stgraber> so I don't really care having it or not, I care about inconsistent installations
<ScottK> stgraber: Is gcompris on your ISO?
<stgraber> ScottK: yes
<ScottK> stgraber: You might see about getting it moved from the ubuntu-desktop packageset to yours (since it's in Universe).
<Riddell> stgraber: ok as you wish
<stgraber> ScottK: that's weird, it was in our packageset for karmic then was apparently moved to ubuntu-desktop with lucid.
<stgraber> cjwatson: ^ any chance you can fix that when you have a minute ?
<stgraber> Riddell: I just checked and we won't need a meta package update as edubuntu-desktop simply depends on ubuntu-desktop solving all of our issues ;) For some reason I didn't remember that part of the magic.
<Riddell> phew
<NCommander> Riddell: what happened to my dove image?
<Riddell> NCommander: still going
<mathiaz> Riddell: hm - seems that -server isos have disappered
<mathiaz> Riddell: 20100928.2 is no longer available from http://cdimage.ubuntu.com/ubuntu-server/daily/
<Riddell> umm
<Riddell> spooky
<Riddell> mathiaz: they're still there on antimony but maybe they're not on one of the mirrors
<Riddell> elmo did say they were getting full
<mathiaz> Riddell: ok
 * mathiaz hopes they'll show up eventually
<NCommander> Riddell: very slow :-/
<Riddell> NCommander: yes, and I need to go to bed now
<Riddell> mathiaz: I'm copying the images over to http://jasmine.19inch.net/~jr/tmp/ubuntu-server/ incase you need them now
<mathiaz> Riddell: I won't need them now
<mathiaz> Riddell: it would be great if they can show up in a couple of hours
<Riddell> NCommander: going to sleep now, feel free to kill the process if it doesn't get done soonish
<NCommander> Riddell: k
<maxb> Hi, Bazaar in maverick is 2.2.0. 2.2.1 is released, with some fairly important bugfixes. Can you advise if we should aim for a SRU or a (very) late-breaking release pocket upload? (pitti suggested the latter in bug 636930, but that was some days ago, so may no longer be valid)
<ubot4> Launchpad bug 636930 in bzr (Ubuntu Maverick) (and 4 other projects) "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affects: 5) (dups: 4) (heat: 288)" [Undecided,Triaged] https://launchpad.net/bugs/636930
<ScottK> maxb: Since it's eligible for post-release micro-version update, I don't see a strong reason to wait.  If all the same testing is done as for a post-release update, I think it would be reasonable to drop it in between RC and final.
<maxb> Right, that makes sense
<mathiaz> ScottK: IIUC accepting bzr would require an ISO respin
<ScottK> mathiaz: That's why I said after RC.
<ara> good morning!
<ara> Riddell, morning
<ara> Riddell, rekonq is crashing for me in kvm, is that known?
<ara> seb128, as RAOF has confirmed that it is a mesa issue, I think we should add it to the release notes for RC
<Riddell> ara: not known to me
<ara> Riddell, OK, thanks, I will file a bug
<ara> Riddell, bug 650934
<ubot4> Launchpad bug 650934 in rekonq (Ubuntu) "Rekonq crashes in a KVM with 800MB ram (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/650934
<cjwatson> stgraber: hm, this is odd, can't immediately figure out why it went to desktop ...
<cjwatson> ubuntu-desktop I mean
<cjwatson> germinate shows it in edubuntu/desktop-gnome, edubuntu/desktop-kde, edubuntu/ubuntu-edu-preschool, and edubuntu/ubuntu-edu-primary
<Daviey> Hey!  What are the chances of a respin happening before RC?  We don't need one, but wondered if foundation are likely to call one.
 * cjwatson hasn't heard of a reason right now
<cjwatson> not globally anyway, edubuntu might need one
<Daviey> ok great, the current situation with the server seems to be pretty sound.  The only edge case of concern is people using the on cd archive to upgrade UEC, will get a silent failure.  There is a work around for this, if we had a respin it would close this edge case - but not worth making a new ISO for that IMO.
<Daviey> (new installs are unaffected)
<cjwatson> what package is the workaround in?
<Daviey> eucalyptus-java-common, has been fixed to stop euca' before attempting to upgrade the database.  The work around, would be a copy and paste # stop eucalyptus ; do-upgrade() ; start eucalyptus, after reboot
<Daviey> (database schema upgrade is handled in packaging)
<cjwatson> did we not respin after that fix last night?
<cjwatson> maverick-server-amd64.list:/pool/main/e/eucalyptus/eucalyptus-java-common_2.0+bzr1241-0ubuntu4_amd64.deb
<cjwatson> maverick-server-i386.list:/pool/main/e/eucalyptus/eucalyptus-java-common_2.0+bzr1241-0ubuntu4_i386.deb
<cjwatson> eucalyptus-java-common | 2.0+bzr1241-0ubuntu4 |      maverick | amd64, armel, i386, powerpc
<cjwatson> all in sync
<Daviey> ahh, sorry - i was mistaken
<Daviey> i didn't realise there was a new spin last night
<cjwatson> there was some difficulty pushing to cdimage mirrors I think
<cjwatson> let me see if that's resolved
<cjwatson> looks ok, you want 20100928.2
<Daviey> cjwatson: so, the server team should be considering 20100928.1 as the RC candidate?
<cjwatson> .2
<cjwatson> surely?
<Daviey> that isn't on cdimages.*
<cjwatson> it is on some of them
<cjwatson> I just checkd
<cjwatson> +e
<Daviey> ahh
<cjwatson> (p.s. official name is cdimage.ubuntu.com not cdimages)
<cjwatson> it's also on the ISO tracker
<cjwatson> ok, so I just deleted a pile of older builds; let's see if that helps cdimage pick it up
<cjwatson> try it again in a few minutes?
<Daviey> cjwatson: rockin' thanks.
<Daviey> So, when .2 shows up - we will spend today doing some pre-RC testing.
<cjwatson> stgraber: wow, that was more complicated than I expected it to be, but fixed now
<cjwatson> stgraber: you gained edubuntu-live as well in the same process
<cjwatson> and ubuntu-desktop lost those two and language-pack-kde-*, which is obviously correct anyway
 * ogra would appreciate an armel rebuild ... i assume the archive should be setteled by now 
<Riddell> NCommander, GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100929/
<NCommander> Riddell: yup, saw, thanks. Already did a successful test install :-)
<cjwatson> robbiew: we're due an EOL announcement for jaunty soon, aren't we?  https://wiki.ubuntu.com/EndOfLifeProcess
<cjwatson> ah, heh, I see you edited https://wiki.ubuntu.com/EndOfLifeAnnouncement recently so I guess you know ...
<ScottK> IIRC it went out a few days ago.
<ogra> Riddell, thanks a lot
<Riddell> ogra: you're welcome.  what did I do?
<ogra> roll ne images :)
<ogra> *new
 * ogra was waiting to test the new bootloader on omap3
<smoser> cjwatson, or slangasek could you populate iso tracker from http://uec-images.ubuntu.com/server/maverick/20100928.4/published-ec2-daily.txt
<smoser> and also list 20100928.4 as the uec images to be tested.
<cjwatson> smoser: done and done
<ScottK> cjwatson: Does x-loader belong in some package set (I find it unusual to see packages in Main that don't)?
<smoser> gracias.
<cjwatson> ScottK: how odd.  it *ought* to be in core
<cjwatson> oh, eek
<cjwatson> ScottK: thanks, nasty bug - it was using the i386 Packages file regardless of architecture, I think
<ScottK> cjwatson: You're welcome.
<ScottK> Convenient of wgrant to put the package sets on the package acceptance page so the lack would be there staring at me.
<doko_> ok to sync http://packages.debian.org/changelogs/pool/main/libd/libdbd-sqlite3-perl/current/changelog ? fixes ftbfs
<ScottK> doko_: Did your ucf update get resolved?  I just went looking for the FFe bug and couldn't find it.
<doko_> ScottK: it was ufc
<doko_> anyway, not needed
<ScottK> That would explain why I couldn't find it.  OK.
<ScottK> doko_: It's in Main, so it needs to wait until after RC.
<ScottK> (after that, it looks good)
<cjwatson> ScottK: how exciting.  http://paste.ubuntu.com/502618/
<cjwatson> I'm going to apply that as it looks basically correct - TBH if the Ubuntu Studio guys want to fix ia32-libs they're welcome to it :-)
<ScottK> Absolutely.
<persia> Quite possibly the fix there will lead to work to drop that from Ubuntu Studio again.
<ScottK> cjwatson: The correction to the package set already shows up on the LP package accept page.  Very nice.
<cjwatson> ScottK: yep, seems to be immediate, which is good
 * Riddell out for a bit
<ScottK> There's a reasonable stack of Universe syncs in the queue if anyone has time to look ...
<ScottK> Is it known/on purpose we have a newer mountall in the archive than is on the Kubuntu live CD (i386)
<ScottK> Riddell: ^^^?
<doko> skaet: what is wrong with keeping bug #635891 open for natty?
<ubot4> Launchpad bug 635891 in lprof (Ubuntu Maverick) (and 3 other projects) "libvigraimpex (main) build-depends on hfd5 (universe) (affects: 1) (heat: 188)" [High,Fix released] https://launchpad.net/bugs/635891
<skaet> doko,  was just assigning it.
<skaet> making sure it was on someone's monitoring list,   for writing release notes,  if its not going to be fixed.
<persia> skaet, Isn't it better to do that with a release-notes task?
<persia> That way it shows up in https://bugs.launchpad.net/ubuntu-release-notes
<persia> (and we can track when it gets release-noted separately from when it gets fixed)
<skaet> persia,  will be doing that too.
<skaet> just changed the assigned to field to be the desktop team, from unassigned.
<doko> need somebody to approve for bug #642344 tiles (unapproved) and mvel2 (new), new upstream version just taken and renamed from debian
<ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 3 other projects) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/642344
<ScottK> doko: I just approved tiles.
<doko> ScottK: then you have to approve mvel2 too =)
<ScottK> OK
<stgraber> cjwatson: thanks (for the packageset change)
<ScottK> doko: I'll have to look at New tonight or tomorrow, but seems fine.
<doko> ScottK, cjwatson: would be nice to have it built tomorrow morning/noon my time. still doing the manual bootstrap with #is
<ScottK> OK. Will try.  If some else gets to it first, I won't mind.
<doko> hmm, why doesn't my grace upload show up?
<ScottK> doko: It's in the queue, but it's in the Xubuntu packageset, so not accepting until after RC.
<doko> ahh, ok
<doko> ScottK: what about drizzle, will it be removed? just asking for NBS ...
<ScottK> Yes.
<ScottK> Upstream decided they'd rather ship nothing at this point and I think we aren't going to disagree.
<ScottK> There's a removal bug pending.
<CardinalFang> I have a question about our current release state.  The "unapproved" queue has close to 40 items in it.  Is "approved" frozen while we make RC images or something like that?
<persia> CardinalFang, For anything that lands on an image undergoing validation, yes (unless the image fails validation and the release team for that image needs a specific package for a respin)
<CardinalFang> persia, okay.  I (=Online Services) care about two packages in the "unapproved" queue.  I don't know what I should be doing now.  Waiting, perhaps?
<persia> Which packages?
<ScottK> CardinalFang: Unless it rises to the level of "We should not release the RC unless we fix this", waiting is appropriate.
<CardinalFang> persia, ubuntuone-client, desktopcouch .
<persia> Yeah, those need waiting.
<CardinalFang> ScottK, I don't think we should stop RC, no.
<persia> CardinalFang, If it was some package that wasn't used on any image, and you had a really good reason, you could beg, but those appear on images.
<ScottK> Stuff that's not in Main or seeded on an image, I'm pushing through, so those wouldn't be waiting.
<persia> Ah, with that information, yes no need for package names to reach a conclusion :)
<CardinalFang> persia, okay, I guess my only question is, wait for what?  What happens next for me?
<CardinalFang> I guess I fear being asleep when someone asks a question about them.
<persia> Wait for RC to be released.
<CardinalFang> persia, okay.  Sorry for sounding neurotic.
<ScottK> doko: mvel2 source accepted.
<doko> ScottK: thanks
<Riddell> ScottK: hmm, no I didn't see that it had the old mountall
<Riddell> cjwatson: just how serious is that mountall bug?
#ubuntu-release 2010-09-30
<Riddell> slangasek: should I be pre-publishing images now?
<slangasek> Riddell: if you have good images, then yes :)
<Riddell> slangasek: so I do  for-project .. publish-release .. poolonly to pre publish?  then what do I do tomorrow to publish them?
<Riddell> charlie-tca: ok to publish xubuntu images?
<Riddell> stgraber: ok to publish edubuntu images?
<stgraber> Riddell: yep
 * robbiew probably should work on a release announcement, huh?
<Riddell> robbiew: https://wiki.kubuntu.org/MaverickMeerkat/RCAnnouncement would be a start
<robbiew> yeah...I think skaet started it already
<Riddell> I started that
<robbiew> oh...Riddell did
<robbiew> :)
<Riddell> where's rick to sign off on ubuntu images?
<robbiew> will need to update https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview as well
<Riddell> yes indeed
<Riddell> jiboumans: ok to publish ubuntu server images?
<robbiew> Riddell: I don't believe they need to sign off on the images
<robbiew> they = rick and jos
<robbiew> if the ISOs cleared the isoqa process, then they are good to go
<Riddell> I'm going by https://wiki.kubuntu.org/MaverickMeerkat/ReleaseManifest, there's a few failures on ISO tracker so I wouldn't say that counts as cleared
<Riddell> e.g. http://iso.qa.ubuntu.com/qatracker/test/4564 has two failures on live session and one on wubi
<robbiew> aye
<robbiew> Riddell: well you might not get a response from either today :/
<slangasek> Riddell: tomorrow you run publish-release again with 'yes' instead of 'poolonly'
<Riddell> slangasek: for each of the classes of image?
<slangasek> for all images that belong on releases.u.c
<Riddell> yep
<slangasek> and you'll want to make sure you stow the beta images away in ../old-images/ before you start publishing with 'yes', otherwise bits go awol
<Riddell> slangasek: is that just done by hand?
<slangasek> sadly, yes
<Laney> 30/09 00:51:16 <sarah_pearce16> shes gonna het off with some fitty then
<Laney> >> (30/09 00:51:18) (Laney[+Ris]) (39:sarah_pearce16)
<Laney> >> (1=1 |#crumbs    2=2 |#php       3=3 |#short.bus 4=4 |#haskell   5=5 |#toast~ers 6=6 |#debian-uk 7=7 |#relax     8=8 |#deb~n-cli 9=9 |#agda
<Laney> >> (0=10|#ubu~lease q=11|#ubu~-motu w=12|#ubu~devel e=13|#ubuntu-uk r=14|#epigram   t=15|&bitlbee   y=16|#ubunt~ing u=17|#debian    i=18|#debi~evel
<Laney> argh
<Laney> multitouch + x clipboard = bad combination
<ajmitch> Laney: it's an entertaining combination though
<Laney> I accidently paste things so often, it's pretty shameful really
<Riddell> slangasek: for publishing on cdimages I use "named" in the command?
<slangasek> Riddell: correct
<Riddell> slangasek: what happens if I use "no"?
<slangasek> Riddell: then you get images published with naming in the style of alphas (i.e., without the release version in the filename)
<Riddell> ok, not what I want then
<Riddell> slangasek: what do I have to do to publish wubi (if anything)?
<slangasek> Riddell: that's not part of the RC checklist, is it?  I don't know that we "release" wubi until the end
<slangasek> Riddell: but the process is to grab the URL returned by 'find-live-filesystem i386 wubi' and wget that into the release dir
<slangasek> (and call it 'wubi.exe', or something else sensible)
<Riddell> I'd have thought RC was ment to follow the final release as closely as possible, isn't it ment to be a practice run?
<slangasek> that's not how I understand it
<slangasek> there's lots of other stuff happening on release day that we don't go through for the RC - the RC is really just a last test of the archive+images before the point of no return
<persia> It's also an extra good excuse to make developers get their heads out of random code and remember that a release is happening, and they have to fix that niggling bug *NOW*
<ScottL> Riddell, were you asking about ubuntu studio publication?
<ScottL> i think we should be good :)
<Riddell> ScottL: I was
<ScottL> Riddell, is there anything specifically you needed?
<Riddell> https://wiki.kubuntu.org/MaverickMeerkat/ReleaseManifest says I need LuisdeBethencourt to sign off, but if you can prove you're also responsible for it that's good
<ScottL> Riddell, i do not think you will get his sign off ;)  i am current project lead however, you can validate that with persia and themuso if necessary
 * persia hunts up the email to ubuntu-release
<persia> Oh, u-d-a actually: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-September/000766.html
<Riddell> persia: do you trust this guy?  or is he just a one bit shift plageriser of ScottK? :)
<persia> ScottL, You should probably update the wiki
<persia> Riddell, I trust ScottL
<ScottL> persia, i shall update the wiki later tonight (kids are acting up)
<ScottK> Actually someone other than ScottL should update the wiki.
<persia> (and yes, nick-completion gets useless at that level of similarity)
<persia> ScottK, Who ought it be?
<Riddell> I can update the wiki
<ScottK> Excellent.
<ScottL> Oustanding
<persia> Great!
<ScottL> err. Outstanding ;)
<ScottK> persia: I don't think people should be self-appointed to the release manifest.
<persia> ScottK, We probably ought formalise that then, as we've historically mostly self-appointed release manifest entries when we added them.
<persia> I agree with your point, but it needs documentation, review by appropriate teams (ubuntu-release?  TB?), announcement, etc.
<ScottK> persia: I don't know that it has to be a formal rule, just a best practice.
<persia> That's easier to implement :)
<ScottK> persia: The release delegations are different than ISO signoff in any case.
<ScottK> (re your earlier comment)
<persia> Ah, that's my failure in not being familiar enough with the release approval process then.
<persia> (both in referencing that, and in not ensuring that ScottL was listed there previously)
<ScottK> We'll survive.
<Riddell> slangasek: the .pool directories look good, I presume I use sync-mirrors to push them out?
<slangasek> Riddell: yep
<Riddell> syncing
 * Riddell snoozes
<skaet> Riddell,  around?
<persia> skaet, he claimed to be snoozing about 270 minutes ago: he's probably still doing so :)
<skaet> heh, spotted that, but he wasn't marked away, so figured I'd check.  :)
 * skaet figures its time for her to go sleep too,  it can wait until the morning.   
<persia> Won't hurt to leave a contentful ping, and check your backscroll in the morning... :)
<persia> (plus someone else might have the data you seek)
<skaet> Thanks persia,   I sent a long email a while ago now,  mostly its just trying to sort out who'll do what tomorrow between him, Robbie and myself ;)  The TechnicalOverview needs some love on its release notes for the known issues.
<persia> GIven your timezone, I suspect you'll end up with whatever isn't already done when you get up :)
<skaet> lol, yup.
<ara> good morning all!
<Riddell> charlie-tca: ping, xubuntu sign off needed
<Riddell> jiboumans: ping, server sign off needed
<didrocks> weird weechat doesn't save anymore channels on closeâ¦
<Riddell> well it's only wee, next time try mucklechat :)
<mvo> could someone please reject my foomatic-gui upload? it appears that needs a bit of clarification with till first
<seb128> mvo, done
<mvo> thanks seb128
<Riddell> ogasawara: please check kernel info on https://wiki.kubuntu.org/MaverickMeerkat/TechnicalOverview
<ara> Riddell, pointing to the kubuntu wiki, uh? :)
<ara> Riddell, in known bugs thare are some from last milestone
<Riddell> ara: I think didrocks is making some edits, please coordinate with him to get them updated
<didrocks> will release the lock shortly
<ara> Riddell, shouldn't be skaet doing that? or the one acting as RM
<ara> who is in charge?
<Riddell> yes skaet said she could do it too
<didrocks> done for me
<doko> please accept lash, if possible
<persia> It's in the Studio set.
<doko> ahh, ok
<persia> doko, Generally https://launchpad.net/ubuntu/maverick/+queue?queue_state=1&queue_text= will show if stuff is in a set (use queue_text if the list is too long)
<cjwatson> Riddell: mountall 2.19 is serious for cloud, nice-to-have for everything else
<Riddell> good, thanks
<cjwatson> Riddell: do you know about publish-image-set.py in lp:ubuntu-archive-tools?
<cjwatson> Riddell: it doesn't run them for you, but it saves having to come up with all the publish-release commands by hand
<Riddell> cjwatson: I did not
<cjwatson> pitti wrote it for alpha-3 or so, and I polished it a bit for beta; it's not quite there yet but it's a heck of a lot easier than byhand
<cjwatson> hah, bet it doesn't know about "RC" mind you ...
 * cjwatson goes to fix it
<Riddell> doesn't look like it
<cjwatson> fixed
<Riddell> is this a bad sign "Making armel+omap zsync metafile ... too long between blocks (try a smaller block size with -b)"
<Riddell> ok images all in place except those omap ones which zsync breaks on
<Riddell> cjwatson: any idea what that's about?
<Riddell> now we just need sign off from server, the ubuntu website people to do whatever the ubuntu website people need to do, publish, announce
<Riddell> beasties still need updated on https://wiki.kubuntu.org/MaverickMeerkat/TechnicalOverview
<Riddell> ogasawara needs to update linux version numbers too
<cjwatson> uh, I vaguely remember having to do some weird stupid thing with zsync
<Riddell> curiously the kubuntu omap images published fine
<cjwatson> let me poke about a bit before I answer
<Riddell> but ubuntu-netbook and kubuntu-mobile broke
<cjwatson> which exact command?
<cjwatson> (s)
<cjwatson> actually never mind, I'll just see if I can make it cope in general
<Riddell> ARCHES='armel+omap armel+omap4' for-project ubuntu-netbook publish-release ports/daily-preinstalled 20100929 preinstalled-netbook named rc #FAILED
<cjwatson> try it again now
 * Riddell tries
<Riddell> "too long between blocks (try a smaller block size with -b) Trying again with block size 2048 ..."  clever :)
<cjwatson> still a zsyncmake bug, but there you go
<ScottK> slangasek: I'd appreciate it if you would have a look at the kdebase-workspace upload in queue (it's a one line change to it's upstart script).  The rationale sounds reasonable and the code does what the rationale says, but i have no idea if it's the right idea.
<smoser> Riddell, publish of ec2/uec images is done from nectarine.canonical.com
<smoser> cjwatson also has acl
<smoser> documented at https://wiki.ubuntu.com/UEC/Images/Publishing
<Riddell> hmm
<Riddell> well I don't seem to have access to nectarine
<Riddell> cjwatson: can you publish the UEC images?
<cjwatson> yeah
<cjwatson> what build id?
<cjwatson> 20100928.4?
<smoser> are we ready to push go ?
<smoser> if so i can do it
<smoser> or we can let cjwatson
<smoser> also for uec images i have to update AMI pages on amazon, which i can/will do
<cjwatson> I probably ought to learn how to do it
<smoser> yeah.
<smoser> ok.
<smoser> well, i'm kind of here. if you fall over.
<smoser> i've already pre-published that image. i dont think you've ever been shared aws login info to do "Updating Amazon Pages"
<cjwatson> so I run 'sudo -u vmbuilder /home/vmbuilder/bin/cronrun promote-daily rc /srv/ec2-images/server/maverick/20100928.4', yes?
<cjwatson> I'm probably best off not trying to do the amazon update
<cjwatson> oh, I add --make-public?
<cjwatson> so 'sudo -u vmbuilder /home/vmbuilder/bin/cronrun promote-daily --make-public rc /srv/ec2-images/server/maverick/20100928.4'?
<cjwatson> (awaiting ack before pressing enter)
<smoser> verifying
<smoser> vbcron promote-daily release /srv/ec2-images/server/maverick/20100928.4/ --verbose --make-public
<smoser> oh. and vbcron is just sudo -u vmbuilder (in ~vmbuilder/bin)
<smoser> so yeah.
<smoser> hit enter
<cjwatson> you had 'release' not 'rc'?
<smoser> oh carp
<smoser> i did.
<smoser> we need to run with 'rc'
<cjwatson> does it require any kind of cleanup of the previous publication?
<smoser> i'll handle that. its all public
<smoser> err... private
<nhandler> Looks like Omg Ubuntu! has already announced the RC
<cjwatson> should I let you do this at this point? :)
<smoser> yes. i'm sorry. i can't believe i did that.
<ajmitch> nhandler: someone has to jump the gun :)
<wgrant> Slashdot always announces the release several hours early.
<smoser> ok. cjwatson i just started: vbcron promote-daily --make-public rc /srv/ec2-images/server/maverick/20100928.4 --allow-existing --verbose
 * cjwatson nods and logs out :)
<smoser> it will take like 3 hours :-(
<smoser> at least the last one did.
<smoser> and worse, its largely network bandwidth bottlenecked
<elmo> smoser: who's bandwidth?
<elmo> whose
<smoser> outbound from canonical
<smoser> well canonical -> aws
<smoser> obviously its not saturated, but i don tthink that a release grab is going to help it.
<elmo> smoser: if this is nectarine, you're on a link that's essentially unaffected by RC or anything else
<smoser> oh. it is nectarine.
<ttx> Riddell: I'm ok with RC
 * cjwatson leaves a comment on behalf of the release team on the omgubuntu page
<Riddell> ttx: thank, I'll publish those then
<cjwatson> I don't imagine slashdot will ever change their spots but at least omgubuntu could do better
<ttx> I'm having problems with that conference connection
<ttx> smoser/Daviey: you can confirm for me
<Riddell> I don't see it on slashdot
<smoser> ttx, ?
<ttx> smoser: that RC is "ready to ship" for you
<Daviey> ttx: confirm?
<smoser> well, no.
<smoser> it was ok.
<smoser> but we're a couple hours away now.
<smoser> as i fat-fingered the pre-publish yesterday
<Riddell> smoser: for the normal server images, not cloud
<ttx> smoser/Daviey: Riddell has been asking me if I could signoff for RC
<ttx> smoser/Davieyyou know ths situation better than I do
<ttx> and that flaky connection can go down any time
<Daviey> ttx: Yes.. it's looking good.
<Daviey> ttx: Nothing major has arisen with the pre-rc tests
<cjwatson> in mdz style I am slightly spooked by the lack of need for last-minute respins
<ttx> cjwatson: that's because you rock :)
<ttx> smoser/Daviey: great
<Riddell> wow, those omgubuntu people are cheeky
<smoser> ok. i have to get away from the machine for a bit.  the publish will be done when it is done.
<Riddell> "perhaps you should work _with_ us" it's not like we're hard to find if they want to ask
<smoser> and it will update: http://uec-images.ubuntu.com/query/released.latest.txt
<ScottK> Riddell: After they published a screed about how awful Ubuntu devs were, I decided I wasn't interested in them anymore.
<Daviey> Maverick is looking better that i expected :)
<Riddell> didrocks: gnome version numbers still don't match https://wiki.kubuntu.org/MaverickMeerkat/RCAnnouncement
<smoser> so anyone interested can just : while sleep 10m ; do wget http://uec-images.ubuntu.com/query/released.latest.txt | grep "maverick.*rc" && mpg321 NarwhalsNarwhals.mp3; done
<ScottK> Low expectations will do that for you.
<didrocks> Riddell: sorry, should have forget to save the edit, fixed.
<Riddell> so now we need skaet or someone to update the bugs on https://wiki.kubuntu.org/MaverickMeerkat/TechnicalOverview, ogasawara to fill in her version for the linux bit, newz to copy it over to the ubuntu website
<ttx> Riddell: if you don't need me anymore, I'll disappear again
<Riddell> ttx: thanks, you can go
<ttx> Riddell: thank you for a smooth milestone release !
<Riddell> and they're all on the wrong side of the planet so I guess we have to wait
<Riddell> or I could just assume the announcement is ok, ignore the ubuntu website and announce
<Riddell> that's what I would do if I was an omgubuntu editor :)
<didrocks> :)
<ogra> where is the known issues page template ?
 * ogra wants to check that all notes made it from the bugs to that page
<ogra> Riddell, ? ^^^
<Riddell> ogra: bottom of https://wiki.kubuntu.org/MaverickMeerkat/TechnicalOverview
<ogra> thanks
 * ogra cross checks
<ogra> can i edit there ?
<ogra> its all blue !
<ScottK> You can.  We allow it.
<ogra> heh
<ScottK> ;-)
<ScottK> Riddell: Can I start reviewing/accepting seeded packages from the queue?
<ScottK> (normally once we're into publishing that's OK)
<ogra> hrm
 * ogra would edit if he could log in ... seems to be some heavy load on the wiki atm
<Riddell> ScottK: aye go for it
<ScottK> OK.  Thanks.  I'll work doko's NBS stuff.
<cjwatson> Benjamin Humphrey got in touch with me by /msg as requested, but when I replied eight minutes later he'd already /quit ...
 * cjwatson sighs
<ScottK> Sigh.
<ScottK> lamont: Why are all the i386 buildd's on manual?
<ScottK> Is there an estimated time they'll be back?
<wgrant> You'd think that news sites could, you know, check the website.
<ara> skaet, hello, are you around?
<ScottK> wgrant: That's not a recipe for being first.  You have to have proper priorities.
<Riddell> ara: skaet seems to still be asleep
<Riddell> I've announced on kubuntu.org but the ubuntu e-mail announce will probably need to wait for her
<ara> Riddell, but there are some bugs on the release notes that are already fixed
<Riddell> ara: yes that's what I'm waiting to be updated
<ara> Riddell, i.e. bug 628681
<ubot4> Launchpad bug 628681 in ubiquity (Ubuntu Maverick) (and 1 other project) "Kubuntu OEM did not install oem-config-kde (dup-of: 628290)" [High,Triaged] https://launchpad.net/bugs/628681
<ubot4> Launchpad bug 628290 in ubiquity (Ubuntu Maverick) (and 1 other project) "OEM installation, missing "Prepare for shipping to end user" icon (affects: 2) (dups: 2) (heat: 167)" [High,Fix released] https://launchpad.net/bugs/628290
<ara> Riddell, OK, no worries, I'll talk to her when she's around :)
<ScottK> Riddell: We're going to have trouble moving these post-RC builds through with no i386 builders.  Perhaps you could have a poke at IS and find out what's up and when we can expect to have them back?
<ogra> ScottK, i'm happy to share the arm ones (though we would have to delay the release i guess ;) )
<cjwatson> I can chase it
<ScottK> Heh. Probably.
<elmo> ScottK: that was Ng
<ScottK> cjwatson: Thanks.
<elmo> he's doing the bootstrap
<elmo> that you guys asked for - he should only be a couple  more minutes he says
<ScottK> OK.
<ScottK> cjwatson: ^^^ mystery resolved.
<cjwatson> ah, normally bootstraps don't require taking all the buildds down for more than a few moments
<cjwatson> the procedure I remember is "stop buildds, get nominated buildd to accept package you want, re-enable them all"?
<elmo> cjwatson: essentially, yes
<lamont> cjwatson: yep.  and wait for it to fetch and at least start unpacking the buildd
<lamont> s/buildd$/tarball/
<cjwatson> OOo is needed, but will take a while :-/
<cjwatson> (fix uninstallables on armel)
<Ng> cjwatson: sorry yeah it's taking me a bit longer than it should
<Ng> ok they're back on auto now, sorry about that
<cjwatson> thanks!
<wgrant> Ng: Is the build in question tiles?
<Ng> yeah
<wgrant> It bounced onto vernadsky a minute or two ago.
<wgrant> Was that intentional?
<Ng> no, it seems to be unhappy
<ScottK> Threaten to build it -j 16 on armel if it doesn't behave.
<elmo> ScottK: you joke, but foomatic already does that :-/
<ScottK> elmo: Yeah, I knew I wasn't making that up.
<ScottK> lamont says that makes the buildd very angry.
<ScottK> I'd appreciate it if someone would review/accept clamav.  Once that's in Maverick, I'm ready to upload it to lucid-updates ...
<Riddell> "The following link will direct you to a download location near you" ... "Or, choose the mirror closest to you"   why do we need the second if we have the first?
<Riddell> ScottK: let me look
<ScottK> Riddell: Thanks.
<cjwatson> ScottK: done
<cjwatson> oh, sorry, Riddell was in progress on it apparently, didn't notice
<ScottK> Thanks both of you.
<Riddell> too late by only seconds, no glory for me
<cjwatson> Riddell: heh
<cjwatson> as if the accepter is visible anywhere anyway ...
<Riddell> ah, good morning skaet
<skaet> good morning Riddell :0
<skaet> :)
<seb128> hey skaet
<Riddell> skaet: release is mostly done, just needs you to update the beasties on https://wiki.kubuntu.org/MaverickMeerkat/TechnicalOverview
<skaet> Riddell,  cool.   Need some of robbiew's input on some of the entries too.
<Riddell> oh, tsk, when does he wake up?
<ScottK> He's two hours east of skaet, so I guess whenever he feels like it.
<skaet> Riddell,  ScottK - actually robbiew and I are both in Austin.  ;)
<ScottK> Oh.
<ScottK> That's right, I had you confused with the Oregon mob.
<ScottK> Sorry
<skaet> ScottK,  no worries ;)
<skaet> Riddell,  haven't seen answers from newz2000 yet either in the inbox, about the paths
 * elmo posts to OMGUbuntu that the 'release is [...] done', you heard it here first
<Riddell> skaet: he's on irc though
<robbiew> what do you NEED from me?
<robbiew> just a review of the TechnicalOverview
<robbiew> ?
<ara> skaet, I am pretty sure that bug 628290 is fixed in RC, and should be removed from the notes
<ubot4> Launchpad bug 628290 in ubiquity (Ubuntu Maverick) (and 1 other project) "OEM installation, missing "Prepare for shipping to end user" icon (affects: 2) (dups: 2) (heat: 167)" [High,Fix released] https://launchpad.net/bugs/628290
<skaet> text for the bugs and known issues.
<ara> many of the "Known issues" there are from Beta
<skaet> robbiew,  text for the bugs and known issues.
<skaet> ara, if its good,   then yes it should be removed.
<ara> skaet, yes, but if that one is there, I think most should be checked :)
<skaet> I just took the beta and then double checked the status on launchpad.
<skaet> ara,  :yup agree.   that's what I put in the note to robbiew ;)
<skaet> what needs tso be added today are the ones from the release target, and the one's we've found since beta and deferred.
<robbiew> sorry...I can't do it right now...ara can you verify?
<ara> robbiew, I'll have a look
<robbiew> thnx
<skaet> Riddell, newz200 is responding to us,   can you doublecheck the paths on the announce part and update with any input from him.   Asked him about a couple of the fixme paths at the same time,  so we should hear from that.
<skaet> ?
<ara> skaet, I commented out two bugs that are fixed in RC. You can double check now
<skaet> ara,  thanks!  :)   will do.
<ara> I am going to review now the bugs found during RC testing, to see what's worth adding to the release notes
<ara> seb128, didrocks, did you guys added this one to the release notes? https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/561734
<ubot4> Launchpad bug 561734 in mesa (Ubuntu) (and 2 other projects) "quadrapassel doesn't start: Failed to initialise clutter: Unable to select the newly created GLX context (affects: 27) (dups: 7) (heat: 153)" [High,Fix committed]
<didrocks> ara: I didn't
<seb128> ara, no, is one game really worth rc notes?
<didrocks> ara: but yeah, impacted intel driver, can have been added to the release note
<didrocks> and it's in the queue now, right?
<seb128> yes
<ara> seb128, it is the only clutter application?
<seb128> yes
<ara> OK, so if you think it is not worth it, that's fine
<seb128> I would not bother for one game especially when the fix is in the queue
<ara> OK
<seb128> but if somebody want to add it I'm fine with it
<seb128> ara, but thanks for pointing it ;-)
<seb128> I would be interested to get feedback on whether the fix work for you when it gets in
<doko> Riddell: why is sun-java6 in NEW?
<ara> seb128, sure, let me know when it reaches the archive, and I will check the fix
<seb128> ara, I will, thanks
<kenvandine> can someone please reject the desktopcouch upload in the queue?  i just found a serious bug, there will be a new release asap
<Riddell> doko: because Brian uploaded it?
<seb128> kenvandine, seems it got accepted already
<doko> Riddell: no, I did
<kenvandine> ok... so that puts more pressure on a new release :)
<seb128> kenvandine, it was over an hour ago, how broken is it?
<kenvandine> it will likely break all quickly apps
<seb128> will make didrocks happy
<kenvandine> hehe
<cjwatson> better fix it soon then :)
<kenvandine> CardinalFang is busting it out now :)
<didrocks> oh nice :)
<seb128> didrocks, see you though they could do anything else after breaking oneconf, they did :p
 * didrocks loves more and more desktopcouh, breaking quickly apps and oneconf :)
<didrocks> seb128: hehe, right
<didrocks> I think I either hate it or it hates me :)
<kenvandine> didrocks, the wrapper object created from get_records no longer contains a rows method
<kenvandine> or any other for that matter
 * CardinalFang is pale enough.  Wearing this brown paper bag will not help.
<didrocks> hum, yeah, that's anoying
<didrocks> annoying*
<didrocks> CardinalFang: heh, don't be!
<CardinalFang> I'm astonished this slipped through tests.
<Riddell> doko: well that'll be why it's there then, packages which have been deleted then uploaded will go through New
<doko> Riddell: why deleted? it's in lucid partner
<Riddell> doko: https://edge.launchpad.net/ubuntu/+source/sun-java6/+publishinghistory says "Deleted on 2010-04-30 by Colin Watson
<Riddell> remove partner packages copied over when initialising maverick; these should only be in lucid for now"
<cjwatson> doko: the partner team instructed us to do this
<doko> cjwatson: ahh, ok
<cjwatson> they want to start partner afresh for every release
<doko> brian didn't know about it
<cjwatson> he asked for it
<cjwatson> (we won't have to delete them manually in future; Soyuz has been changed to avoid copying them)
<ara> skaet, from the bug list at iso.qa.ubuntu.com I don't see any supercritical worth mentioning (apart from those on the list)
<skaet> ara,  thanks for checking.   :)
<skaet> saw the bugs you commented out,  we need to doublecheck launchpad is up to date on those, since they were not in "fixed released" state last night, which is why I left them in.
 * robbiew is off the phone now...sorry :/
<ara> skaet, both were bugs that were marked as duplicated of others
<ara> skaet, the original ones are "Triaged" and "Won't Fix" (the ones in the release notes) but if you follow the links, the master bugs are Fixed released
<ara> in versions contained in the cd
<skaet> ara,  thanks.   it was a bit late. ;)
<ara> :)
<smoser> ok. cjwatson Riddell uec images are now public
<newz2000> cjwatson, Riddell: what is the difference between "release notes" and "technical overview?"
<Riddell> I've never worked that out
<newz2000> that makes me feel so good
 * newz2000 isn't the only one
<newz2000> Riddell: I'm unconfirming the URLs I confirmed
<robbiew> I thought the technical overview WAS the release notes
<Riddell> ok
<newz2000> for release notes they will be http://www.ubuntu.com/getubuntu/releasenotes/1010 the technical overview will live on the wiki
<newz2000> (wherever it is now)
<ScottK> AIUI, technical overview is focused on stuff we meant to have happen, release notes is focused on stuff we didn't.
<newz2000> one of them (release notes I think) gets translated into many langs and is available from the installer, so it's the one we want to have on www.u.c (for performance reasons)
<cjwatson> yes, we write the release notes separately
<cjwatson> compare:
<cjwatson> https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
<cjwatson> https://wiki.ubuntu.com/LucidLynx/ReleaseNotes
<cjwatson> until quite close to the end of the cycle, the only release notes are embedded in TechnicalOverview, but for final release we split them out
<newz2000> Riddell: you can and should use that URL I gave you but it seems the content will live on the wiki
<newz2000> There is a mis-configuration in our CMS and I will have the vendor fix it by next week, so advertise http://www.ubuntu.com/getubuntu/releasenotes/1010
<newz2000> that will be the final URL
<Riddell> vendor?  ubuntu.com doesn't just use drupal or the like?
<newz2000> Riddell: yes, it's drupal but we've had some custom work done by a consultancy
<ogasawara> Riddell: just fyi, I've updated the TechnicalOverview with the updated linux kernel bits
<charlie-tca> Can't we do anythign about OMG! Ubuntu announcing these releases before they actually happen?
<popey> I would recommend speaking to joey, not benjamin
<jpds> And not linking to master mirrors; but local country ones, please.
<charlie-tca> Someone really needs to
<popey> this happens with every release, it's always _someone_ who messes up and posts public links to the iso images, you'd just expect omg to have slightly more clue
<charlie-tca> That was my thought. People consider them to be an official website, not a blog
<popey> people in "wrong" shocker
<ScottK> popey: Maybe you'd expect that.
<smoser> i'm going to step away right now for an hour or so.
<ScottK> (the clue part)
<charlie-tca> And to announce as early as they did... They really could wait at least until afternoon
<smoser> the only thing left to do for UEC images is update the ami pages.  which i can do when i return.
<smoser> (if you've already released... its not a big time critical thing IMO)
<popey> charlie-tca: joey is actually quite an outside to ubuntu, omg is very much someone looking in from outside.
<popey> e.g. they adopted a CoC and didn't use the Ubuntu one because they thought they weren't allowed.
<newz2000> Where are the release notes currently?
<charlie-tca> But some of the them are heavily involved in Ubuntu
<skaet> thanks ogasawara
<popey> charlie-tca: define heavily :)
<ScottK> and involved
<charlie-tca> maybe it is just the perception?
<popey> I know they mean well, just trying to get the 'news' out there, and people lap it up. yes they mess up sometimes, but I don't think Joey ever posts anything with malice.. ben on the other hand..
 * charlie-tca hides again
<robbiew> newz2000: you mean this https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview ?
<newz2000> robbiew: I don't think that's what I mean. :-)
 * newz2000 subtly references previous conversation about diff between technical overview and release notes
<Riddell> newz2000: they're not separate for now
<Riddell> only for the final one
<newz2000> oh, ok
<Riddell> when I hope someone will actually be incharge of prepraring them
<newz2000> I need to set a redirect up so that when someone wants to view the release notes (linked from the homepage) they get sent somewhere
<newz2000> Somethign to replace this page: http://www.ubuntu.com/testing/maverick/beta
<skaet> Riddell,  re: incharge of preparing them,  yup - robbiew and I will decide that later today ;)
<robbiew> newz2000: yeah..that's the same content from the Technical Overview
<newz2000> robbiew: ok, great, thanks
 * robbiew is still editing it though
<newz2000> robbiew: would you mind if I create a new heading above "Upgradingâ¦" and make upgrading and downloading a sub-section?
<newz2000> or you could do it if you like
<newz2000> I'd like to get the call to action above the fold
<newz2000> It could say "Get Ubuntu 10.10" or similar
<robbiew> newz2000: sure...I'm fine with it.  I'll make the change.
<newz2000> great, thanks
<robbiew> newz2000: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview
<robbiew> how's that look?
<robbiew> (re: the Get Ubuntu 10.10)
<robbiew> I'm out of the wiki, so feel free to modify as needed
<GrueMaster> skaet: For the release notes:  Upgrading beagle (armel omap) from lucid->maverick can run of of free space if USB drive is 4G or less.
<robbiew> GrueMaster: ack..will add
<robbiew> GrueMaster: "run OUT of", I assume
<skaet> robbiew, ack
<GrueMaster> robbiew: yea, that too.
<robbiew> GrueMaster: is there a bug that I should mention as well?
 * GrueMaster needs more caffeine infusion.
<newz2000> robbiew: thanks a unch
<GrueMaster> No bug.
<robbiew> cool
<GrueMaster> Not sure if it is one really.
<newz2000> unch = bunch or lunch or brunch depending on if you're hungry or not
<robbiew> GrueMaster: sure...just making sure...added
<GrueMaster> On a side note, with all the requests to clean up disk space, does lucid-desktop-[ia64|powerpc|powerpc+ps3].* belong in http://cdimage.ubuntu.com/ports/daily-live/20100928/ with maverick images?  Could free up a couple Gb.
<Riddell> how curious
<robbiew> newz2000: so will we have http://www.ubuntu.com/testing/maverick/rc ?
<newz2000> robbiew: no, not planned. There will be a link on testing page pointing to /getubuntu/releasenotes/1010
<robbiew> basically, what replaces http://www.ubuntu.com/testing/maverick/beta?
<robbiew> newz2000: ok
<cjwatson> GrueMaster: no, it doesn't.  will remove
<cjwatson> previous images get carried over, and this sometimes means that images from the previous release get mistakenly carried over - long-standing minor bug
<GrueMaster> oops.  :P
<cjwatson> I've checked and it only affects that one tree
<cjwatson> nuked
<smoser> ok. so i've not seen any release info, and i'm back now. so i can do the ami pages.
<slangasek> ScottK: I see kdebase-workspace is gone from the queue, I guess that was accepted rather than rejected?
<ScottK> slangasek: It was, but I'd still appreciate it if you'd look at the change.
<ScottK> (I didn't accept it and I'm not sure if whoever did was completely upstartified)
<robbiew> newz2000: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview is good to go
<Riddell> robbiew: I'm off out, I take it you'll send out the announce when the ubuntu.com pages are done?
<newz2000> robbiew: ok, any word on when we're ready to "release"
<robbiew> Riddell: aye..thank you sir!
<slangasek> ScottK: looks good to me - exactly the fix expected based on our experience with gdm
<cjwatson> ScottK,slangasek: I accepted it, it seemed to match the gdm change and there was extensive discussion on the bug
<cjwatson> which looked broadly correct
<ScottK> cjwatson and slangasek; Thanks.
 * Riddell updates .htaccess and HEADER.html files
<robbiew> newz2000: just need a few more minutes to update the mirror links in the announcement...to point to /rc
<newz2000> cool
<robbiew> newz2000: done with release announcement...skaet anything else need to be done?
<skaet> robbiew, release notes are good.   can I have one more pass on the announce?
<robbiew> skaet: sure thing
<newz2000> robbiew: if we make the first link point to www.ubuntu.com/testing/download it will bounce them to a mirror near them using geoip
<robbiew> newz2000: which first link? :)
<newz2000> robbiew: first download link
 * newz2000 thinks robbiew needs to work on his mind-reading skills ;-)
<robbiew> yep...http://www.ubuntu.com/testing/download (Ubuntu Desktop, Server, and Netbook) is there
<robbiew> maybe I should mention that it bounces to a mirror near them using geoup
<robbiew> geoip
<jpds> "Or, download Ubuntu 10.10 RC; The following link will direct you to a download location near you:"
<newz2000> robbiew: sorry, I meant https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview
 * newz2000 likes jpds wording better than geoip
<robbiew> yeah..yeah..I wasn't going to actually say "geoip" ;)
<robbiew> newz2000: adding now
<newz2000> Do you guys get a moment of dread just before you release this out into the world?
 * newz2000 always has violent butterflies in his stomach
<robbiew> heh...yeah
<robbiew> jpds: I assume you are correcting?
 * robbiew didn't want to step on your wiki edit ;)
<jpds> robbiew: All yours now.
<robbiew> newz2000: I'm out of the wiki..TechnicalOverview is good to go
<newz2000> robbiew: are the mirrors ready, should we launch the website?
<robbiew> skaet:^
<robbiew> I think some were still lagging
 * robbiew goes to check again
<skaet> when I was checking, some were pointing to beta about minutes ago.
<skaet> double check them is good idea.
<robbiew> http://ubuntu.saix.net/ubuntu-releases/10.10/ still pointing to beta
<skaet> announce still needs a bit more tweaking, but website can start I think.
<skaet> without waiting for it, once we know the mirrors are good.
<skaet> ;)
<robbiew> http://mirrors.sohu.com/ubuntu-releases/10.10/    http://ftp.riken.jp/Linux/ubuntu-iso/CDs/10.10/    http://ftp.kaist.ac.kr/ubuntu-cd/10.10/    http://ftp.kaist.ac.kr/ubuntu-cd/10.10/   all beta
<smoser> does anyone mind if I update the AMI pages now ?  I am about to fall over, and need to step away.
<robbiew> http://ubuntu.mirrors.proxad.net/10.10/   http://ubuntu.mirrors.proxad.net/10.10/  http://mirrors.us.kernel.org/ubuntu-releases/10.10/   also beta
<robbiew> smoser: go ahead
<smoser> thank you.
<robbiew> newz2000: so both http://cesium.di.uminho.pt/pub/ubuntu/10.10  and  http://mirror.linux.org.au/ubuntu-releases/10.10 don't work
<robbiew> :/
<newz2000> robbiew: did you get those from www.ubuntu.com/testing/download ?
<robbiew> no...from the TO...they were already there
 * robbiew hates this listing of the mirrors
<newz2000> robbiew: ditch it
<newz2000> just use testing/download
<robbiew> newz2000: aye...btw, I meant the ReleaseAnnouncement...TO is fine
<robbiew> skaet ^^^^
<robbiew> since you are still in the announcement
<robbiew> maybe we should just leave the mirrors out
<robbiew> and let the link do it's job
<newz2000> more choices is not more good
<robbiew> right
<skaet> robbiew, yeah,  I tend to agree at this point.
<newz2000> disclaimer: during the first hour it can be hit and miss
<smoser> ami pages updated. uec images are "done". http://uec-images.ubuntu.com/releases/maverick/rc/
<skaet> robbiew, newz2000  so, should I just strike out section "Or, choose the mirror closest to you:" ?
<ScottK> It's Gnome, of course more choices aren't good.
<ScottK> ;-)
<robbiew> yes
<newz2000> skaet: imho, yes
<robbiew> ScottK: hush...lol
<skaet> robbiew, newz2000 doing it now.
<robbiew> smoser: ack, thnx
<skaet> bit torrent comment at the end - goes too?
<robbiew> yeah
<robbiew> skaet: oh..wait, I thought you meant something else...that can stay
<robbiew> sorry
<robbiew> "Please download using Bittorrent if possible."  seems fine to me
<skaet> heh,  no worries.   will just put it back.
<robbiew> newz2000:  go ahead and flip the website
<newz2000> \o/
<skaet> robbiew,  am out.   do one more quick scan, and pronounce the blessing (if appropriate)
<robbiew> newz2000: http://www.youtube.com/watch?v=hLFYx6xlhB0
<robbiew> skaet: aye
<newz2000> this is it
<skaet> it is what it is...
<newz2000> oops, should have watched the whole thing
<newz2000> ok, it's live
 * skaet \o/
<stgraber> newz2000: is the redirection to wiki.ubuntu.com the wanted behaviour when you click on that RC banner ?
<newz2000> stgraber: yes, for now
 * robbiew sends out the announcement
<marjo__> robbiew: thx
<GrueMaster> Is there an actual image for kubuntu-netbook on armel?  I see kubuntu-mobile (which really looks cool btw) and Kubuntu-preinstalled-desktop, but not netbook.
<ScottK> GrueMaster: No separate netbook image anymore.  It's part of desktop now.
<ScottK> GrueMaster: If your display is less than 700 pixels high, you have a battery, and no CD drive, you get netbook on first run (and there's a kcm for easy switching).
<GrueMaster> Ok, so http://iso.qa.ubuntu.com/qatracker/test/4597 should be kubuntu-desktop?
<ScottK> Looking
<ScottK> GrueMaster: Yes.
<ScottK> stgraber: Can you fix ^^^
<GrueMaster> Let me know when it is fixed and I will fill in the appropriate info.
<GrueMaster> And kubuntu-mobile is not part of the release testing, right?  Looks cool so far, but also has a ways to go.
<ScottK> GrueMaster: It's a tech preview, so doesn't need any official testing, but if you get a chance to look at it, it would be appreciated.
<GrueMaster> Have it running now, hence the comments.
<GrueMaster> On omap4 btw.
<ScottK> Cool.
<ScottK> Actually there may have been a test case for mobile.
<ScottK> Interesting.  Just i386.
<ScottK> GrueMaster: You might report a result for the i386 kubuntu-mobile test and mention in comments what you're actually testing on, so we have a record.
<GrueMaster> Someone should probably review the testcases prior to next week release testing.  I see imx51 on the list for netboot and it is not supported.
<GrueMaster> Ok.  Or I could just add an omap4 test and report there.  For the most part, it has the same issues as all the other images (sound mainly).
<ScottK> Right.
<ScottK> However you think best.
<GrueMaster> prefer to keep arch results separate.  And I am seeing an issue on omap, but I am reflashing and will retry.  Missing perl lib.
<newz2000> robbiew: I like your release announcement, it's great, but it leaves me with one lingering question...
<newz2000> Is it web scale?
<robbiew> huh?  you mean the <<BR>> cruft?
<newz2000> no, Ubuntu. Is it web scale?
<newz2000> (sorry, obscure reference to http://www.youtube.com/watch?v=b2F-DItXtZs )
<robbiew> ah
<robbiew> lol
<robbiew> newz2000: gotcha
 * nigelb hugs robbiew 
<robbiew> nigelb: :)
<nigelb> That was like *awesome* mail about RC.  Love the THGTTG reference :)
<nigelb> You should copy and paste less often :p
<nigelb> The originals are more aweome
<robbiew> nigelb: heh...tell me about it...kept the damn <<BR>> cut and pastes at the bottom so folks know I sent the announcement :/
<nigelb> haha
<\sh> newz2000: put a copy on another server...youtube says, there is content of comcast in it...krauts are not able to watch it ;)
<newz2000> \sh: I didn't make that unfortunately, it was one of those viral videos going around a few weeks ago
<newz2000> I'm really surprised it was blocked, it's got some bad language but otherwise no music or photos or anything that might upset someone
<newz2000> \sh: just google for "mongodb web scale" and I'm sure you'll find a copy
<ScottK> robbiew: I just accepted ubuntu-artwork, so the font change is in.
<robbiew> ScottK: thnx...heh...but I think kenvandine needs to resubmit with a change to the font size
<ScottK> robbiew: It was 10 point in what I accepted.  Is that wrong?
<kenvandine> ScottK, we are just discussing that now
<ScottK> OK.
<kenvandine> i think it will get bumped to 10.5 or 11
<kenvandine> ubuntu is a little smaller than sans
<ScottK> OK.  In general if there's stuff in the queue that shouldn't be processed, it's worth a mention.
<kenvandine> ScottK, yeah... this just came up :)
<kenvandine> sorry
<Riddell> announce not gone out yet?
<ScottK> Yes
<kenvandine> ScottK, i just uploaded a new ubuntu-artwork changing it to 11, sorry for the repeat work
<skaet> Riddell,  robbiew sent out about an hour ago on ubuntu-devel-announce, and ubuntu-announce.
<robbiew> and the releases blog...and on LP :)
<ScottK> kenvandine: No problem.  I'll look at it in a moment.
<kenvandine> ScottK, thx
<ScottK> Don't see it in unapproved yet.
<kenvandine> ScottK, a little lag there i guess...
<ScottK> Yep.  It arrived.  Now I'm waiting for the diff.
<ScottK> Also Riddell's liblastfm upload was 12 seconds ahead of yours, so you'll need to get in line ...
<kenvandine> hehe
<ScottK> kenvandine and robbiew: Accepted.
<ScottK> That should make the same publisher run as the first one, so no one will actually get the one with the wrong size.
<robbiew> ScottK: thnx
<kenvandine> ScottK, thx!
<ScottK> You're welcome.
<robbiew> skaet: FYI -> 630748
<robbiew> bah
<robbiew> https://bugs.launchpad.net/ubuntu-release-notes/+bug/630748
<ubot4> Launchpad bug 630748 in linux (Ubuntu Maverick) (and 2 other projects) "iwlagn degrades quickly during normal wifi session (affects: 4) (dups: 1) (heat: 26)" [High,Confirmed]
<skaet> robbiew,  yeah I came in part way through the thread on ubuntu-kernel.
<robbiew> chatting in #ubuntu-kernel about it...fix isn't out, but a suitable workaround is available
<robbiew> cool
<skaet> am adding it to the agenda.
<robbiew> skaet: added to ubuntu-release-notes also
<skaet> right now as well, so it keeps on the radar.
<robbiew> ack
<skaet> yup, saw thatand was tempted to send you a big :D
<ScottK> We need to figure out a different name for our "Release Candidate" milestone because what we are producing is not (and never has been) what most people thing the term release candidate means.
<robbiew> how so?  we don't change much between the RC and release
<doko> robbiew: we don't have a 4.4.5 final GCC release, so maybe it's better to talk about 4.4.4, or you'll see the 4.4.5 final gcc in the unapproved queue tomorrow ...
<robbiew> ~$ gcc --version
<robbiew> gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
<doko> don't say that I won't deliver what the release notes say ...
<robbiew> well THAT is a but misleading, imo
<doko> it is, it's a merge error, but I didn't want to change that again. the kernel folk are a bit jumpy about it
<robbiew> well hell...I guess it's your fault ;)
<robbiew> I'll make the change back for the final release
<doko> thanks
<ScottK> robbiew: I generally think of a RC as "The thing we'll release unless something comes up".
<ScottK> I don't think Ubuntu RCs have ever been anywhere near that.
<doko> otoh, the package is much closer to 4.4.5 than 4.4.4
<robbiew> doko: shut up
<robbiew> lol
<ScottK> Uploading a new Gnome version between RC and final isn't particularly RCish.
<robbiew> ScottK: agree with that
<seb128> we didn't do that
<seb128> we uploaded a few tarballs with translation updates only
<ScottK> Ah, OK.
<seb128> we got most of the new GNOME in on monday before RC
<ScottK> I just saw a lot of Gnome stuff with new version numbers.
<ScottK> That's not so bad then.
<seb128> right .92 to .0
<robbiew> ;)
<ScottK> Ah.
<seb128> GNOME is code frozen between those
<ScottK> OK.
<robbiew> ScottK: yeah....I agree that the RC should be the RC (so to speak)
<seb128> so it's bug fixes which deservers a freeze exception and translation updates
<Riddell> I agree to the gnome updates since I think if I was an upstream I'd want the .0 version shipped so I'd be confident when people report bugs that it's the same version released
<seb128> but yeah, we got bitten by the timing due to 10.10.10
<robbiew> I wonder who decided that?
<robbiew> heh
<ScottK> robbiew: This was going to be the cycle where we stuck to the milestones ....
<seb128> ;-)
<robbiew> it was? I thought it was the cycle we did everything cowboy-ish because it was Maverick
<robbiew> :D
<robbiew> I'm telling you...just remember the 3 sentences of life...and it will all be OKAY
<robbiew> http://www.youtube.com/watch?v=hLFYx6xlhB0
<ogra> ScottK, sorry, i wasnt clear in the bug, devmem2 is a hard dep of the omap GL drivers packages
 * ogra adds that to the bug
<ogra> oh, ricardo did already
<ScottK> ogra: OK.  In that case if you can find an archive admin with time to review, I think it's fine.
<ogra> i'll try, thanks (it will help plasma on omap massively)
 * \sh has a dream...ogra and something kde related..
#ubuntu-release 2010-10-01
<Riddell> oh good, omgubuntu removed comments from that Colin Watson character, good to know they don't let those trolls ruin everything
<wgrant> You can't expect them to let facts get in the way :)
<persia> "facts" only apply in a given perception of reality, don't assume what is real for developers is real for users.
<nigelb> heh
<elmo> Riddell: hmm?  I can still see his comment?  or did he make more?
<Riddell> http://www.omgubuntu.co.uk/2010/09/ubuntu-10-10-release-candidate-available-for-download/#disqus_thread top comment says "Colin Watson 20 hours ago Comment removed."
<elmo> ah, I'm viewing the thing without javascript and have a completely crippled view of comments which doesn't show me that
<cjwatson> robbiew: I noticed in the RC announcement that there was no mention of the installer redesign under Ubuntu Desktop, despite the fact that it gets mentioned in nearly every review of 10.10 so far.  Should there be?
<cjwatson> just for the avoidance of doubt, my omgubuntu comments weren't removed by me
<Riddell> and as pointed out, you can just disable javascript to read them, how strange
<nigelb> Riddell: more like "how ineffective"
<mvo> I'm sorry for a last-minute issue, but bug #652151 needs another upload of software-center (I just uploaded it). double checking the diff is very welcome, in a nutshell the problem is that "update-software-center" runs as root, creates a ~/.cache/sofware-center dir if HOME is pointing to /home/$user (as is default with sudo). so extras care is now taken that the dir is created at the right place and never in /home/ when root is nvolved
<ubot4> Launchpad bug 652151 in software-center (Ubuntu Maverick) (and 1 other project) "software-center crashed with IOError in _open() (affects: 30) (dups: 22) (heat: 226)" [High,In progress] https://launchpad.net/bugs/652151
<cjwatson> Riddell: can daily CD builds be re-enabled?
<Riddell> oh aye, I'll do that, forgot yesterday
<Riddell> done
<cjwatson> ta
<didrocks> hey
<cjwatson> folks looking at NBS: don't remove the omap4 kernel packages, they're false positives
<Daviey> Hi Release Team... just preparing release status notes for the meeting, and wondered if bug #644587 can be actioned, so we can remove it from the agenda :).
<ubot4> Launchpad bug 644587 in drizzle (Ubuntu Maverick) (and 1 other project) "Please remove drizzle from maverick (was: fails to build from source on maverick) (affects: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/644587
<Daviey> Thanks.
<cjwatson> doko_: how goes the libspring-2.5-java build?
<cjwatson> Daviey: how does this align with the apparent attempt by Clint in the bug to get an updated version into maverick?
<ScottK> cjwatson: Clint gave up because upstream decided it was too hard (apparently they've not been having much luck getting through ftp-master and my position was I'd accept an upload through Debian, but wasn't going to volunteer us to source New a package of that size this late).
<Daviey> ^^ yeah.. that is this situation i was last aware of.
<Daviey> cjwatson: it was Clint that updated the description to reflect removal on the 29th
<cjwatson> Daviey: oh, shame he didn't leave an explicit comment, it would have been clearer
<Daviey> cjwatson: Yes, fair comment.
<doko_> cjwatson: Ng is working on it
<cjwatson> thanks
<ScottK> Please don't accept musescore.  Ubuntu Studio wants to do some testing with it before they decide if they want it post-RC.
<cjwatson> skaet,robbiew: FYI, "Upgrading Wubi systems from 10.04 LTS is known to fail, and is not recommended at this time." is not an accurate summary of bug 610898.  It only fails if you installed Wubi to a partition other than the main Windows partition.  I tested an upgrade in a more normal situation a week or two ago and it worked fine.
<ubot4> Launchpad bug 610898 in wubi "grub-pc upgrade renders computer unbootable when Wubi is installed to partition other than Windows (affects: 5) (heat: 40)" [Undecided,Confirmed] https://launchpad.net/bugs/610898
<cjwatson> I've edited the release agenda to be a bit more accurate (but more unwieldy)
<Daviey> Would a member of foundations be able to look over the upstart modifications: http://launchpadlibrarian.net/54001906/libvirt-host-upstart.debdiff  for bug #599342.  Advise if A) it's suitable and B) we should target for final - or consider it for SRU?   Thanks :)
<ubot4> Launchpad bug 599342 in libvirt (Ubuntu Maverick) (and 1 other project) "Temporary failure in name resolution (affects: 2) (heat: 53)" [Medium,Incomplete] https://launchpad.net/bugs/599342
<cjwatson> it's overcomplicated for a start, 'if grep -q "\<$hostname\>" /etc/hosts; then ...' would suffice
<cjwatson> it seems twisty and confusing to me
<cjwatson> isn't there a real event we can wait on?  busy-waiting in upstart jobs is generally wrong
<cjwatson> I'd prefer to see that as a post-release update, rather than squeezing it in at this point
<Daviey> Yeah.. i'm not entirely comfortable... it's gonna also make debugging why the upstart process is blocked - if people broke /etc/hosts
<cjwatson> that way there's space for finding that it's wrong and revising
<Daviey> cjwatson: Sounds good to me!  Thanks.
<cjwatson> Daviey: drizzle removed
<Daviey> \o/
<Daviey> cjwatson: I've been leaning on you quite heavily today, you must claim your free beer from me.  Appreciated!
<cjwatson> if you can figure out what the heck is going on in bug 594162, that would be more than adequate payback ...
<ubot4> Launchpad bug 594162 in wget (Ubuntu Maverick) (and 1 other project) "segmentation fault while downloading preseed file (affects: 1) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/594162
<cjwatson> doko_: ^- actually, could you have a look at that?  the assertion is deep down in the dynamic linker and I'm not sure I trust my intuition
<cjwatson> __getpagesize is failing
<doko_> trying to understand the problem
<cjwatson> actually, I do have one thought ...
<Daviey> cjwatson: I don't mind having a poke... Have you managed to find a reproducible method of causing it?
<cjwatson> nope
<Daviey> :(
<cjwatson> it's not entirely impossible that busybox is chrooting and then trying to exec one of its own applets
<cjwatson> that would ... probably not work very wewll
<cjwatson> *well
<cjwatson> I'll ask them to try a patch for that, but it's just a guess
<cjwatson> it would be execing busybox-static in the chroot and not quite sure what that would do
<cjwatson> confirmed that if you run 'sudo busybox sh' and then 'chroot / rm --help' you get busybox rm help output
<ogra> err ?
<ogra> 32 ?
<ogra> hmm, one dch -i to much i guess
<ScottK> Want to redo it?
<ScottK> No problem to reject if you do.
<ogra> ScottK, nah, i'm fine with one skipped version number ... no biggie
<ScottK> OK
<ogra> hrm
<ogra> i have to patch a Makefile.in ... do you prefer to get all autocrap in the diff ? or would you be fine with a simple patch to .in and .am ?
 * ogra is really not eager to run automake
<ScottK> If you're patching makefiles, it will likely not be me that reviews it.
<ogra> well, its a change in a target path only
<cjwatson> just patching .am and .in is probably fine in that case
<ogra> thanks
<stgraber> highvoltage,cjwatson: I'm going to revert that seed change in edubuntu.maverick so we have all langpacks again. If we don't have a working image by Tuesday, I'm going to re-apply it.
<cjwatson> check when the new langpacks will land first maybe?
<ogra> who ever reviews my maximus upload, please take a close look at the preinst/postinst change, i'm not sure if an elif would be better there (and i'm happy to redo it if its wrong)
 * ogra isnt really comfortable with moving conffiles around
<ogra> (and i dont get why it happened in the first place)
<stgraber> cjwatson: well, according to the e-mail I got from David Planella they are building today
<cjwatson> moving conffiles around: these days, you should use dpkg-maintscript-helper
<ogra> well, i tried to stick with what the package had already
<ogasawara> robbiew: Re bug 630748 - sabdfl reported positive test results from my test package which I've posted to the bug.  Just wanted to get your Ack in the bug to allow the upload.
<ubot4> Launchpad bug 630748 in module-init-tools (Ubuntu Maverick) (and 5 other projects) "iwlagn degrades quickly during normal wifi session (affects: 4) (dups: 1) (heat: 26)" [High,In progress] https://launchpad.net/bugs/630748
<ogra> (which apparently is mv_conffile)
<ScottK> cjwatson: Would you mind turning the release bot off for the language pack  flood ....
<robbiew> ogasawara: done
<cjwatson> done
<ScottK> Thanks.
<ogasawara> robbiew: thanks, will get it uploaded
<skaet> cjwatson,  thanks for the clarification on Wubi for bug 610898.
<ubot4> Launchpad bug 610898 in lupin (Ubuntu) (and 1 other project) "grub-pc upgrade renders computer unbootable when Wubi is installed to partition other than Windows (affects: 5) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/610898
<GrueMaster> cjwatson: I updated bug 652522.  USB keyboard now works, but no usb nics.
<ubot4> Launchpad bug 652522 in debian-installer (Ubuntu) "modules missing from omap netboot image. (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/652522
<cjwatson> ok, that should be fixable
<GrueMaster> Cool.
<cjwatson> turning queuebot back on, I assume that the language packs have been done
<cjwatson> (haven't checked but the queue isn't bursting)
<cjwatson> mvo: software-center> is os.rmdir sufficient?  won't the cache directory often have contents?
<cjwatson> mvo: I'd have thought maybe shutil.rmtree or whatever it is?
<mvo> cjwatson: the specific error that gets fixed always creates a empty dir
<mvo> cjwatson: I can not think of a way it has content other than sudo software-center
<mvo> cjwatson: I'm fine with adding this, but for the specific fix I have it should not be needed
<cjwatson> ok, no problem then
<cjwatson> just jumped out at me
<cjwatson> mvo: so the stuff in softwarecenter/log.py runs with dropped privileges?
<mvo> cjwatson: log.py is not included by update-software-center (that is the only bit that runs as root). but paths.py is included
<cjwatson> gotcha
<mvo> cjwatson: that caused the problem :/
<cjwatson> accepted
<mvo> many many thanks
<mvo> plus for the review
<cjwatson> Riddell: you beat me to mozc by under a minute
<cjwatson> sigh
 * cjwatson Ctrl-cs queuebot
 * Riddell takes all the glory
<lamont> did we have a mass giveback  on i386, or is that just how many langpacks there are?
<lamont> heh. langpack
<ogra_ac> a fraction
<mdeslaur> skaet: I just uploaded a fixed m2crypto to fix #600549
 * ScottK has a look
<cjwatson> ogra_ac: this console handling in jasper-initramfs looks funny to me
<cjwatson> +        console=tty[A-Z]*)
<cjwatson> +            CONSOLE=${x#*=}
<cjwatson> and then
<cjwatson> -        setenv bootargs quiet splash ro ${BOARD_OPTS} root=${VOLID} fixrtc
<cjwatson> +        setenv bootargs quiet splash ro ${BOARD_OPTS} root=${VOLID} fixrtc ${CONSOLE}
<cjwatson> shouldn't that just be CONSOLE="$x", rather than stripping the leading console=?
<ogra_ac> i only want to hand it over if a serial console arg is set
<cjwatson> sure, but you want console=ttyS0 on the command line, not just ttyS0, surely?
<lamont> cjwatson: just for giggles, I'm going to schedule openjdk-6 on the panda and see how it does.  that'll involve a moment or 3 on manual for the i386 world. unless you or ogra_ac say not to, of course
<cjwatson> lamont: ok by me
<ogra_ac> cjwatson, errr
<ogra_ac> yes
<ogra_ac> sigh
<lamont> s/i386/armel/ sigh
<cjwatson> ogra_ac: shall I reject this and you reupload, then?
<ogra_ac> cjwatson, yep
<ogra_ac> thanks for pointing it ut
<cjwatson> ok, thanks
<ogra_ac> *out
<ogra_ac> (and sorry for wasting time )
<cjwatson> not a problem
<lamont> cjwatson: would you like another i386 buildd for a bit (at the expense of an amd64 buildd)?
<lamont> meh. all 3 amd64 are idle, I'll just steal one
<seb128> hum pitti left
<seb128> the telepathy-glib non trivial update is required for telepathy-gabble to build
<seb128> it depwait on a newer version
<cjwatson> lamont: I don't think it matters all that much
<cjwatson> seb128: I'll review it
<seb128> thanks
<cjwatson> +    Require Vala 0.10.0 for the Vala bindings
<cjwatson> seb128: does it matter that we backed out the new GIR stuff?
<cjwatson> hm, there seem to be matching Debian patches
<cjwatson> ok, this looks fine then
<cjwatson> accepted
<seb128> cjwatson, right I was going to say that normally chrisccoulson reverted the requirement for the new gir there
<seb128> cjwatson, thanks
<skaet> mdeslaur,  thanks!  :)
<lamont> 2010-10-01 17:10:36+0000 [-] Build log:  debian/rules build
<lamont> 2010-10-01 17:10:37+0000 [-] Build log: explicitely fail the build for armel
<lamont> cjwatson: openjdk-6 is gonna need a new upload  at some point for this...
<cjwatson> you'll need to ask doko for that
<lamont> yeah
<lamont> anyway, afk for a few
<NCommander> Riddell: cjwatson: any issues if I respin Dove once casper builds and is published? (Riddell said I could respin the ARM images, but that was a few days ago, and I didn't want toupset anything befor eI poked antimony)
<Riddell> go ahead
<NCommander> Riddell: second question, once my image is spun, do I need to do sometihng special to kick it onto the ISO tracker, or will it just magically pop up?
<Riddell> NCommander: it needs to be added, but why would you do so?  we're not tracking images until next week
<NCommander> Riddell: just asking for reference ask
<NCommander> *sake
* You're now known as ubuntulog
<lamont> mucking about with the arm buildds again
<ogra_ac> cjwatson, does http://paste.ubuntu.com/504104/ look sane to you ?
<NCommander> Can someone please bless https://bugs.edge.launchpad.net/ubuntu/+bug/635415 for upload? (I can sponsor, just need the release teams OK)
<ubot4> Launchpad bug 635415 in plt-scheme (Ubuntu) "armel build failure (uses internal outdated libffi) (affects: 1) (heat: 14)" [Undecided,New]
<ogra_ac> NCommander, its an ftbfs fix
<ogra_ac> just upload
<ogra_ac> if its to weird RM can still reject
<ScottK> NCommander: It's in Universe, no release team approval needed anyway.
<NCommander> ScottK: fair enough
<ScottK> At least I'm assuming it's not seeded.
<ScottK> Either way, upload away and we'll review it in the queue.
<ogra_ac> ist not
 * iulian already approved it.
<iulian> NCommander: Please subscribed ubuntu-release from now on.
<iulian> subscribe even
<NCommander> iulian: someone needs to update the wiki :-/
<iulian> What wiki?
<NCommander> https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions for Universe/Multiverse
<NCommander> I subscirbed ~motu-release out of habbit
<NCommander> But the part about universe not needing an individual yay/nay should be there
<iulian> NCommander: It actually doesn't say anything 'bout motu-release.
<NCommander> iulian: right, see above ;-)
<iulian> Yea, alright.
<cjwatson> ogra_ac: thanks, two things though
<ogra_ac> shoot
<cjwatson> ogra_ac: firstly, you need [ ] around -b $device
<ogra_ac> ugh
<ogra_ac> yeah
<cjwatson> actually best around the ! too
<ogra_ac> right
<ogra_ac> i usually do that by default, not sure why i missed it here
<cjwatson> ogra_ac: secondly, I don't really see the point of dividing the size down.  why not just have size=$((stat -c $device)) and then dd bs=$size count=1?
<cjwatson> (excuse typos, am on the n900)
<cjwatson> worth checking that the dd won't run out of memory if bs is more than ram, of course
<ogra_ac> cjwatson, wont work for swap
<ogra_ac> swap files cant contain holes which is what bs=$size count=1 does
<ogra_ac> it actually needs to be bytewise filled up
<ogra_ac> oh wait thats count=0 i'm talking about, count=1 might actually work
<cjwatson> you're thinking of seek=1
<ogra_ac> err, yeah
<ogra_ac> right, i'll change it then
<newz2000> Hi, is there a kubuntu netbook for 10.10 or is that now gone?
<Riddell> newz2000: it's now part of the normal kubuntu image
<newz2000> Riddell: ok, thanks
<Riddell> newz2000: there's a kubuntu mobile but it's very much in tech preview mode so no special download page magic needed
<newz2000> ah, sounds interesting
<Riddell> newz2000: hmm, but we don't use any magic download stuff from you currently i think
<Riddell> newz2000: does kubuntu have or could we get a download link like http://www.ubuntu.com/testing/download ?
<Riddell> and is it possible to have a link like that which goes to the .iso file directly?
#ubuntu-release 2010-10-02
<newz2000> Riddell: sorry I missed you, yes, you will have that available, I finished testing today but you may not be using it until your new site goes live
<cjwatson> ogra: hmm.  so, I just double-checked both coreutils and busybox dd, and they both malloc a buffer at least as big as the blocksize
<cjwatson> ogra: so maybe my advice to use bs=$size count=1 wasn't so hot after all
<cjwatson> ogra: I'm slightly concerned about rounding errors from the bs=1M option though
<cjwatson> ogra: but maybe rounding errors aren't much of a problem - anyway, sorry but I think perhaps this needs to go back to your previous divide and bs=1M solution
<cjwatson> sorry, couldn't check on the spot when you asked last night
<Riddell> newz2000: my new site?
<cjwatson> could somebody review base-installer, ubiquity, and ubiquity-slideshow-ubuntu?
<cjwatson> those are mine or sponsored by me
<Riddell> cjwatson: I'll take a look
<cjwatson> ta
<ogra> cjwatson, i'll change back to the divider code later today though for a swap file it really shouldnt matter that much if there are rounding errors
<ogra> cjwatson, how about that one ? http://paste.ubuntu.com/504460/ no rounding errors :)
<ogra> or in a better readable version http://paste.ubuntu.com/504469/
<cjwatson> ogra: go ahead, thanks
<ogra> with the last one ?
<ogra> or the former ?
<ogra> :)
<ogra> make a pick
<cjwatson> I don't mind, flip a coin
<ogra> heh
<ogra> i'll pick the latter
<rsalveti> ogra_ac: the package opengles-sgx-omap3 built fine yesterday, but I can't still see the packages at our repository, just the sources
<rsalveti> and the build status is Uploading build on cushaw
<rsalveti> 18 hours ago, is this normal?
<cjwatson> rsalveti: no, that's odd, ask #launchpad for help (better during working hours)
<cjwatson> I'll ask on the internal soyuz channel just in case
<ogra_ac> rsalveti, oh, doo you have multiverse enabled in your image ?
<ogra_ac> it surely went there
<cjwatson> no, it's stuck somewhere
<ogra_ac> ah, k
<cjwatson> I can't see why - I've asked
<cjwatson> may not be anyone around who can check just now though
<ogra_ac> yeah
<rsalveti> ogra: cjwatson: oh, ok, so it seems to be a bug at launchpad
<rsalveti> np, will be off now, going to the airport, but will try to ping someone tomorrow
<ogra_ac> you fly out already ?
 * ogra_ac hasnt even packed
#ubuntu-release 2010-10-03
<lex79> someone around? I uploaded qt4-x11, but I missing the epoch in the "Replaces" field, please accept the right version :) I uploaded twice
<lex79> thanks
<micahg> if I'm going for an update that requires an FFe and both sid and experimental have new versions and experimental doesn't add too much more, should I go for the one in experimental?
<micahg> if I'm going for an update that requires an FFe and both sid and experimental have new versions and experimental doesn't add too much more, should I go for the one in experimental?
<Riddell> micahg: depends if it's the version you want
<micahg> Riddell: well, the version in sid is enough to fullfill the main reason for the FFe
<micahg> Riddell: the package is tortoisehg
<micahg> so, do I do the minimum required, or since we're updating, go all the way
<micahg> or whatever I think is good :)
<cjwatson> micahg: at this point, minimum required
<ScottK> cjwatson: Would you please feed http://paste.debian.net/93104/ into mass-sync.py?
<micahg> cjwatson: ok, thanks
<ScottK> Riddell: ^^^ perhaps you'd be up for tossing that at mass-sync?
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<cjwatson> ScottK: (I take it you just did the NEW processing, since the two new packages are in DONE rather than NEW?)
<ScottK> cjwatson: I did.
<cjwatson> righto
#ubuntu-release 2011-09-26
<stgraber> oh, typo in the changelog, as it's still in the queue might as well fix that :)
<stgraber> please reject ^
<stgraber> and re-uploaded
<ScottK> stgraber: Rejected the older one.
<stgraber> ScottK: thanks
<ScottK> No problem.
<ScottK> slangasek: ^^^ Yon kde-workspace upload has the upstart init change you're waiting for if you'd care to review (all the patches are cherrypicks from upstream).
<slangasek> ScottK: accepted
<ScottK> slangasek: Thanks.
<slangasek> and that lightdm is the last one that blocks fixing this on the plymouth side
<pitti> ev: will have a look at the custom widgets thing this morning
<pitti> slangasek: accepted
<pitti> thanks!
<slangasek> pitti: huzzah, thanks to you
<micahg> pitti: could you review firefox ^^
<pitti> oh, another one? :-)
 * pitti already accepted two yesterday
<pitti> micahg: sure, doing
<micahg> pitti: you weren't supposed to accept the first one ;)
<micahg> or whichever one ubuntu2 was
<micahg> pitti: thanks!
<pitti> np; sorry for prematurely accepting ubuntu2 then, didn't spot that error
<micahg> pitti: yeah, I didn't spot the issue either, cjwatson caught it, but we should've listened to infinity and rejected it :)
<pitti> ^ review of that appreciated (I uploaded), breaking ubiquity
<micahg> pitti: why the funny version?
<pitti> micahg: it was -0svn1 before, and it's a bit impractical right now to commit that to debian's svn
<pitti> I can also name it -0ubuntu1 if people prefer taht
<micahg> pitti: right, so it should be -0ubuntu1, no?
<pitti> fine for me; rejecting, reuploading
 * micahg isn't sure what his obsession with version numbers is about...
<ev> pitti: thanks
<pitti> ev: sorry about that; I was going to test the new pygobject with ubiquity with the first live CD after b2, but we didn't get one yet; seems you beat me to it
<pitti> anyway, the just uploaded version works fine
<ev> no worries
<ev> we should discuss doing this sort of thing in a more automated fashion at UDS
<ev> integration tests and all that jazz
<pitti> ev: I thought QA used to have daily automatic tests of our CDs; they should catch this sort of regression, too
<ev> well I was thinking of something less reactionary.  Have the buildd run through the unit tests of any package that depends on the package being built
<ev> that way we catch it straight away
<pitti> ah
<pitti> ev: with jhbuild that already works pretty nicely, but that's of course not easy to move to our per-package source builds
<ev> hm
<ev> admittedly I haven't dug through the source here much
<pitti> next time I upload pygobject I could just run the ubiquity tests
<pitti> that's low-tech and rather easy to do
<ev> Oh, my intention wasn't to just fix ubiquity with this approach, but make it hard to get any software into the archive that breaks existing software.
<ev> but that works for now :)
<ev> is it too late to switch wubi to building ext4 disk images? It's roughly a two line change.
<ogasawara> could I get the linux-meta-3.0.0.12.13 package approved in the queue please?
<ScottK> pitti: I just uploaded KDE 4.6.5 for natty-proposed.  I'd appreciate it if you could accept it today.
<pitti> ScottK: will see to squeeze it in, and/or delegate to SpamapS :)
<ScottK> pitti: Thanks.
<seb128> ^ I did reject my gtk upload, it had a small issue
<ScottK> pitti: You rejected my oxygen-icons upload?
<pitti> ScottK: yes, see bug; it's a no-change upload, so I guess not worth an SRU?
<ScottK> OK.  Thanks.
<ScottK> Agreed.
<ScottK> People who had the bad PPA version already got the fixed one I guess.
<pitti> yes, the reversion to .2 also seems to be in the PPA, according to changelog
<ScottK> It is.
<ScottK> I forgot to go back and diff against what was in the archive.
<pitti> ScottK: ok, all done; that should keep the buildds busy for a while
<ScottK> Yep.  Thanks.
<cjwatson> pitti,SpamapS: I don't suppose one of you could look at my grub/grub-installer/hw-detect SRUs?  I have a tester ready and waiting eagerly. :-)
<ScottK> There will be a bunch of non-i386 failures due to transient build-dep uninstallability.  I'll keep an eye and retry, but don't be suprised.
<cjwatson> (In fact, he first mailed me about this set of bugs in February ...)
<pitti> cjwatson: already at it :) (while I'm at it)
<cjwatson> cool
<cjwatson> grub <= natty shouldn't suffer from the problem I uploaded for today; I'm pretty sure that I've isolated that to GCC >= 4.6
<pitti> cjwatson: for hw-detect, will that get an accompanying d-i upload?
<cjwatson> yes, although only after it's built
<SpamapS> cjwatson: hah, I read that as "I have a zester ready and waiting" .. and I wondered.. what does citrus flavoring have to do with grub?
<cjwatson> boots better if you add some lemon juice
<pitti> good night!
<Daviey> squashfs until the pips squeak.
 * ScottK prepares to get sabdfl'ed.
<lamont> deploying the correct fix for the archive mirror. this could produce a short period where the archive is not completely in sync
<infinity> "The correct fix"?
<lamont> the one where we fix dangling symlinks by also syncing the target, instead of stomping on it
<lamont> it would be interesting to know how debmirror deals with symlinks between components
<lamont> I suspect that the answer is "not"
<lamont> fwiw, the not-in-sync shows up mostly as 403/404 errors. :(
<infinity> There are worse things than a few missing files for an hour or two.
<Daviey> lamont: Hmm, you have concerns that debmirror (and others?) will be broken going forward?
<lamont> Daviey: no
<Daviey> lamont: super, thanks
<skaet> Daviey,  there are 2 cobbler-enlist_0.1 packages in the new queue,  separated by 10 days.    Should the older be rejected.   Note:  the sizes are different between the two.
<skaet> ?
<Daviey> skaet: One is called cobbler-enlist, the other cobbler-enrol :)
<Daviey> cobbler-enrol can be rejected.
<skaet> Daviey,  yup,  misread that, my bad.    cobbler-enrol rejected now.
<bjf> skaet, is today's daily iso busted ? i get an "installation failed" "The installer encountered an unrecoverable error." dialog trying it
<Daviey> ta
<skaet> bjf,  I've just been doing updates myself today.   jibel,  are you seeing anything from the automated tests?
<Daviey> oo-er
<skaet> ....
<bjf> skaet, np, will keep looking
<SpamapS> Release team, need your thoughts on the situation with ensemble/juju ..
<SpamapS> Its a leaf package, no dependencies..
<skaet> Daviey, oo-er?
<SpamapS> We have a pending upload which renames ensemble's binary packages to juju, as the project has been renamed..
<Daviey> bjf: What ISO image?
<slangasek> The Situation is using Juju?  By all means, let's capitalize on this in all our marketing
<slangasek> oh, not that situation
<SpamapS> And there are two big features which upstream would like to see land in 11.10...
<Daviey> SpamapS: I assume you have a transional package in place?
<SpamapS> Since its a leaf, unseeded, universe package, can we upload after Thursday?
<bjf> davidm, should have been the daily from today, i'm pulling a new one down, and will retest
<SpamapS> Daviey: yes, thats part of it.
<SpamapS> slangasek: Maybe we can get snookie too :)
<Daviey> SpamapS: ISTM that there are two issues, the name and the features.  Can they be handled in seperate uploads please?
<slangasek> SpamapS: it can be uploaded after Thursday, but "new features" still means "FFe", which requires some lead time... I don't think you want to risk the name change not going through because it's caught in review
<Daviey> Thereofr eseperate FFe's
<slangasek> so I would suggest uploading the package name change ASAP
<SpamapS> Ok I can upload the name change now for sure. Should I open a FFe bug to track the rename too then?
<cjwatson> bjf: do you have a bug# and/or installation logs?
<Daviey> SpamapS: Is a deprecation warning being issued under older commands?  Or just shooting for gold?
<cjwatson> bjf: and which daily, we build quite a few
<Daviey> SpamapS: Bugs are always handy :)
<SpamapS> Daviey: I was thinking that at least /usr/bin/ensemble should throw up a warning.
<bjf> cjwatson, not yet, just tried, failed, just pulled down one right now, am going to try that
<Daviey> ... and rewarding! :)
<bjf> cjwatson, how to i tell one daily from the next ?
<cjwatson> bjf: it would really help if you could tell me the URL
<cjwatson> we build dailies of Ubuntu desktop, Ubuntu alternate, Ubuntu server, Kubuntu desktop, Kubuntu alternate, Xubuntu desktop, Xubuntu alternate, need I go on
<cjwatson> several of which are Canonical-supported
<cjwatson> and we build each of those for multiple architectures
<Daviey> bjf: It's not clear to me even what flavour you have encountered this with... server, desktop, kubuntu etc?
<bjf> cjwatson, sorry, ubuntu desktop amd64
<cjwatson> thank you
<bjf> Daviey, ^
<slangasek> SpamapS: if you want to just say in the changelog that I've pre-approved the name change, that's fine
<cjwatson> if you had the daily from today, what new one are you pulling down?
<Daviey> He's right ya know
<Daviey> https://jenkins.qa.ubuntu.com/job/oneiric-desktop-amd64_default/98/
<skaet> Daviey, re: cobbler-enlist:  debian/copyright is different from what is in the cobbler-enlist.c file.   Note: cobbler-enlist.c, references cobbler-enrol in the title of the comments also.
<cjwatson> wasn't saying he wasn't, just needed something to look for ...
<Daviey> crap, thought i caught them all
<SpamapS> slangasek: alright that sounds good. I'm finishing some testing and will upload after that.
<bjf> cjwatson, i have a script that pulls down the ubuntu desktop amd64/i386 every day, i tried it and it failed, i just ran the script again incase new ones had been built
<skaet> Daviey,  np.  want me to reject it so you can re-upload?
<cjwatson> Daviey: do you know how I can extract installer logs from jenkins?
<Daviey> cjwatson: I think jibel or jamespage are the key to that.
<SpamapS> And per the other features.. which should land late this week, is there anything I need to do to ensure that the upload early next week is approved?
<Daviey> skaet: please
<skaet> Daviey, done.
<cjwatson> it's chocolate-teapot levels of usefulness without logs, sadly
<cjwatson> well, I guess we get one bit of information out, success or failure :)
<cjwatson> but surely we can do better, I complained about this months ago
<bjf> cjwatson, i'll see what i can get you
<cjwatson> thanks; I'm syncing now but it will take a while
<bjf> cjwatson, i'm building a new usb key right now, when it fails, which logs would you like? (is there a wiki page for debugging installer issues?)
<cjwatson> the logs from the previous usb key would've been fine, but ...
<cjwatson> https://wiki.ubuntu.com/DebuggingUbiquity
<cjwatson> tl;dr: /var/log/{syslog,partman}
<cjwatson> oh and /var/log/installer/debug
<bjf> cjwatson, ack
<cjwatson> should probably edit that page to not talk about EOL distributions but life's too short
<bjf> cjwatson, bug #859849
<ubot4> Launchpad bug 859849 in ubiquity (Ubuntu) "ubiquity crashed with AttributeError in do_set_property(): 'StateBox' object has no attribute 'label' (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/859849
<cjwatson> fixed by new pygobject
<cjwatson> I'll find the dup target in a moment
<cjwatson> so will be fixed in tomorrow's daily
<cjwatson> *dailies
<bjf> cjwatson, ok, thanks
<cjwatson> bug 856669
<ubot4> Launchpad bug 856669 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "pygobject 3.0.0-0svn1 does not work with custom python GTK widgets (affects: 24) (dups: 20) (heat: 194)" [Undecided,Invalid] https://launchpad.net/bugs/856669
<cjwatson> (stupid bugbot, true status is fix released on pygobject)
<jamespage> cjwatson, Daviey: it looks like that test run did not actually start installing - hence no installer log
<cjwatson> jamespage: ok, but it would do if it got past a certain point?  that's good
<jamespage> cjwatson: yes it would - the preseed kicks off httpd in early_command and the framework then grabs the installer log every X seconds
<jamespage> looking at todays tests - https://jenkins.qa.ubuntu.com/
<jamespage> it would appear that all oneiric-desktop-* tests failed
<jamespage> alternate was OK
<jamespage> they all appear to have failed in the same way i.e failed to start installation
<cjwatson> anything gtkish would have done
<cjwatson> dunno if you test kubuntu
<Daviey> woah, 2.6.38-1.3 â 2.6.38-1000.1 .. is that right?
<infinity> Daviey: I'm on it.
<infinity> (Feel free to ignore all the ARM kernels in the queue, I'm reviewing them all)
<Daviey> infinity: ah ok, i started chatting in -arm, if you want to take over.
<cjwatson> pitti: bug 720558 - do you want non-Xen tests as well, or do you think Xen tests are enough?
<ubot4> Launchpad bug 720558 in grub-installer (Ubuntu Natty) (and 7 other projects) "Ubuntu 10.04 currently requires groot= workaround with pvgrub (affects: 1) (heat: 12)" [Undecided,Invalid] https://launchpad.net/bugs/720558
<cjwatson> (obv. I need to test maverick and natty too)
<doko> please could somebody approve openjdk-6? JamVM fixes, one CACAO fix and three OpenJDK fixes
<infinity> doko: Let me look.
<infinity> La la la, gnome3.20 flood...
<cyphermox> could someone please ack network-manager-applet?
<infinity> cyphermox: I don't see how it's at all improved over pitti's previous complaints.
<infinity> Oh, unless I'm reading the diff wrong.  Need more context.
<cyphermox> ah? I moved the files over into a -common package as suggested
 * infinity downloads the full source.
<infinity> Yeah, but what depends on the -common?
<cyphermox> libnm-gtk0. did I screw this up again?
<infinity> Yeah.
<cyphermox> dah!
<infinity> You depend on a -common (= ${binary:Version}) ...
<infinity> In essence, you've moved nothing, just created a new package. :P
<infinity> Because libnm-gtk0 and libnm-gtk1 will still not be co-installable.
<infinity> Which was the complaint.
<infinity> Does the library actually require those two unversioned files to run?
<infinity> Or to be loaded usefully.
<infinity> Or is it just the applet that needs them?
<cyphermox> the library does
<infinity> Seriously? :/
<cyphermox> at least wifi.ui; since it's used to display the dialogs the library is meant to display
<infinity> In that case, you're going to have to give them versioned paths.
<infinity> And then you can safely put them in the library package.
<cyphermox> but why not just keep them in this -common package? afaik it does follow policy (section 8.2 iirc)
<cyphermox> I was looking this up again this morning
<cyphermox> I thought I only screwed up the dependency
<infinity> Well, the common package only works if (A) you fix the dependency, but more importantly (B) those files will work with newer versions of the library.
<infinity> (Or, more to the point, newer versions of those files will work with older libraries)
<infinity> If that backward compat isn't guaranteed, just versioning the files and stuffing them in the library package is reasonable.
<infinity> If upgrading to libnm-gtk1 makes libnm-gtk0 fail to function, then we've won nothing with the split.
<cyphermox> From what I know these files should work with older versions, that part doesn't worry me
<infinity> If you're fairly sure of that, then yeah, your only bug here is the dependency.
<cyphermox> please reject it, I'll fix this
<infinity> Rejected.
<cyphermox> fwiw, I do see the issue with the dependency, sorry about that
<cjwatson> pitti,SpamapS: it turned out I already had a debian-installer/natty-proposed upload staged (for some time), so I uploaded that
<cyphermox> infinity:  ^ I think this covers it all now.
<doko> slangasek, why not qemu-linaro 2011.09?
<slangasek> doko: because I haven't tested 2011.09 at all yet and time is short
<slangasek> I really don't want to go through another round of ppa tests, etc. to get this done
#ubuntu-release 2011-09-27
<infinity> slangasek: Around?
<slangasek> infinity: hi
<infinity> slangasek: Care to lend an eye to http://paste.ubuntu.com/697609/ for sense-making?
<infinity> slangasek: Turns out that we went around and around in circles because someone had me convinced we actually used the debconf frontend.  Which we really don't. :P
<infinity> (except for server)
<slangasek> ah :)
<slangasek> infinity: looks good to me
<infinity> You counted case/;; agreement, didn't you?  I can only assume that was the delay.
<infinity> My eyes crossed when I did it. ;)
<slangasek> yes, I did :)
<infinity> Should hit the queue in 2 seconds.
<infinity> If you'd like to accept for me.
 * infinity considers exporting VISUAL=vim in cdimage@antimony's bashrc... This nano business offends me.
<slangasek> 'cepted
<infinity> Danke.
<infinity> And now I delay the preinstalled dailies, so we actually get something fixed in before another 25 hours passes.
<infinity> Are LP automagic bug closures broken, or am I just being impatient?
<infinity> (Should happen on ACCEPT, surely?)
<pitti> cjwatson: would be nice, yes; usually we have the 7 day maturing period for regressions, but as this doesn't "naturally" get tested by people using -proposed, it would be good to know that regular installs still work
<pitti> infinity: still awake?
<pitti> I'm reviewing other people's gnome updates, but it would be nice if someone could review my uploads (glib2.0, nautilus (trivial), gnome-online-accounts, eog, gedit-plugins
<slangasek> pitti: I see two breaks: added for the gdbus ABI change.  Is it certain that this is all that's affected, has anyone searched the revdeps for symbol references?  And how recently was the API introduced - could conflicting with old versions of nautilus cause more harm than good for upgrades?
<seb128> slangasek, I can reply for that
<slangasek> seb128: heya
<seb128> slangasek, the api was added mid-oneiric, I've grepped through main on a dc machine
<seb128> upstream grepped through the GNOME git as well
<seb128> only nautilus and gnome-online-account showed up
<slangasek> ok
<seb128> I checked with dx as well to make sure they don't use the gfbus generator, they don't yet
<seb128> it will only break the current oneiric version of nautilus
<seb128> gnome-online-account is a new source in oneiric
<seb128> so the breaks are useful for oneiric upgraders during a day or so
<seb128> we don't need it for natty->oneiric
<slangasek> I would go further and say it's important to remove the breaks for natty->oneiric, so we don't make upgrade calculations more difficult than they need to be
<slangasek> maybe I'm being paranoid, but we've recently seen breaks negatively impacting upgrades, so...
<slangasek> (gcj-4.4)
<pitti> right, i also grepped unity
<pitti> slangasek: ok, I'm fine removing them
<seb128> I've checked with ted, they didn't have time to use the gdbus generator yet
<pitti> slangasek, seb128: I tested nautilus with the new glib, and didn't find any breakage
<pitti> g-o-a didn't work, but that could just as well have been the old version
<seb128> it's not really a feature change
<seb128> just a namespace tweak
<slangasek> pitti, seb128: well, accepted this version - a further upload later in the week to drop the breaks may be the right thing to do
<pitti> I just tested the new g-o-a and new glib, and that works fine
<seb128> slangasek, thanks, agreed
<pitti> slangasek: I can remove it right now
<pitti> slangasek: well, let's say, I'll upload it once that version built, just in case there's some armel trouble again, etc.
<seb128> pitti, well, maybe save a glib update for tomorrow in case any post . patch land in git?
<pitti> seb128: sounds good
<seb128> post 3.2
<seb128> who broke my keypad? ;-)
<pitti> slangasek: bah, I suck -- turns out that I forgot a comma, which effectively dropped the two new breaks: :/
<pitti> slangasek: funny retroactive "do what you mean"
<slangasek> pitti: ah shoot - does that give a build failure due to broken syntax, then/
<slangasek> ?
<pitti> no, it built fine here
<pitti> I actually had expected it to fail on "cannot parse dependency" or so
<slangasek> yeah
<pitti> hm, I built it about three times, but not sure whether i rebuilt the whole package after adding the breaks
<pitti> I guess it'll fail then; fixed in bzr, I'll upload again once it does
<pitti> sorry about the mess
<pitti> slangasek: so, of course it failed to build, sorry; ^ fix
<pitti> I mean, I just uploaded the fix
 * pitti accepts glib2.0, we discussed it above, and the diff is quite trivial
<cjwatson> pitti: would you mind acking my debian-installer/natty-proposed upload?
<pitti> cjwatson: good morning; sure
<pitti> looks fine, accepted
<pitti> cjwatson: ^ would you mind reviewing ubuntu-defaults-zh-cn?
<pitti> I also uploaded gnome-online-accounts (part of gnome 3.2 finals), would be nice if you could ack this as well
<jamespage> hello
<jamespage> please could a member of the release team review FFE bug 851659
<ubot4> Launchpad bug 851659 in jenkins (Ubuntu) (and 4 other projects) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/851659
<jamespage> required to support eclipse 3.7
<doko> jamespage, commented
<jamespage> thanks doko; still needs a release team ack if anyone is around
<pitti> jamespage: done
<pitti> jamespage: want to sync yourself, or need a sponsor?
<jamespage> pitti, need a sponsor for that one please
<pitti> jamespage: asm3 synced
<jamespage> pitti: thankyou
<doko> pitti, please accept java-common, fixing broken /usr/lib/jvm/default-java symlink
<cjwatson> pitti: done
<doko> cjwatson, pitti: please accept java-common and openjdk-6. java-common isn't really necessary, but will unbreak the dangling symlink faster on all archs
<pitti> doko: accepted j-common; still waiting for the diff to appear for openjdk
<pitti> uploaded debian-gis and osm2pgsql to fix NBS
<tumbleweed> bdrung: we were expecting an eclipse FFe for the last month. glad to finally see it. I have no previous experience with the package, and it is rather close to final freeze. Are we pretty confident about wanting this?
<bdrung> tumbleweed: we had to get some deps updated before we can get eclipse in (that delayed it).
<bdrung> tumbleweed: 3.5 is very old and it used xulrunner (see the workaround to get rid of xulrunner). eclipse 3.7 uses webkit by default
<tumbleweed> bdrung: right. And you are ready to deal with any last-minute issues from it?
<tumbleweed> err yeah, I can see why we'd want it with webkit
<infinity> bdrung: I highly approve of the xulrunner->webkit thing, but yeah, this is pretty last-minute.  Are these packages actually testing?
<infinity> tested*
<bdrung> tumbleweed: eclipse 3.7 lived in experimental for a long time (will be uploaded to unstable soon).
<tumbleweed> right, that helps
<bdrung> infinity: it lives in the ppa. i did some small testing and one user is using the ppa version (and it works for him)
 * bdrung will be afk for two hours.
 * tumbleweed grants the FFe
 * micahg hugs tumbleweed and bdrung
<doko> https://launchpadlibrarian.net/81207327/buildlog_ubuntu-oneiric-armel.xzgv_0.9%2Bsvn40-1ubuntu1_FAILEDTOBUILD.txt.gz
<doko> seb128, pitti: which gtk/gnome libary causes these build failures?
<doko> it's not the only one, and I think it's too late for such changes. please could you consider reverting this?
<doko> skaet, ^^^ repeating here, you're not on #ubuntu-devel
 * skaet goes to edit her auto logins for Freenode,  silly reboot.
<doko> did see similiar build failures on some theme packages
<skaet> thanks for repeating it here doko.
<seb128> doko, no idea
<seb128> reverting> no
<seb128> we just updated from a .90 in unstable series to stable
<seb128> those updates have only a few selected import bug fixes, it doesn't make sense to "revert"
<seb128> if there is a bug we should find and fix it
<micahg> seb128: I think that's this: http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00236.html
<seb128> that one is not recent though
<seb128> it's like a month old
<micahg> that build failure is almost 2 weeks old also
<micahg> oh, no it isn't...
<micahg> seb128: right, but I think it happened after the amd64/i386 rebuild
<micahg> and started to manifest in the armel rebuild
<seb128> it doesn't really make sense to add bugs back though
<seb128> if as-needed is breaking things maybe turn that off for the end of the cycle and back next cycle?
<micahg> we did that last time :)
<doko> no. we did fix all known issues
<seb128> well apparently not, you just pointed one
<seb128> ;-)
<doko> these were introduced between the x86 rebuild and the arm rebuild
<doko> seb128, a FFe for gtk/gnome packages doesn't mean that you don't have to fix regressions
<seb128> doko, that's not a regression
<seb128> it just expose application which rely on something else to call -lm for them when they use it
<seb128> "sources" rather than "application"
<seb128> i.e those softwares are buggy, it just happened that the bug was not showing because something else was bringing in an implicit way what they need
<seb128> the corresponding commit is http://git.gnome.org/browse/gdk-pixbuf/commit/?id=d430bc4df3314a88cd538474d26ff7764d1f408c
<seb128> we could revert it for oneiric as a workaround I guess but still that's not a bug
<seb128> those source will need fixing next cycle
<doko> seb128, skaet: it is a regression. the x86 builds did succeed: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+sourcepub/1865274/+listing-archive-extra
<seb128> doko, define regression
<doko> seb128, doesn't build, when it did build before. that's what counts for buildability
<seb128> those sources are buggy and instead of declaring the depends they need they happened to work because others were pulling requirement for them
<seb128> it's technical neither a bug nor a regression on the gdk side
<doko> then don't change the requirements after feature freeze
<ScottK> seb128: If they were depending on stuff they only indirectly depended on, that's a bug, IMO.
<seb128> that's barely a feature, it's a fix, it was leading softwares to link to libraries they don't need
<seb128> ScottK, it's a bug from their source, they use lm and need -lm which gdk happened to bring for them but they can't rely on that
<seb128> if they use lm they need to have -lm in their flags
<ScottK> Sounds right to me.
<seb128> I'm fine putting the extra flags in gdk as a workaround for those buggy source
<seb128> but I disagree that's a feature freeze break or a regression
<skaet> seb128, noted.  Thanks.
<micahg> doko: there are only ~75 failures in the armel rebuild that aren't depwait and most aren't in a packageset, maybe just put out a call for help fixing them (if it's this issue, it should be easy for almost Ubuntu dev)
<seb128> how many of those -lm bugs do we have? just curious
<doko> seb128, the bad thing is that we don't know it
<seb128> so let's revert the commit as a workaround, I will do that
<seb128> still I will drop it early next cycle ;-)
<doko> three did fail in gtk-engines-*, this is the fourth one
<doko> seb128, right, sounds fine at this stage
<doko> micahg, I think some of these need some planning, like all the OpenGL/Gles issues
<micahg> doko: yeah, wasn't sure how many were -lm vs OpenGL/Gles
<doko> micahg, the issue is that somebody has to look at these, maybe better file bug reports. waitung now for weeks on this ...
<micahg> doko: if you can file the reports you might get some people's attention
<doko> ARM/Linaro did commit to do that
<infinity> There's nothing we can do about GL/GLes in some cases.
<infinity> Not without a lot of porting effort, that is.  These aren't always "quick FTBFS fixes".
<doko> infinity, micahg these are seen very often: https://launchpadlibrarian.net/81210497/buildlog_ubuntu-oneiric-armel.ratbox-services_1.2.4-1_FAILEDTOBUILD.txt.gz
<infinity> doko: That hardly looks arm-specific.
<micahg> looks like a toolchain on arm bug ;)
<infinity> doko: That header defines the user struct on amd64 too.
<doko> infinity, didn't ftbfs
<infinity> doko: That's nice.  Maybe the header changed? :P
<infinity> Or, maybe something started including it that shouldn't have...
<infinity>  /* The whole purpose of this file is for GDB and GDB only.  Don't read too much into it.  Don't use it for anything other than GDB unless you know what you are doing.  */
<infinity> ^-- A bit of a scary warning. :P
<infinity> doko: If you're seeing that class of failure "often", then user.h is almost certainly being included by some more common/standard header.  If so, we should find this and make it stop. :P
 * infinity will have a quick hunt after a smoke and root beer run.
<Daviey> can an AA nack keystone please.
<infinity> Daviey: It's broken?
<infinity> Well, it's also a huge diff...
<Daviey> infinity: being superseeded
<dblawson> I'm putting the buildds on manual for a bootstrap briefly
<dblawson> Done, back to auto
 * Daviey reviews ^^
<Daviey> slangasek: Do you have thoughts on  openssl in queue, related to another c_rehash issue?
<Daviey> RE: dovecot, have a few questions to ask the sponsor - will follow that up tomorrow, in his TZ.
<infinity> Daviey: You might want to reject it if you have concerns to discuss, or someone else might decide to accept when you're not looking. :/
<infinity> (This has happened to me a few too many times)
<infinity> We really need a "being looked at, don't touch" queue.
<Daviey> infinity: Annoyingly, i don't have foo to do that.
<Daviey> or at least a comment field.
<slangasek> Daviey: cjwatson briefed me on it earlier, I'll have a look at it
<Daviey> I'm sure dgetting from the queue used to work.. :/
<Daviey> cool
<infinity> doko: So, that class of failures is due to sys/ucontext.h on ARM including sys/procfs.h ...
<Daviey> Can orchestra be accepted please.
<Daviey> jdstrand: Are you confident your patch for libvirt will be accepted upstream?
<Daviey> (Silly question, because we need it anyway)
<jdstrand> Daviey: well, I am the upstream author of the security driver. I noticed that someone sent a patch for something else with unidirectional pipes like 5 minutes after I did (not for the apparmor driver)
<jdstrand> Daviey: it's conceivable that they will have me iterate on it-- but the patch is solid as is and acceptable for ubuntu. I can reupload or refactor for 'p'
<jdstrand> if required
<Daviey> nah, i just wondered really.
<jdstrand> they've accepted everything from me. on occasion they have had me redo something based on some other stuff they were working on
<Daviey> jdstrand: It was lots more work than i expected it to be.. make sure you collect beer tokens from ubuntu-server at UDS.
<jdstrand> heh
<Daviey> can libvirt be accepted please.
<jdstrand> depending on what happens with the latest pipe code, I might have to iterate, but that is all 0.9.7 stuff anyway
<Daviey> reject dovecot for now please
<Daviey> Happy times.
<Daviey> Are any AA's around?
 * Daviey launches a big *sigh*
<infinity> Daviey: I might be.
<infinity> Daviey: libvirt+ dovecot-
<Daviey> \o/
<Daviey> orchestra+
<Daviey> reviewing glance
<Daviey> zul: Does glance need to wait for pending nova upload?
<zul> no it shouldnt
<Daviey> infinity: thanks
<Daviey> don't go anywhere!
<zul> nova should be there now
<Daviey> Can any spare AA accept glance please, looks good.
 * Daviey now looks at nova.
 * Daviey wonders if there is any point in him reviewing stuff.
<infinity> Daviey: Just ping me with a list of things that have your +1/-1, I'll get to it when I take breaks from my own work.
<Daviey> infinity: thanks
<Daviey> infinity: nova+1
<Daviey> infinity: glance+1
<dobey> hey release guys; could someone approve these please? :) https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=ubuntuone
<stgraber> just pushed a new edubuntu-artwork hiding two entries that we don't want in our menus (nepomuk). I just realized this may have needed a UIFe from edubuntu-docs. As a member of edubuntu-doc and the guy who's going to do the screenshots, I don't have a problem with that change and I know these two entries don't appear in any of our documentation.
<Daviey> dobey: I'm really not confident in reviewing a new upstream version of ubuntuone*, especially without a changelog of what it does.
<Daviey> Not to mention it's flippin' huge, looks like artwork changes and strings.
<Daviey> Does it have an FFe already?
<stgraber> Daviey: could it be bug 849494 I seem to remember seing this one in my mails recently
<ubot4> Launchpad bug 849494 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "String freeze exception: still offers Evolution plug-in for contact sync in Oneiric (affects: 3) (dups: 1) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/849494
<dobey> Daviey: artwork changes and strings?
<infinity> Is there a permanent FFe for ubuntuone, like we have for GOME?
<dobey> no
<Daviey> infinity: no.
<infinity> If not, while I'm inclined to review this anyway because it fixes some important bugs, huge diffs like this at this point in the release are pretty unacceptable. :/
<seb128> infinity, well, even with a ffe that's not really a good sign
<infinity> At least, for packages that are installed on nearly every ubuntu desktop in the world.
<dobey> which huge diff?
<seb128> GNOME has a ffe because they don't do such diffs that late ;-)
<infinity> seb128: Some of GNOME's late changes can get this large.
<dobey> ubuntuone-control-panel?
<Daviey> dobey: I'm seeing pot translation changes in ubuntuone-control-panel?
<dobey> GNOME also doesn't have a bunch of extra code inside the same source tree, to support another platform, independent of linux
<infinity> Irrelevant.
<Daviey> dobey: I wrongly assumed the binary blob in ubuntuone-control-panel-2.0.0/ubuntuone/controlpanel/gui/qt/ui/images_rc.py was an image, what is it?
<infinity> Like I said, I'm inclined to spend some time reviewing it anyway, but at this point in a release cycle, we want specific bugfixes (even if that means backporting patches), not large new versions.
<dobey> Daviey: compiled qt UI code for the windows port
<dobey> Daviey: though not sure why that would be in the diff
<Daviey> dobey: Ah, ok - i assumed it as a diff representaton of an image.
<dobey> Daviey: anything with 'qt' in the filename path can be ignored, because we don't install that on ubuntu; that's the windows stuff
<stgraber> dobey: http://launchpadlibrarian.net/81223413/ubuntuone-control-panel_1.1.3-0ubuntu1_2.0.0-0ubuntu1.diff.gz in case you're wondering what's in the diff
<Daviey> dobey: Off Topic, being upstream - does it make sense to ship that in the same orig tarball?
<doko> infinity, https://launchpadlibrarian.net/81225550/buildlog_ubuntu-oneiric-armel.easymp3gain_0.5.0-6_FAILEDTOBUILD.txt.gz looks like an incomplete fpc transition, there are more ...
<dobey> Daviey: it doesn't make any sense not to. as an upstream i don't want to maintain a different release for every different platform. ideally there would only be one UI and one set of code, but we are in an odd place with that at the moment, though will improve over the next 6+ months
<dobey> Daviey: i really have no idea why exactly the pot file is just a big block of ----- in that diff :-/
<Daviey> :(
<infinity> doko: The user.h thing is a bug in ARM's ucontext.h, BTW.  It's the only arch that includes (and always had included) procfs.h instead of carrying local typedefs like the others.  I guess something recently started including ucontext that didn't before, thus the chain reaction explosion.
<dobey> Daviey: it gets generated at build time anyway
<infinity> doko: I imagine we should rewrite ucontext.h and push it upstream, but I don't see that happening in the next 2 days.
<dobey> Daviey: so the pot file itself being there really doesn't make any difference afaik
<Daviey> dobey: Hmm, doesn't LP pull in the translations from source packages, rather than binary?
<Daviey> s/translations/template/
<dobey> Daviey: i don't know about launchpad, but the u1 strings get pulled out by the langpacks magic at build-time
<dobey> as i understand it
<infinity> LP translations are from the build-time tarballs, yes.
<infinity> If by "LP", you mean Rosetta.
<infinity> (Okay, so it hasn't been called that in 5 years, but "launchpad translations" felt ambiguous)
<infinity> langpacks? :)
<dobey> the strings for things in the default seed are pulled out by langpacks after the "build" portion of the package building afaik
<infinity> Daviey: Pulling translations from source packages would be nearly impossible.
<infinity> Daviey: We do it post-binary-build, when the files actually have sane names and locations and such.
<doko> infinity, if you don't know what, then call it multiarch
<infinity> doko: I really doubt it...
<Daviey> infinity: ah, ok - thanks
<doko> something did change in the order of inclusions. at least on i386 where the x86_64 headers are used. not sure on arm
<infinity> doko: I can keep tracing it back, but I'm not sure I see the point.  There's no harm in including sys/ucontext.h, except on ARM, so it's more likely an ARM bug that's been sleeping for 7 years than something we can blame on others.
<doko> anyway, some more packages fixed in the next cycle
<jamespage> dovevot
<jamespage> dovecot
<infinity> Yeah.  I think I'll put a pin in this *glibc bug, but I should rewrite that header.
<infinity> I just love that it's been like this ever since the port started in glibc CVS and, apparently, no one's included it until now.
<infinity> Actually, that in itself might be a sign that maybe the bug is that it shouldn't be included at all.  Maybe I'll trace back further.  The part where it works on other arches may just be a happy accident.
<Daviey> jamespage: hey
<jamespage> I should learn to type ctrl-f first
<Daviey> hmm
<jamespage> Daviey: you had questions?
<Daviey> jamespage: Can you expand on reasoning for:
<Daviey> +    - debian/mail-stack-delivery.postinst: drop -n flag from dovecot deliver
<Daviey> +      command in postfix configuration.
<jamespage> Daviey: -n is not longer a valid flag as far as I can see
<Daviey> ah, ok
<Daviey> and:
<Daviey> -        imap_client_workarounds = outlook-idle delay-newmail
<Daviey> +        imap_client_workarounds = delay-newmail
<Daviey> correct, right?
<jamespage> OK; so dovecot is actually quite helpful
<jamespage> I reviewed all of the warnings that where generated by the current configuration
<Daviey> And it wanred that outlook-idle was deprecated?
<jamespage> this option is no longer required by which I assume its implicit rather than explicit
<Daviey> jamespage: The one which concerned me really was, http://pb.daviey.com/gqzT/
<Daviey> It looked like a potential typo, wanted to make sure.
<jamespage> both of the _file options are deprecated
<Daviey> jamespage: but re-added with "<" there?
<jamespage> I tested this on a local install to ensure that imaps was working OK with that configuration
<jamespage> picks up the new config fine
<doko> infinity, the fpc issues track down to the lazarus ftbfs
<Daviey> jamespage: did the warnings suggest you add a '<'?
<jamespage> yep - and that is as documented in examples provided in package as well
<Daviey> jamespage: ah, ok - super!
<Daviey> jamespage: sorry for doubting you. :)
<jamespage> Daviey: np - I was quite surprised - I was actually just testing utlemming proposed change to the upstart config and discovered it was all borked
<Daviey> jamespage: well if you will test stuff, you are more likely to find issues.. best not to test :)
<dobey> i wish i could make the diff only show changes relevant to ubuntu, but alas
<jamespage> Daviey: we should probably have a test for mail-stack-delivery - thats the second time I've discovered it non-functional a few weeks before release...
<Daviey> :/
<Daviey> good thinking.
<Daviey> infinity: can you un-reject dovecot please, and accept? ;)
<infinity> Done.
<Laney> dobey: you can provide a filtered diff on a bug or whatever
<Laney> filterdiff is your friend
<dobey> hmm
<infinity> doko: Indeed.  Retrying lazarus on armel and powerpc, but I assume they'd fail again.  Any idea what's gone wrong there?
<doko> infinity, tell me how to turn on verbose build logs ...
<SpamapS> re the ensemble rename to juju .. which I'm almost done testing..
<infinity> doko: Happy to do a local build, if you have an idea of what to look for.
<SpamapS> Would it be better to keep the source package name ensemble and just introduce juju as a new bin package, or let it come in as a NEW source package?
<infinity> SpamapS: NEW source is fine, we'll just have to manually diff it.  Not the end of the world.
<infinity> SpamapS: I assume the new source still builds ensemble-ish binary packages for transition purposes, though?
<SpamapS> Just thinking about bug tracking, people will likely want to report bugs in juju, not ensemble
<ScottK> Since it's a new package this cycle, I'd rename the source
<SpamapS> infinity: it builds a transitional package so people with ensemble installed will get juju, and a /usr/bin/ensemble which displays a disclaimer.
<infinity> SpamapS: Kay, good enough for me.  Yeah, new source makes more sense.
<SpamapS> ack, thx
<dobey> filterdiff is not my friend :(
<doko> infinity, got it, multiarch ...
<infinity> doko: Is that the answer for everything now? :)
<slangasek> infinity: not for everything, just the bugs
<doko> infinity, yes I fixed all ld --as-needed issues ;)
<slangasek> hey, multiarch broke NM, so it can break anything :)
<skaet> :P
<dobey> Laney: filterdiff -x qt changes.diff seems to not do what --help says it should do :(
<dobey> anyway, i need to go now
<Laney> add some *s
<dobey> Laney: ah, none of the other actual regex stuff i was doing worked either but "*qt*" seems to have done it :P
<Laney> :-)
<dobey> http://people.freedesktop.org/~dobey/ucp-ubuntu-2.0.0.diff
<dobey> much shorter without all the windows code in the way
<dobey> anyway, i do have to go :)
<infinity> slangasek: You want to review that ca-cert upload from lool, since it seems to be more fallout from your headache? :)
<slangasek> maaaan
<slangasek> looking
<doko> powerpc looks messy after the last gnome orgy
<doko> infinity, fpc waiting ...
<infinity> doko: When the queueu munger gives me a diff.
<slangasek> lool: why does ca-certificates add a conflicts: on the old openssl instead of a Depends: on the new one?
<slangasek> lool: (fwiw I'm inclined to reject this upload for that)
<infinity> doko: Is the upstream for foo-plugins @gentoo? :P
<infinity> doko: That entire CFLAGS line is pretty suspect, not just the sse.
<Daviey> keystone looks good, can it be accepted please?
<slangasek> Daviey: done
<slangasek> ^^ bugfix-only flashplugin upload, touches up a few spots I missed with the previous one
 * infinity grumbles about file renames making the package one enormous diff.
<Daviey> slangasek: thanks
<slangasek> infinity: what package was that?
<infinity> slangasek: fp-nonfree
<slangasek> infinity: there shouldn't have been file renames in the latest - only a directory rename (due to the native package)
<infinity> slangasek: Yeah, but the autogenerated diff was against the one in the archive, not the one in the queue.
<infinity> Anyhow, reviewed and accepted.
<slangasek> infinity: oh; I thought 10ubuntu4 was already accepted long enough ago that LP would've gone against that
<slangasek> but it seems not... something wrong with the publisher?
<infinity> slangasek: ubuntu4 was still in unapproved.
<infinity> slangasek: I just rejected it.
<slangasek> oh
<slangasek> odd, I was sure I saw an accept earlier
<infinity> Odd indeed.
<slangasek> maybe I just imagined it because mdeslaur started talking to me about it :)
<mdeslaur> slangasek: I wasn't accepted yet when I looked at it
<mdeslaur> s/I/It/
<slangasek> yeah :)
<slangasek> infinity: anyway, by the time I was done gutting the maintainer scripts, might've been shorter to review the whole package than the diff ;)
<infinity> slangasek: Which is what I ended up doing. :)
<slangasek> :D
 * Daviey would accept orc (1:0.4.14-1ubuntu1), if he could.
<infinity> Is that a hint?
<Daviey> builds, and sensible upstream cherrypick, fixes a bug.
<doko> slangasek, infinity: please give back the powerpc builds once gtk-3.0 is in the archive
 * micahg confronts orc with a 12 damage dragon...
<doko> afk now
 * infinity is trying to decide how to feel about that libav upload.
<micahg> did siretart upload the 63 patch change?
<infinity> Yup.
<infinity> And actually, the 63 upstream cherrypicks worry me less than multiarching 2 days before final freeze.
<infinity> Unless those m-a changes are well-testing in Debian already?
<micahg> yeah...
<infinity> tested*
<micahg> I think multiarch was only uploaded last week to debian for libav
<doko> reject it. we don't have a chance to test this
<infinity> That's my feeling too.  Someone needs to re-upload with the CVE fix, though.
<micahg> infinity: worse, uploaded Friday :D
<infinity> micahg: If it's Friday where you are, I want to be in your timezone.
<micahg> infinity: no, libav w/multiarch was uploaded to Debian last Friday
<infinity> Ahh.
<Daviey> debian-gis, uploaded by pitti - postgresql-8.4-postgis -> postgresql-9.1-postgis, change.. Would be good to know if it should be "postgresql-9.1-postgis | postgresql-8.4-postgis", rather than a straight change.. as postgresql-8.4-postgis is still in Oneiric (should it be?).
<micahg> infinity: tomorrow is my Friday this week though :D
<slangasek> infinity: I actually have a multiarching coming yet, but I'm going to rebuild-test the lot of revdeps
<slangasek> (libjack... the *right* libjack, instead of the wrong one I already converted this cycle but isn't installed by default, feh)
<infinity> slangasek: Feel free to unreject libav if you think it's even remotely testable for sanity, but it just seems risky to me.
<slangasek> nope
<slangasek> doko is right, multiarching libs needs to come with pre-upload regression testing
<infinity> Or with the flood of opening a new release and some random prayer? :P
<micahg> with libav that's almost impossible at this point
<infinity> Cause you know we'll see this same upload again in 2.5 weeks. ;)
<micahg> infinity: anyone running pre-alpha1 shouldn't mind the breakage
<infinity> slangasek: So, what you're saying is that when you regression-tested the (wrong) libjack, everything worked smashingly because nothing was linked to it? ;)
<slangasek> yep!
<infinity> Well done!
<slangasek> and this is why libasound2-plugins:i386 isn't installable for users of freshly-installed amd64 systems
<slangasek> (but works great for those of us continuously upgrading since lucid :P)
<infinity> Aww.  I was about to get excited about how the best upstream version bump is when the diff is nothing but the version number, and then I found an actual bugfix hidden at the very bottom.
<slangasek> infinity: we wanted a conffile for dpkg multiarch, right?
<infinity> slangasek: I do believe we wanted to make sure upgrades looked the same as new installs, and taking over the installers' /etc/dpkg/dpkg.cfg.d/multiarch as a conffile seemed like a sane way to go.
<infinity> slangasek: It also lends the path a certain bit of canonical credibility, should other people feel the need to do the same sort of thing in insallers in the future (so you don't end up with /etc/dpkg/dpkg.cfg.d/{multiarch,march,multi,foreignarch} depending on mood and moon phase)
<slangasek> infinity: yah, just checking that 'conffile' is sane from your POV
<infinity> slangasek: I was happy with config file too, but conffile does lead to the path credibility argument.  Shows up in dpkg -S and everything.
 * slangasek watches dpkg utterly fail to notice it's not actually building for the architecture I asked it to.  oh, irony
<slangasek> that's ok, building an i386 .deb containing amd64 code is easier than trying to get it to actually cross-build, so this is a sufficient test :)
<infinity> Heh.
 * infinity wanders off to hunt a sandwichbeast.
<slangasek> infinity: can you review dpkg post-hunt?
<slangasek> bjf: fix for bug #846451 in the dpkg upload waiting in the unapproved queue; feel free to grab/build/test
<ubot4> Launchpad bug 846451 in dpkg (Ubuntu) "upgrades from oneiric beta-1 installs missing multiarch support (affects: 3) (heat: 16)" [High,Fix committed] https://launchpad.net/bugs/846451
<doko> slangasek, infinity: gtk3.0 built on powerpc. please give back powerpc builds in 1h
<doko> good night
<slangasek> doko: which builds, specifically?
<doko> slangasek, all in main, which don't have ftbfs bug report
<doko> http://qa.ubuntuwire.org/ftbfs/
<slangasek> hum, I don't know of a sane way to query that, so I'll defer to infinity
<slangasek> ah
<slangasek> ok
#ubuntu-release 2011-09-28
<Daviey> cyphermox: tracker, build1 and this build2 - both No change rebuild against libcamel-1.2-29?
<ScottK> doko: Looks like they're all retried.
<infinity> Did someone really go do that manually?
<infinity> I was about to just do it as a batch. :P
<ScottK> I did the ones that weren't done already.
<ScottK> LP is pretty fast tonight, so it didn't take very long.
<infinity> You really shouldn't have said that.
<infinity> You'll jinx it.
<ScottK> (mindless work while supervising youngest child's violin practice)
<ScottK> You're assuming I care.
<ScottK> My work is done ....
<infinity> Anything to take your mind off the screeching?
<ScottK> ;-)
<ScottK> It was plucking, but yeah.
 * micahg would've piped the ubuntu-desktop packageset list to ubuntu-build for powerpc
<slangasek> I was sure that sentence was going to end "to /dev/audio"
<infinity> The only thing being piped to /dev/audio right now is Master of Puppets.
<slangasek> infinity: could you review the dpkg in the queue?  it should be as easy as it looks
<infinity> slangasek: And as long as the hash of the installer-created files is the same (ie: they have those exact contents), we get no prompts on hijack, right?
<slangasek> that's my experience, yes
<infinity> It's been a while since I've dealt with hijacking.
<slangasek> (tests clean here... so unless I screwed up the conffile contents, we should be good)
<infinity> Kay.  Assuming you installed it over a pre-existing file, and it didn't asplode, yay.
<slangasek> i.e., unless I screwed up my local file prior to unpacking dpkg over it
<infinity> Heh.
<infinity> Accepted, and back to wishing I still had hair.
<slangasek> ...
<slangasek> ... thanks? :)
<infinity> Those were two reasonably unrelated thoughts.
<cyphermox> Daviey: yes
<pitti> Daviey: postgresql-8.4-postgis is NBS, so it shouldn't be an alternative dependency
<pitti> Daviey: that's why the uploads were necessary in the first place
<pitti> now just waiting for powerpc to finally catch up
<ScottK> FYI, those ^^^ are my uploads, so I need someone to review.  They're just a straight pull from upstream, no fanciness.
<infinity> I only review fancy uploads.
<ScottK> It did involve using git, so it's kind of fancy ...
<pitti> ScottK: I'm watching the queue anyway between builds and sponsors, will get to them, too
<ScottK> pitti: Thanks.
<infinity> Looks sane to me.
<Daviey> pitti: ah!  Makes sense :)
<lool> slangasek: ca-certificates needs to run the fixed c_rehash; a Depends would be fine I guess
<micahg> pitti: I take your request to upload blueman as an ACK?
<pitti> micahg: ah, it was meant to be; I thought Stefano already acked it
<micahg> pitti: he wanted more info
<pitti> but as this now is more or less a Xubuntu specific thing, if you and charlie-tca are happy with it, that's fine
<micahg> and testing
<micahg> pitti: ok, thanks, will upload in a bit, still trying to get some updates out ATM
<pitti> can someone please review my gobject-introspection and apport uploads?
<pitti> cjwatson maybe?
<pitti> thanks!
<cjwatson> ... too slow
<cjwatson> (wasn't me)
<cjwatson> apport's fine, accepted
<lool> cjwatson: would you kick ca-certificates?  I'll reupload it with a bumped Depends instead of a Conflicts
<cjwatson> lool: no ca-certificates in the queue
<lool> 01:22 -queuebot:#ubuntu-release- Removed package: ca-certificates
<lool> sorry, missed that in the log
<lool> reuploaded
<tjaalton> guess this is a better place to ask for a FFE. bug 860297
<ubot4> Launchpad bug 860297 in sssd (Ubuntu) "FFE: sssd 1.5.8 -> 1.5.13 (affects: 2) (heat: 14)" [Wishlist,New] https://launchpad.net/bugs/860297
<infinity> tjaalton: Upload away, the upstream changelog and justifications seem sane.
<Daviey> didrocks: Am i being crazy?  sni-qt - - build-dep on debhelper 9 (fix lintian warning as debian/compat is 9) .. Is 9 in oneiric?
<infinity> tjaalton: I'll leave it to someone else to review, though, it's 4am here, and I need sleep. :P
<infinity> Daviey: It sure isn't.
<tjaalton> infinity: ok, thanks!
<didrocks> Daviey: no, I am crazy, sorry, I wanted to change debian/compat, reject it :)
<Daviey> heh.
<didrocks> Daviey: shouldn't do things while on the phone I guess :)
<pitti> didrocks, Daviey: compat level 9 is in natty or even earlier
<pitti> it's mainly for multiarch compat
<cjwatson> yes, it just isn't final yet
<pitti> ^ that's why it's still dh 8.x
<cjwatson> but you don't actually have version 9
<pitti> but yeah, we shouldn't bump it for no reason
<cjwatson> as the lintian-info for that note says, if you're using a non-final version of debhelper, you should override lintian, not add a build-dep on a nonexistent version
<micahg> pitti: can you copy firefox 3.6.23+build1+nobinonly-0ubuntu0.10.04.1 from ubuntu-mozilla-security to lucid-security?
<Daviey> pitti: was i wrong?
<pitti> Daviey: haven't seen the patch; but a >= 9 build dep is of course wrong
<pitti> Daviey: I thought you meant bumping compat to 9
<Daviey> ah, no - i don't care about that.
<Daviey> pitti: sorry, i thought you were correcting me :)
<cjwatson> ngg, d-i ftbfs
* pitti changed the topic of #ubuntu-release to: Beta 2 released! (Archive freeze remains in effect.) | http://pad.ubuntu.com/ubuntu-release | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<pitti> moved our etherpad to pad.ubuntu.com, which is hopefully  more stable
<pitti> and left a pointer in the old one
<Daviey> The old one was run by a plonker aiui.
<didrocks> Daviey: pushe a new sni-qt, sorry for the oversight
<didrocks> pushed*
<micahg> is another archive admin available for a copy?
<pitti> micahg: sorry, was in a meeting and then stuck in the chinese image fix
<pitti> micahg: can do now
<micahg> pitti: no problem, just didn't want to miss the next publisher :) (I know I have a half hour)
<pitti> cjwatson: so, above live-build fixes --package with local .deb; I used that to build a new chinese iso with the new defualts package which also just landed in the queue, and it built a nicely sized and working iso
<cjwatson> ok, reviewing
<cjwatson> I wish queue diff generation were instant and magic
<pitti> micahg: done
<micahg> pitti: thanks!
<pitti> cjwatson: not that urgent, fine to do it in an hour or two even; just wanted to give some context how I tested
<pitti> cjwatson: once it's in, I'll re-spin another chinese build to double-check the size
<cjwatson> s'ok, accepted now
<pitti> thanks
<pitti> +1 on magic queuediff, though
<pitti> sometimes it's weird, I see the diff in the webui, but queuediff doesn't yet
<pitti> ten minutes later it works
<cjwatson> I think that's just random HTTP failure
<pitti> must be some difference between logged in and unauthenticated
<cjwatson> in such cases retrying queuediff a few times often works
<pitti> ah, interesting
<cjwatson> or maybe depends which appserver you hit or something
<cjwatson> I wish launchpadlib had better automatic backoff/retry support
<pitti> I got so used to it that I'm getting grumpy with logging into cocoplum, fetching, and mdebdiff'ing
<didrocks> FYI, bug #732016, I'm emailing the documentation team now
<ubot4> Launchpad bug 732016 in unity-2d (Ubuntu) (and 4 other projects) "UIFe: Desktop should be titled (affects: 8) (dups: 4) (heat: 64)" [Low,New] https://launchpad.net/bugs/732016
<pitti> cjwatson: oh, seems http://china-images.ubuntu.com/oneiric/daily-live/ is not covered by auto-cleaning old images? I don't see where these images are hosted on antimony
<cjwatson> no, I've just been pruning by hand for now
<cjwatson> I'll go and do that
<cjwatson> cdimage/www/china-images/
<pitti> oh, thanks; can cleanup myself, too, but I was looking in /full
<cjwatson> I've nuked a batch
<pitti> http://china-images.ubuntu.com/oneiric/daily-live/20110928/
<pitti> hmm
<pitti> so i386 got smaller, but amd64 actually grew
<pitti> my own local build was 691 MB (amd64)
<pitti> will investigate in a few
<jdstrand> Daviey: fyi, patch acked
<jdstrand> Daviey: (the libvirt one you asked about)
<Daviey> jdstrand: rocking!
<ev> I'd appreciate comment from someone on the release team as to whether I can upload the changes noted in bug 861410
<ubot4> Launchpad bug 861410 in ubiquity-slideshow-ubuntu (Ubuntu) "Ubuntu screenshots need to be updated to reflect the lastest UI iteration (affects: 1) (heat: 8)" [High,Fix committed] https://launchpad.net/bugs/861410
<ev> cheers
<lool> cjwatson: Thanks for bringing attention to that other ca-certificates bug; indeed my upload fixed that one, but because it might reappear after oneiric we don't nuke the original cause of the issue (plain c_rehash in postinst), I've opted to do another upload to cleanup postinst ^
<ScottK> ev: I'd imagine you pretty much have to.
<lool> s/we don't nuke/if we don't nuke
<ev> ScottK: I just wanted to make sure I ran it past you guys first, to be sure I wasn't stepping on toes
<ev> thanks
<ev> will do
<skaet> hi ev,  why were all the properties properties changed: -x to +x)
<ev> skaet: I fixed that in the merge
<ev> it was because Christian had his branch on a vfat filesystem
<ev> but trunk to the previous uploaded version is free of that noise
<skaet> ev,  coolio.   thanks.     getting the updates in now is good by me.
<ev> great, thanks!
<pitti> ev: just answered to the UIFE, sorry for delay
<pitti> (it's really just a bug fix)
<pitti> hey skaet
<skaet> heya pitti
<ara> skaet, hello, what time is the Final Freeze? :)
<skaet> ara, 2100 UTC
<pitti> 2100 UTC
<skaet> :)
<ara> skaet, tomorrow, 21:00UTC, isn't it?
<skaet> yup.
<ara> awesome, thanks!
<pitti> skaet: so, LangpackTranslationDeadline is October 6th
<pitti> skaet: so I'd request a full export on October 6th evening, so that on Friday, Oct 7 I can build/upload the final langpacks
<pitti> skaet: that's right after RC (if we have an RC)
<pitti> does that sound alright?
<pitti> (same procedure as every year)
<skaet> pitti, yes that sounds right.   RC is going to be more like we did in Natty.
<skaet> release candidate process checklists need to be modified into LTS and non,  I suspect.
<pitti> skaet: is that the full story, with releases.u.c., announcement, etc, or just an internal testing round with QA and tracker?
<skaet> pitti,  internal testing round with QA and tracker.
<pitti> ok, as I thought
<pitti> so if we have delta langpacks for these, it's no biggie
<skaet> pitti,   I'll make a point of clarifying this at the release meeting, and take a pass at the checklist.
<jdstrand> Daviey: I see that glance got promoted. this was conditional on documentation being updated to reflect that it assumes a trusted network. is this captured in a bug somewhere? was this already done?
<pitti> ^ behold! last package for GNOME 3.2 final
<pitti> and it's trivial, just updated Thai translations
<pitti> we reviewed the other stuff on http://people.canonical.com/~platform/desktop/versions.html, and this was the only one left
<skaet> :)
<pitti> there might be some .1 post-release bug fix upstream updates before we release,of course
<ScottK> For RC, we just have to remember that when we say an image is a release candidate image, we actually mean that now.
<pitti> for that we'd need to adjust the langpack translation deadline
<pitti> if we put it 7 days before final release, we can't make a true RC
<pitti> at least not 7 days before
<ScottK> I had expected that to be when we started working on getting final images.  It normally takes a few days to beat down RC bugs.
<Laney> are we having a separate unseeded universe final freeze again?
<ScottK> skaet and tumbleweed: Historically final freeze for unseeded Universe/Multiverse packages has been much later (release week).  I didn't see any discussion of that this time?
<Laney> oh
<Laney> snap!
<ScottK> Laney: ^^^ I was already typing that ...
<skaet> ScottK,  Laney,   yes,  that was an oversite.   We need to come up with a process page, so it can get added and tracked.
<Laney> FinalFreeze already says it
 * skaet goes back to staring at pages. :)
<Laney> maybe add an "until [some date]" to the end of the last sentence there.
<ScottK> My recommendation would be 1200UTC on the 11th.
<Laney> don't we usually reserve the last couple of days for RC fixes only even in *verse?
<ScottK> That leaves 36 hours for OMG WTF BBQ situations and mirror sync.
<tumbleweed> seems reasonable
<skaet> ScottK,  given the number of images that need to be respun if its an kitten killer situation,  would actually like a little more margin.   What would it hurt to make it 72 hours?
<tumbleweed> surely we're talking about things that aren't seeded
<Laney> like: FeatureFreeze up until the 6th, FinalFreeze until the 11th, OMG WTF Freeze thereafter
<ScottK> This is for non-seeded stuff?
<Laney> yes
<ScottK> skaet: Images aren't relevant.
<skaet> ScottK,  its more in the lines of one more thing to track and double check.
<ScottK> We've done it this way for years.
<skaet> while doing the images, to make sure no interaction with any of the flavors.
<ScottK> skaet: I'm not aware of there ever being an actual problem from that.
<ScottK> This is too much like work and fighting with management of idiocy.
<Laney> I put a couple of words into FinalFreeze, just needs a date on the schedule
 * skaet figures to wait for ScottK to rejoin channel before continuing discussion. 
<Laney> oh, he left?
<skaet> Thanks Laney
<skaet> yeah,  at 10.03, looks like he left all the channels,  so unfortunate bit of timing.
 * Laney has parts hidden
 * skaet notes that 10.03 was her time zone.... sorry.
<Laney> http://qa.ubuntuwire.com/bugs/rcbugs/ I figure we should have a few days looking at RC bugs
<Laney> so release - 5 days or so for Unseeded Universe Final Freeze
<skaet> seems reasonable to me.   Possibly we should turn this into a thread topic on u-release mail list though,  so others can weigh in, and we can get some clarity.
<skaet> ?
<Laney> if you like
 * pitti accepts unity-lens-musicstore and holds his breath
<Daviey> jdstrand: I will make sure it is documented today.
<Daviey> (glance ssl)
<jdstrand> Daviey: thanks
<pitti> good night everyone
<skaet> good night pitti!
<lamont> ogra_: around?
<ogra_> how do you know i need t lose weight ? :)
 * ogra_ checks his webcam if its on :P
<lamont> heh
<Daviey> Hey.. I've just put a sync in for ruby-rails-2.3.. The current version will not install due ruby being too new.  This sync should fix it, new upstream version of rails.
<Daviey> bug 861524
<ubot4> Launchpad bug 861524 in rails (Ubuntu Oneiric) (and 1 other project) "[oneiric] rails is not installable (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/861524
<Daviey> As the current one cannot be used, it seems safer to just go with what is in Debian.
<Daviey> Thoughts?
<Daviey> (just goes to show nobody tested rails until today.)
<Daviey> Oh crap, it's worse than i thought
<bdmurray> cjwatson: could you approve the kerneloops upload (disabling it) now?
<micahg> skaet: I'd like to chat with you about nss/nspr when you have a chance
<skaet> micahg,  nss/nspr?   education please,  not parsing that acronym.
<skaet> :)
<micahg> skaet: the mozilla security library and portable runtime
<skaet> thanks micahg.
<micahg> skaet: nss contains the trusted root certs and it would be nice to update before release
<micahg> err, trusted root certs for some programs
<skaet> micahg,  when would the changes land?
<micahg> skaet: that's the problem, I don't think I can land it today, plus I'm off tomorrow and Friday, I was thinking to land Sunday if that would be ok?  This is something that we push out at times as security updates as well and I can do some testing before pushing it out
<skaet> micahg,  is the only thing being updated the certs, or are there some code updates happening too?
<micahg> skaet: unfortunately code updates, but NSS has a good record of not breaking binary compatibility with updates
<Daviey> micahg: What sort of SRU cadence do you do for these usually?
<skaet> micahg,  suggest prepare it up,  and then lets discuss in the channel early next monday.   we'll have a better idea how things are looking overall then,  i'm leaning to including but would like to get others on the release team's opinions.
<micahg> Daviey: usually it's been as needed to fix security issues
<micahg> or keep Firefox/Thunderbird working
<micahg> skaet: will do, thanks
<SpamapS> juju has been uploaded to oneiric's NEW queue
<SpamapS> slangasek: Hi, just an FYI,  the ensemble -> juju rename we discussed on Monday is now in the NEW queue
<micahg> skaet: we've got a potential issue that could possibly affect thunderbird upgrades from natty -> oneiric (firefox will be fixed with the Firefox 7 update for natty later this week), should I file a tracking bug? (mozilla Bug 680802)
<ubot4> Mozilla bug 680802 in Add-ons Manager "Upgrade Firefox when there is an add-on update waiting to be installed uninstalls the add-on" [Major,Assigned: ] http://bugzilla.mozilla.org/show_bug.cgi?id=680802
<skaet> micahg,  yes please.
<micahg> skaet: eta on upload would be sunday
<skaet> micahg,   understood.   Let me know the LP bug number when you have it.
<micahg> skaet: Bug #861664
<ubot4> Launchpad bug 861664 in thunderbird (Ubuntu Oneiric) (and 1 other project) "Upgrading Firefox/Thunderbird when an add-on update is waiting to be installed hides the add-on (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/861664
<skaet> Thanks micahg !
<micahg> skaet: even though it's temporary, perceived impact is high, so I'm marking it high
<skaet> micahg:  ok.
<micahg> skaet: actually, I should probably update Firefox as well for those who don't fully update before jumping to the next Ubuntu release
<skaet> yes.  seems prudent, as that may well happen. sigh.
 * tumbleweed wonders why barry didn't just sync python-peak.rules
<tumbleweed> barry: any reason you didn't sync python-peak.rules? We'll now have another tarball mismatch (not that this is particularly serious, I just rushed reviewing it in Debian, so we could sync)
<barry> tumbleweed: i'm sorry, i didn't realize you were doing that.  yeah, we should definitely sync then.  is .rules ready to sync?  .util got rejected (rightly so) so i should request a sync for that one too
<tumbleweed> no, it can't be synced now, there's a tarball mismatch :)
 * tumbleweed should have told you, I guess :P
<barry> tumbleweed: dang.  what can we do about it now?
<barry> tumbleweed: at least .util can be syncd
<tumbleweed> ah it has to be fake-synced, until there's a new upstream version
<tumbleweed> util can still be synced
<barry> tumbleweed: okay, i'll request a sync for util
<tumbleweed> thanks
<barry> tumbleweed: please confirm: i should use syncpackage to request a fake sync for .rules?  and for .util?
<cyphermox> could someone please ack network-manager? fixing the wired+wireless routing bug (bug 856333) :)
<ubot4> Launchpad bug 856333 in network-manager (Ubuntu) (and 2 other projects) "(oneiric) wired connection unnaturally slow (affects: 2) (dups: 1) (heat: 20)" [High,In progress] https://launchpad.net/bugs/856333
 * micahg hugs cyphermox
<cyphermox> micahg: heh, took way longer to figure that one out than it should have ;)
<tumbleweed> barry: you can syncpackage .util yourself, or requist an archive-admin sync, no faksync required, we don't have a tarball mismatch there
 * micahg wonders if that will also fix his own wireless routing issue
<tumbleweed> barry: .rules will need fakesyncs in the future, but it's mostly in sync now, so no need to touch it
<cyphermox> micahg: what wireless routing issue ?
<micahg> cyphermox: will have to chat later...too much to do
<barry> tumbleweed: ack, thanks.  will do .util now and we can clean up .rules for P
<cyphermox> sure, just ping me if you need me to look at it
<tumbleweed> cyphermox: if it's what I was experiencing, I was getting ethernet loops when connected by wireless and wifi at the same time (but that was a week or two ago)
<cyphermox> tumbleweed: yup
<cyphermox> traffic coming out eth0 and in wlan0 (and trouble coming in both sides)
<barry> tumbleweed: .util syncpackage'd
<tumbleweed> in that case, \o/, one less ftbfs package
<Daviey> bjf: bdmurray asked that kerneloops be disabled now, happy with that/
<Daviey> ?
<bjf> Daviey, that's ogasawara's call
<Daviey> bjf: thanks
<ogasawara> Daviey: yes, I'm fine with that
<barry> tumbleweed: well, actually not quite yet :).  we need to get .util and .rules landed and then do a rebuild of turbojson (the original ftbs).  but i've tested this locally and think it will work
<tumbleweed> barry: heh. .rules alreday landed. Yeah Itested it locally too
<Daviey> ogasawara: super
<barry> cool.  just waiting for .util and then i'll hit the big button
<infinity> bjf / Daviey / ogasawara: bdmurray has had a kerneloops upload in the unapproved queue for over a week that disables it, I've just been waiting on Final Freeze to accept it.
<Daviey> infinity: Yeah, saw it there - and bdmurray pinged about it earlier.
<infinity> Kay.
<Daviey> Seemed a good idea to check ;)
<infinity> Man, I hate how uninformative the queue UI is about syncs. :/
<Daviey> infinity: Try to get praise/blame history.
<Daviey> seems they are not attributed to anymore anymore.
<Daviey> anyone anymore*
<infinity> Really?
<infinity> That's the only info I *do* see. :P
<infinity> You get curren version, source archive, and requestor.
<infinity> But no previous version, no diffs, nothing to review, really.
<infinity> s/current/requested/
<Daviey> infinity: no, i mean once accepted
<tumbleweed> Daviey: I opened a bug for that earlier today
<tumbleweed> (err not for teh queue, for the package's page)
<infinity> Daviey: Ahh.
<tumbleweed> but yes, they should be more reviewable in the queue too. /me files a bug
<Daviey> why can't the world be perfect today..
<tumbleweed> oh, bug 851562
<ubot4> Launchpad bug 851562 in launchpad "Diff's not available for sync's on +queue page like for regular uploads (affects: 1) (heat: 22)" [High,Triaged] https://launchpad.net/bugs/851562
<infinity> Even having the previous version would be a huge help.  I can't tell if someone's trying to force over an XubuntuX version, etc.
 * tumbleweed can assure you that both of the current sync proposals are OK :)
<infinity> I'm a naturally untrusting person. :P
<cjwatson> ogra_ and other ARM folks: merry Christmas, rmadison now lists all architectures
<infinity> cjwatson: \o/
<infinity> cjwatson: (Can I be a powerpc folk instead?)
<slangasek> infinity: yes, you can be a 604e
<kirkland> can I get someone to accept that keystone upload?
<infinity> slangasek: Hrmph.  Then you get to be an ev4.
<slangasek> ow
<slangasek> kirkland: looking
 * micahg hugs cjwatson
<kirkland> slangasek: one-line bug fix, forwarded upstream;  grabbed two missing source/configuration files from upstream
<slangasek> kirkland: why does debian/copyright on this package claim that it's called "glance"?  Is the rest of the copyright information here correct?
<kirkland> slangasek: i'm guessing zul copied glance's packaging
<kirkland> slangasek: zul did the original packaging ... we're just fixing two bugs to get it functional
<slangasek> yes
<slangasek> I was just curious why these missing files were added as patches, wondering if we were upstream for it - seems not :)
<slangasek> and the copyright file is... not illegal.  So accepting.
<kirkland> slangasek: right
<kirkland> slangasek: thanks;  i'll open a bug on the copyright file now
<infinity> slangasek: "Not illegal" is a pretty high bar.
<slangasek> it's not illegal to list extra people as having copyright when they don't
<slangasek> for instance, it's not illegal to claim that the US Government holds copyright on glance even though it probably doesn't :)
<slangasek> (but upstream themselves make this claim, so anyway)
 * infinity is puzzled by oem-config-slideshow-ubuntu, which appears to be identical to ubiquity-slideshow-ubuntu, except for one stanza.
 * slangasek writes dh_slideshow
<kirkland> slangasek: fixed copyright issue in a branch and sent to the upstream packagers
<slangasek> infinity: can you remind me where it's defined what seeds get pulled onto the ISOs?
<slangasek> kirkland: ok, cheers :)
<infinity> slangasek: In what sense?  You mean, where people document it after the fact and pretend it's true, or the code that does the work?
<slangasek> infinity: the code that does the work :)
<infinity> slangasek: livecd-rootfs/live-buid/auto/config for anything livefs-based.
<infinity> slangasek: debian-cd/*mumble* for alternates and the tiny /pool/ on some livecds.
<slangasek> infinity: ah, I meant specifically the ISO part
<slangasek> yeah, I'm coming up empty on the *mumble*
<slangasek> oh, I see
<slangasek> I'm looking at an upstream debian-cd branch, wtf
<infinity> I'm looking for the mumble bit myself now. :P
<slangasek> there, *now* I see it
<cjwatson> I think you want cdimage/bin/list-seeds
<infinity> Hey look, it's the inheritance code again.
<slangasek> cjwatson: ah, got there, scratched my head, went looking again for something more declarative :)  ok, thanks
<infinity> That's 3 places that I know that lives.
 * infinity reminds himself to put that in germinate as a helper instead.
<micahg> can I get someone to copy from a PPA to archive please?
 * cjwatson almost finishes moving NBS generation entirely off cocoplum and stalls on an RT ticket
<micahg> cancel my AA request...
<infinity> micahg: Okay!
<slangasek> cjwatson: did you have thoughts on getting improved handling on bug #759545?  Is the ucf comparison being done at the wrong point?
<ubot4> Launchpad bug 759545 in grub2 (Ubuntu Oneiric) (and 3 other projects) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 3) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/759545
<slangasek> SpamapS: juju accepted
<SpamapS> slangasek: !! Thanks!
<SpamapS> all juju ever wanted was to be accepted.. to be one of the packages.
<slangasek> y/w :)
<slangasek> man, quit anthropomorphising the software, it really hates that
<SpamapS> :)
<infinity> slangasek: Any chance I can get a once-over on jasper-initramfs, flash-kernel, and livecd-rootfs?
<slangasek> looking
<infinity> slangasek: Before you ask, removing mkdosfs from jasper was cleaning up after code that was removed several versions ago.  I missed noting that in the changelog.
<slangasek> k
<slangasek> infinity: what's the jasper-initramfs change in partition type check?
<slangasek> oh, n/m
<slangasek> that's an addition, not a change
<slangasek> have confidence in my review
<infinity> Hey, you caught your mistake, that's close enough to perfection where I come from.
<slangasek> I thought you were from Canada
<slangasek> is that all the higher the standards are there?
<infinity> Well, if you caught your mistakes while covered in maple syrup, THAT would be perfection.
<slangasek> infinity: I don't understand the flash-kernel change, how is umount racy without -l?
<slangasek> is this a workaround for a buggy umount?  (hopefully not the util-linux one?)
<infinity> It's util-linux, it's not a umount bug (I don't think), but something's keep a file on that filesystem open for just a split second, long enough to make umount refuse to umount it.
<infinity> The fun part?
<infinity> Any debug code added to attempt to trace it adds just enough delay to make it go away.
<infinity> So, not really sure what's keeping something open.  But -l makes it happy, and can't really do any harm.
<infinity> The bug that I helpfully forgot to mention in the changelog is #779410
<slangasek> ah, so it's a race with the fs being in use, not a race with umount returning success before it's unmounted - got it
<infinity> Right.
<infinity> I ran flash-kernel in a loop of 1000 tries with -l and it always DTRT and cleans up properly, so I call it a success.
<infinity> A success, and possibly a dead SD card.
#ubuntu-release 2011-09-29
<infinity> And livecd-rootfs should be self-explanatory, since you reviewed the previous revision.
<slangasek> yep
<slangasek> all accepted
<infinity> Danke.
<infinity> Now, if I get my slideshow fix into ubiquity, I think I'm done touching ARM installers for the cycle.
<infinity> I think.
 * infinity starts going through the queue backlog.
<stgraber> infinity: can you reject atomix? I just noticed it doesn't have a build-dep on dh-autoreconf
<infinity> stgraber: Gone.
<ScottK> infinity: I'd appreciate it if you'd look at kdeutils.  It's a two line patch ...
<infinity> ScottK: Getting there...
<ScottK> Thanks.
<ScottK> If it helps any, we'll be able to taunt Riddell since he's upstream for the application it fixes.
 * infinity cheers for xubuntu-default-settings getting a greeter theme in just under the wire.
<stgraber> infinity: thanks, just uploaded a new one with the missing build-dep
<infinity> I suppose if the greeter itself had not been in flux for the last 3 months, that might have been easier. :P
<infinity> ScottK: Taunting Riddell is never a bad thing.
<infinity> ScottK: Sorry, no kdeutils for you.  Queue page times out, and I'm too lazy to log in to cocoplum. :P
 * infinity logs in..
<infinity> slangasek: Oh heh, I just re-read the f-k changelog and now understand your questions.  You should have rejected it based on my changelog being misleading/wrong. :P
<infinity> slangasek: Oh well.  The code's right, the changelog was autopilot.
<cjwatson> slangasek: my thoughts on 759545 amount to OMG LEAVE ALONE, unless somebody tells me I have to do something about it ...
<cjwatson> (playing with ever more config file handling is not my idea of fun)
<slangasek> ok :)
<slangasek> if you had some idea of what was going wrong, I might take a crack at it
<cjwatson> it's doing ucf and also substituting in values from debconf
<cjwatson> and almost certainly getting the ordering wrong one way or the other
<cjwatson> it's awful
<cjwatson> (and predates me, mostly)
<infinity> 759545> I'd be happy to take a stab at that post-release, but that sort of thing is best not touched right before a freeze.
<infinity> (I do enjoy those sorts of maintainer script / config file / crazy shit problems though)
<Daviey> cjwatson: I/We really, really hate grub for that.
<Daviey> And also the one where all cloud images provide that warning on every kernel SRU.
<Daviey> We release noted that bug for Natty, and i think it's ok to do the same for Oneiric.. But could we look to address it early in P?
<infinity> Daviey: Like i said, I'd be happy to wrangle it post-release.
<infinity> Daviey: And once I've hunted it down, even backport fixes.  Though I'm more concerned about the LTS.
<Daviey> infinity: is it worth it post-release?
<infinity> Daviey: It's worth it for P.
<Daviey> oh yes.
<infinity> Daviey: I mean "in 2.5 weeks".
<infinity> Daviey: Not in 6 months. :P
<Daviey> ahh, i see.
<infinity> I wouldn't even mind if someone assigned it to me, so you could remember to pester me (hint, hint)
<infinity> I suck at bug mail, so IRC annoyance will go a long way. :P
<Daviey> bug 814038 , i nacked - whilst i'd *really* like that in Oneiric.. and it seems to do the job, I'm not comfortable touching grub configs this late in the cycle.  If anyone wants to overal me, i'd be most pleased.
<ubot4> Launchpad bug 814038 in ipxe (Debian) (and 1 other project) "Please offer a grub-ipxe.deb package (affects: 1) (heat: 6)" [Unknown,New] https://launchpad.net/bugs/814038
<cjwatson> Daviey: if infinity wants to take care of it, my objections are fewer than if I have to :)
<Daviey> lol
<cjwatson> Daviey: but to be fair, an approach whereby cloud wasn't mangling grub's configuration files would be pretty nice too
<Daviey> cjwatson: I agree mangling is probbaly the cause for this :)
<Daviey> jhunt: !
 * ogra_ hugs cjwatson (re: rmadison) :)
<ScottK> Please don't accept qt4-x11 yet.
<cjwatson> pitti: FYI, I've moved cron.NBS to lp:ubuntu-archive-tools and made it run on lillypilly, including a bit of rearrangement of ubuntu-archive's crontab there (so cron.NBS now calls nbs-report itself)
<pitti> ah, that makes it easier, thanks
<pitti> ScottK: ack
<cjwatson> pitti: I'm going to be gradually moving reports off cocoplum now that we should have the necessary facilities to run them elsewhere
<cjwatson> since the LP/IS consensus is that ultimately we shouldn't need shell access to cocoplum
<cjwatson> (obviously there are a lot of things to do before that's possible)
<pitti> right; I'm trying myself to use +queue, sru-release, etc. as much as possible, but I still find LP timing out ridiculously often
<cjwatson> yeah, I know it's not ideal, we need to get those fixed before we can move off
<cjwatson> we need an API for +queue
<pitti> that seems to be the worst problem for that
<cjwatson> (I filed a bug for that, I think)
<pitti> stuff like sync blacklist is already being handled, and it shouldn't be hard to rewrite lp-remove-package.py in lplib
<cjwatson> I filed a bug for that too; the API is not quite right at the moment
<cjwatson> or possibly I'm thinking of https://bugs.launchpad.net/launchpad/+bug/853831
<ubot4> Launchpad bug 853831 in launchpad "Export SPPH.changeOverride and BPPH.changeOverride (affects: 1) (heat: 6)" [High,Triaged]
<Daviey> Is anyone a ruby fan on the release team?
<mvo> slangasek: when you get the chance, I would appreciate your input in bug #779382 - I have a working port that should work pretty well, but its still rather late in the cycle and derivates are affected too
<ubot4> Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 9 other projects) "update-notifier not visible under unity (affects: 14) (dups: 2) (heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/779382
<Daviey> I'd like to determine if someone is better placed on solving a ruby/rails issue.. or at least someone that is happy to help sort out the direction.  Currently it's a mess.
<Daviey> aka HELP
<Daviey> (!)
<Daviey> doko: That seems to be part of the fix.. I'd like to have rejected the sync when i realised it was worse than it was. Not having that foo, and nobody listening to my cries yesterday, someone accepted it.
<Daviey> But.. it was broken before that.
<Daviey> bug 861524
<ubot4> Launchpad bug 861524 in rails (Ubuntu Oneiric) (and 1 other project) "[oneiric] rails is not installable (affects: 4) (heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/861524
<Daviey> There was a partial transition done in September, it seems to me that we either need to finish it, try and cherry pick enough to get it working, or versionmanagle to bring it all back to the base version.
<Daviey> All options are bad.
<Laney> looks like syncs 2.3.14 were done?
<Laney> imagine grammatical English there.
<Daviey> Laney: the deps
<Daviey> rails (2.3.14.1) was sync'd in September
<Daviey> it has hardcoded < deps.
<Daviey> m_3 has taken a stab with the depends, https://code.launchpad.net/~mark-mims - but I'm not comfortable with the impact here.
<Laney> actionmailer still needs doing, but once activerecord builds (in progress now), actionpack will build and then ruby-rails-1.3 will
<Laney> looks like doko just did some syncs
<tumbleweed> anyone noticed the big pile of input method related sync requests in the sponsor queue? I know nothing about that stuff...
<Daviey> Laney: okay, so between you and doko - you have it in hand?
<Laney> I just eyed it up, haven't done anything about it
<doko> looks so.
<Laney> but it looks like syncing the stack would fix things, and that doko is doing that
<doko> Laney, will your darcs upload in unstable help armel?
<Laney> no
<Daviey> doko: So you are finishing the transition to *.14?
<Laney> it didn't even fix the ftbfs in sid
<doko> Laney, https://buildd.debian.org/status/package.php?p=darcs ?
<doko> Daviey, yes
<Laney>  right
<Laney> I don't think I changed anything that would fix arm
<Laney> that said, a fix wouldn't be harmful (but would need binNEWing as I added library packages)
<Laney> fix/sync
<Daviey> Laney: Yeah, I was thinking that finishing syncing would be A fix - but i wasn't comfortable with understanding the impact, as the stack isn't just limited to rails - is it?
<Daviey> doko: ruby-activerecord-2.3 (2.3.14-1) is only used with rails?
<doko> at least with ruby-rails-2.13
<pitti> didrocks, ScottK: will you ping when/if we should review qt4-x11?
<didrocks> pitti: hum? should be fine in the unapproved queue, isn't it?
<pitti> 14:57:20     ScottK | Please don't accept qt4-x11 yet.
<didrocks> pitti: the patch cames from a nokia developer, adapted to 4.7.4
<didrocks> ScottK: ?
<didrocks> and it's fix released upstream
<didrocks> as the upstream bug, in the DEP-3 format in the patch tells
<smoser> skaet, just curious, is there a reason that 'ReleaseCandidate' is not in the right column at https://wiki.ubuntu.com/OneiricReleaseSchedule
<smoser> i was confused, and basically thinking there was no RC
<smoser> (i'm easily confused, though)
<skaet> smoser,  ReleaseCandidate is going to happen like it did in Natty,  not as a formal deliverable which is what the last column is used for.   We'll have a formal release candidate for the LTS :)
<smoser> ok.
<smoser> thanks, skaet
<skaet> np
<ScottK> didrocks: Thanks.
<ScottK> I was gone longer than i expected.
<ScottK> didrocks: Accepted.
<didrocks> ScottK: thanks!
<ScottK> I also wanted to make sure the last upload got published on i386 first too.
<ScottK> pitti: re trying to use +queue and timeouts: Welcome to my world.
<ScottK> :-)
<NCommander> can someone kick partman-uboot in the queue?
<skaet> NCommander, its been reviewed?
<NCommander> skaet: a little testing, but not a lot. I thought we weren't in final freeze yet
<skaet> NCommander, fixes are getting reviewed as they go in right now.
<NCommander> skaet: k, let me get it re-reviewed. The scope of the fix is small (affects error messages during partitioning on netboot omap3/4)
<skaet> NCommander, thanks!
<NCommander> skaet: will ping once its done (probably not until after final freeze, as we're in final crunch time now :-/)
<skaet> NCommander, ack.
<cjwatson> +       db_set partman-uboot/boot_not_on_mmc
<cjwatson> NCommander: what's the point of that line?  partman-uboot/boot_not_on_mmc is a boolean, so that line sets it to an out-of-spec value
<cjwatson> (i.e. the empty string - the only in-spec values for booleans are "true" and "false")
<cjwatson> also I'd recommend that boolean templates have a Default field in the templates file of either true or false
<cjwatson> +                           [$id/formatted -nt $id/filesystem ]); then
<cjwatson> bad syntax, missing space after [
<cjwatson> I would prefer commit.d/format_dove_uboot and commit.d/format_omap_uboot to be merged into one script
<cjwatson> in fact merged *back* into one script from the looks of things.  it was better that way, less duplicated code
<cjwatson> debian/files shouldn't be in the source package
<cjwatson> nor should all the */DEBIAN/* cruft
<cjwatson> I'm marginally confused by why this is in both active_partition and choose_method but that'd probably be clear if I looked at it
<cjwatson> confusing indentation in init.d/uboot_omap
<cjwatson> NCommander: ok, that's my initial review; sorry, but I'm going to have to reject this at least for the unclean source package, the syntax error, and the out-of-spec db_set; can you please fix those up?
<doko> please could somebody review icedtea-web (two upstream patches, fixed permissions), openjdk-6 (pulseaudio, permissions), and the just uploaded openjdk-7?
<stgraber> Just pushed edubuntu-live, ltsp and arkose to update translations and do some last minute bugfix for Edubuntu. Would appreciate it if these could make it to our next daily (if they get acked within the next 4 hours we should be good). thanks!
<pitti> doko: yep, currently reviewing
<pitti> NCommander: do you mind reviewing u-boot-linaro? it's two metric tons of changes which I can't judge
<tjaalton> Laney: hey, I*ve posted the diff to sssd's debian/ dir to the bug
<pitti> keeping openjdk-7, no debdiff yet; and jockey, as I uploaded that
<pitti> and with that, good night!
<stgraber> wow, that was fast! thanks!
<doko> $ sync-source.py -b doko ruby-actionpack-2.3
<doko> 2011-09-29 16:56:58 INFO    Creating lockfile: /var/lock/launchpad-sync-source.lock
<doko> Getting binaries for oneiric...
<doko> 2011-09-29 16:57:15 ERROR   Unhandled exception
<doko>  -> http://launchpadlibrarian.net/81447917/bTJiQXFcef5DKR8XewCVYAGXfTW.txt (Values instance has no attribute 'moreverbose')
<doko> cjwatson, pitti: have to run ... could you have a look at these? needed for ruby-rails
<doko> Daviey, ^^^
<doko> ahh wait, already synced :-/
<Daviey> doko: Is the rails mess resolved?
<ScottK> Daviey: Not until it's rewritten from scratch?
<skaet> ScottL, https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-meta/+bug/806672,  looks like its resolved now based on the comments,  can you confirm?
<ubot4> Launchpad bug 806672 in ubuntustudio-meta (Ubuntu Oneiric) (and 1 other project) "UbuntuStudio Oneiric Alpha2 fails to install - unmet dependencies (affects: 2) (heat: 13)" [Critical,Triaged]
<doko> Daviey, please give back ruby-rails-2.3 in about 90min
<Laney> tjaalton: ta, will look hopefully tonight but if not then tommorrow (or someone else can)
<tjaalton> Laney: ok. does it need some special treatment once the final freeze is on?
<Laney> it's universe unseeded (isn't it?), so not just yet
<tjaalton> Laney: yes, indeed
<tjaalton> Laney: fwiw, stephen gallagher is upstream
<tjaalton> unless it wasn't obvious already :)
<Laney> yeah, got that
<Daviey> doko: k
<didrocks> skaet: ScottK: would be nice to have latest unity release in tomorrow's image if you have time
<didrocks> Daviey: as well ^
 * didrocks crosses finger it's the finale release :)
<infinity> didrocks: That's.... A lot of bugs fixed.
<didrocks> infinity: yeah, as always! :-)
<Daviey> didrocks: I'm sorry, it's the first time i've looked at unity code - and it's far too large for me to feel comfortable ack'ing it.
<infinity> Daviey: I'm looking at it.
<didrocks> no worry Daviey ;)
<Daviey> infinity: rocking
<didrocks> thanks infinity
<infinity> didrocks: Have you considered actual patches instead of this massive debian-changes blob?
<infinity> Err, and someone just accepted it for you while I was reviewing it. :P
<infinity> (who was that?)
<didrocks> infinity: it's how merge-upstream works :)
<infinity> For some value of "works"...
<didrocks> infinity: still not perfect for this workflow I know
<didrocks> infinity: basically, the packaging branch is derived from trunk
<didrocks> infinity: then, you bzr merge-upstream ../tarball ../trunk --version <version>
<didrocks> infinity: it takes what's in trunk, add all delta (if any) from the tarball
<didrocks> infinity: then, you can easily cherry-pick with bzr merge ../trunk -r rev
<didrocks> really handy, as you know that next release will overwrite the change
<didrocks> the issue is that it doesn't play well with source 3 :/
<didrocks> reviewing the branch itself is way easier
 * infinity really wants an audit trail on the queue...
<Daviey> infinity: Fancy reviewing a ~ubuntu-cdimage merge proposal? :)
<infinity> Daviey: The boot menu thing?
<Daviey> infinity: yeah
<infinity> Daviey: I've been intentionally leaving that to Colin.
<Daviey> gah.. I was aswell, but i imagined he was AWOL right now.
<infinity> Is there a reason that needs to be in cdimage instead of wherever that sort of thing normally lives?
<Daviey> infinity: It replaces the code that used to be "Install UEC".
<Daviey> As in, there used to be something there
<slangasek> infinity: this is why I really want bzr merges to /be/ the queue... :)
<infinity> slangasek: Or, I dunno.  Auditing on who presses buttons?
<infinity> slangasek: That's not rocket surgery.
<slangasek> infinity: oh, that part
<slangasek> yeah
<slangasek> sorry, I thought you meant "this diff is augh and not auditable"
<infinity> Oh, his diff is icky, but I've seen icky VCS merges too, whatever.
<infinity> No, I was complaining that I've seen a ton of (potentially controversial) accepts over the last couple of hours, and no one's actually been talking about them. :P
<infinity> Well, maybe not a ton.  But a few.
<dobey> hey lovely release team
<infinity> dobey: Whatever it is, we don't want any.
<nigelb> haha
<dobey> how much trouble will it be to get a fix for a nasty webkit crasher into oneiric today? :)
<infinity> dobey: No trouble at all, if it's an isolated and sane fix.
<dobey> it is
<ScottK> No trouble at all as long as there's no auditing of who pushed the accept button ....
<dobey> i am preparing a branch with the cherrypicked patch, right now
<infinity> Or what Scott said.
<infinity> Grr.
<slangasek> mvo: commented on bug #779382
<ubot4> Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 9 other projects) "update-notifier not visible under unity (affects: 14) (dups: 2) (heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/779382
<slangasek> mvo: really, it depends on the desktop team here; I'll do what I can to help land it cleanly if they say it has to go in before release, but seb128 seems to agree with you
<mvo> thanks slangasek
<infinity> mvo: Not sure where you were looking, but lubuntu and xubuntu both ship libindicator in -desktop.
<infinity> Oh, libappindicator...
<infinity> Wait, no, same argument. :P
<infinity> mvo: libappindicator and libindicator are both there for [x|l]buntu-desktop.
<infinity> Now, whether I had an indicator panel on a default Xubuntu install, or if I added it myself later, I don't recall...
<infinity> But the packages were there. :P
<charlie-tca> I show indicator plugin in the panel by default in Xubuntu
<infinity> charlie-tca: Thanks, I can never remember what was default and not, after how much I've hacked and slashed at my panels.
<mvo> infinity, charlie-tcao: oh, cool!
<mvo> that makes it all a lot easier actually
<charlie-tca> Yeah, only way I know is it is a fresh install I did to test today
<infinity> Hahaha.
<dobey> infinity: https://code.launchpad.net/~dobey/ubuntu/oneiric/webkit/scroll-crasher-fix/+merge/77587 <- nice small patch :)
<mvo> would you mind to put that info into the bug?
<infinity> mvo: Done.
<ScottK> slangasek: If the whitelist is in place, why bother with an SRU.  There's no longer an SRU qualifying issue.
<infinity> dobey: Very tiny.  Locally-tested to DTRT, I assume?
<infinity> dobey: (And upload away, if the answer is "yes")
<dobey> infinity: yes, it fixes the crash; and i don't have upload perms for webkit
<infinity> dobey: Oh.  I'll sponsor it in a bit, then. :)
<dobey> infinity: ok, thanks
<ScottK> skaet: It'd be nice if you could fill in the comment field about what's changed on your manifest edits it's be nice.  The diffs for that page are incredibly hard to read.
<infinity> ScottK: I'm sure I failed to comment my edits too.  Apologies.
<ScottK> slangasek too I think, there have been a pile of them.
<ScottK> And they make my eyes hurt.
<infinity> Stop subscribing to it; problem solved? :)
<skaet> ScottK,  switched two lines and cleaned up the seed references (ditto was referring to line above, and it wasn't accurate where it was.)
<ScottK> oops
<ScottK> Yep.  I got that, it just took some study.
<slangasek> ScottK: hmm, probably true
<tjaalton> hey, I've uploaded a new xserver-xorg-input-synaptics, which fixes a merge regression where the quirks were not getting installed. tested by cnd that it works
<slangasek> infinity: are you on ia32-libs?
<infinity> In a call, but it's on my plate, unless you're bored. :P
<slangasek> I have enough excitement in my life without ia32-libs
<slangasek> thanks though :)
<highvoltage> heh
<Daviey> I have reviewed orchestra and dovecot-metadata-plugin (as best as possible), can they be accepted pleased
<infinity> slangasek: ia32-libs seems good to me, except for a bug that will make it break on ia64, which we don't build anymore.  Worth pushing it back to fix and arch we don't use? :P
<Daviey> openjdk7 - diff from 7~b147-2.0~pre5-1 to 7~b147-2.0~pre6-1ubuntu1 (86.4 MiB) ... :/
 * infinity closes his eyes and accepts ia32-libs.
<infinity> Daviey: openjdk7 is unseeded and unsupported, just grit your teeth, see if debian/changelog looks sane, and let 'er rip?
<infinity> Ugh.  This habit of doing major version bumps on Canonical-originating packages within hours/days of freeze needs to be rethought.
<infinity> It can't be that hard to cut "5.0" at feature freeze, and then maybe ship with 5.0.7 (yay bugfixes) by release. :P
<Daviey> infinity: What packages are you referencing directly?
<infinity> *indicator*, software-center... Possibly others.  But those are the ones I've noticed this week.
<infinity> Not that 2.95->3.0 (for instance) was actually a large diff.  That's not my complaint.  But in some projects, even just bumping a major revision number can accidentally cause a problem.  I see the argument for shipping a shiny 3.0.0, but.. Who cares?
<infinity> And if the versions mean anything (*cough* stability), 3.0.0 should be landing at feature freeze anyway, cause everything after that is microrelease bugfixes, right? :)
<Daviey> infinity: Major version numbers could just be turning the volume up to 11.
<Daviey> I'm sure if you ask nicely, they'll bump a minor version instead next time :)
<infinity> Maybe.
<infinity> But it kind of looks like this is a team policy thing. :P
<Daviey> Although, it does feel that crack is landing significantly later than in the last 2 cycles.
<infinity> Yeah.  Well.  I'm back now.  And I plan to be draconian about freezes and the queue for the LTS.
<infinity> If I can get the other RMs to back me, we're set. ;)
<infinity> (I'm sure vorlon and cjwatson will be on board with that plan)
<Daviey> infinity: Server has committed to not taking on anything ambitious next cycle.  LTS probably being more importiant to them, than Desktop.
<Daviey> Which should make it easier to have crack land early.
<Daviey> So certianly my suport there :)
<infinity> It's pretty important to desktop too.  Support cycle is still twice as long.
<infinity> And while we may not be the corporate desktop of choice, there ARE some large installations out there.
<infinity> And you can bet they don't run the latest crack every 6 months. :)
<Daviey> infinity: pah, 3 years vs 5 years :)
<infinity> I know. :)
<infinity> And 5 still isn't long enough.
<infinity> But it's much better than 18 months, so I won't complain.
<Daviey> infinity: don't tell anyone, but i still have some dapper servers.
<infinity> sladen: Re: ubuntu-mono upload: Eww.
<infinity> Daviey: I worked hard on that release, I don't mind.
<infinity> Daviey: In dapper, the "server team" was, more or less, me.
<infinity> Daviey: So.. You're welcome. :)
<Daviey> heh
<Daviey> sladen: wow, have you tried building in a launchpad chroot?
<Daviey> I'm sure shipping binaries due to a buildd issue shoudl decrement your karma
<infinity> sladen: If you can build locally but not on a buildd, it's got to be a missing build-dep, or a whacky local config or something.
<infinity> sladen: Surely, there's a better way. :P
<infinity> Daviey: I want karma every time I press the accept button.  And twice as much for reject.
<infinity> Now, who did I promise I'd sponsor an upload for?
 * infinity alt-tabs through the mess on his desktop.
<infinity> Right.  dobey, webkit.
<jdstrand> skaet: fyi, bug 851986 needs to be SRU
<ubot4> Launchpad bug 851986 in firefox (Ubuntu Oneiric) (and 7 other projects) "use of Ux in ubuntu-* abstractions and profiles is too lenient and should be improved (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/851986
<jdstrand> skaet: I updated the milestone accordingly
<skaet> jdstrand,  thanks.
* skaet changed the topic of #ubuntu-release to: Final Freeze in effect. | http://pad.ubuntu.com/ubuntu-release | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<infinity> skaet: I'm squeezing in one more upload that I reviewed for dobey several hours ago and am merging now. :P
<infinity> (if bzr will ever finish branching...)
<skaet> infinity,  ack.
<skaet> could someone with op perms in ubuntu-devel, change the topic to reflect the fact its now past 2100 UTC, so we're final freeze now?
<infinity> skaet: I already did.
<skaet> infinity,  Thanks!
 * sladen looks around at the ceiling
<Laney> are you sending out an announcement?
<jbicha> hi, just curious if anyone was doing anything with bug 821876 or if that will wait for P?
<ubot4> Launchpad bug 821876 in ubuntu-font-family-sources (Ubuntu) "FFe: New upstream version Ubuntu Font Family 0.72 (Ubuntu Mono hinted and Ubuntu Condensed hinted) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/821876
<Laney> seems late.
<jbicha> yeah, it's not my bug, but I figure the Release Team will need to do a Yes/No for it...now that OMG Ubuntu announced that it's been released
 * sladen marks it as a dup of bug #854264
<ubot4> Launchpad bug 854264 in ubuntu-font-family-sources (Ubuntu) "UVFe & FFe: New upstream version of Ubuntu Font Family 0.80 (affects: 2) (dups: 1) (heat: 22)" [Wishlist,Confirmed] https://launchpad.net/bugs/854264
<jbicha> sladen: hi, thanks
<sladen> jbicha: upstream have released 0.80.  Whether it makes it into the distro (it's been uploaded) depends on the Ubuntu Release team.  I suggested writing persuasive messages to the release team on the bug report
<infinity> :P
<infinity> sladen: No comments on the ubuntu-mono hacks?
<infinity> sladen: /lastlog sladen :)
<sladen> infinity: oh, this is just a mere upload of some data files.  No chance that if it gets accepted there's be a theme update to switch over to using them.  no, no, ho ho
<infinity> sladen: Hrm?  No, I assumed that.  But thanks for the sanity check.
<infinity> sladen: I mean comments on why you need to include pngs in your source. :P
<sladen> infinity: oh, the ubuntu-mono (images, not font, sorry, name overloading)
<sladen> infinity: it was a bit crunch point timewise.  I hope to delete the PNG dump-over line when I figure out the exact issue
<sladen> infinity: it's reproducable in a pbuilder-buildd environment, ... yes, it is likely some undeclared imagemagick randomness
<infinity> sladen: Mmkay.  I'll let it slide, but if you find the issue, I wouldn't actually mind it being fixed properly in the next day or two.
<infinity> (hint, hint)
 * sladen nods
 * infinity goes crosseyed reviewing checkbox.
<Daviey> infinity: I think they went for a record d/changelog size.
<infinity> Daviey: The changelog was alright, it was some of the code that made me quiver with fear.  You know, stuff just completely inverting logic to make me have to find context, that sort of thing.
<infinity> Well, Final Freeze has come and gone, and our installer still doesn't build.
<infinity> I call this a success.
<infinity> I wonder if Colin's adding me to ~ubuntu-installer was a subtle "go fix ubiquity" hint.
 * skaet looks at the list of ubiquity bugs, and figures its was a hint. 
<skaet> Laney,  note sent.
<slangasek> why does this plymouth bug report ONLY affect people who are not me?
<infinity> slangasek: Which one?
<slangasek> infinity: the many-tentacled memory corruption one
<sladen> Daviey: launchpad chroot.  tell me more
<slangasek> which I have never seen in person
<infinity> slangasek: As in video corruption?
<sladen> Daviey: what magic do I need to pass to pbuilder/etc to make that work?  And how does it help?
<infinity> slangasek: If so, my laptop very recently developed that bug.
<infinity> sladen: https://api.launchpad.net/devel/ubuntu/oneiric/amd64
<slangasek> infinity: no, memory corruption; plymouth's list code is going off the deep end
<infinity> sladen: (For instance)
<sladen> Daviey: re: server.  I'm gonna replace yo console fonts with early crack
<infinity> sladen: That tarball is the exact chroot used on the buildds.
<mdeslaur> slangasek: you clearly don't own enough hardware :)
<slangasek> infinity: resulting in segfaults and apport bugs and augh
<slangasek> mdeslaur: can *you* reproduce it?
<slangasek> I already have a box here with an nvidia chip, just to try to catch it
<infinity> slangasek: Oh.  Not sure I know that one.  But I kinda ignore plymouth anyway, assume my machine's just going to do ugly things on boot/shutdown, and fail to care. :/
<mdeslaur> slangasek: remind me the bug #? I'll check
<slangasek> infinity: so, we are actually committed to making plymouth not-ugly, and you might stand a halfway decent chance of filing an actional bug report... if you're seeing ugliness, please report it :)
<slangasek> mdeslaur:  bug #849414, or bug #553745, or bug #745744, or bug #542191, or any of the other places plymouth is segfaulting against its will
<ubot4> Launchpad bug 849414 in plymouth (Ubuntu Oneiric) (and 1 other project) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() (affects: 118) (dups: 36) (heat: 666)" [High,Incomplete] https://launchpad.net/bugs/849414
<ubot4> Launchpad bug 553745 in plymouth (Ubuntu Oneiric) (and 5 other projects) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() (affects: 708) (dups: 77) (heat: 3100)" [High,Incomplete] https://launchpad.net/bugs/553745
<ubot4> Launchpad bug 745744 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_list_remove_node() (affects: 82) (dups: 10) (heat: 393)" [High,Confirmed] https://launchpad.net/bugs/745744
<ubot4> Launchpad bug 542191 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_list_remove_all_nodes() (affects: 10) (heat: 40)" [Medium,Confirmed] https://launchpad.net/bugs/542191
<infinity> slangasek: plymouth's been differently broken for me on different hardware for every release since we switched.  I guess I gave up somewhere.
<mdeslaur> ubot4: whoa boy
<ubot4> Factoid 'whoa boy' not found
<infinity> slangasek: I'll start caring again.
<infinity> slangasek: (Speaking of ugly, do we have any intention of making the shutdown transition smooth?  It hasn't been ever since the switch from *dm calling splash_down to the udev rule that does it "when the dms exit")
<slangasek> infinity: er, I fixed that last weekend?
<infinity> I think that's around when I gave up. :P
<infinity> slangasek: My laptop disagrees.  How is it fixed?
<slangasek> oh sorry, by "smooth" do you mean "no modeswitch"?
<infinity> And by udev, I mean upstart.  My brain's not all here.  ubiquity has my Us confused.
<Daviey> sladen: You'll have to update the sources.list and hack /CurrentlyBuilding
<slangasek> I don't think we ever had a flicker-free transition from gdm to splash on shutdown
<slangasek> h]
<Daviey> infinity: Unless you have finished your wrapper for CurrentlyBuilding + sbuild?
<infinity> slangasek: I mean "no jarring me to a text console which may or may not have text, depending on other packages installed, before starting plymouth a second or five later".
<infinity> Daviey: Nein.
<slangasek> now, this cycle we had a major smoothness regression on shutdown, and that one got fixed
<infinity> slangasek: We never avoided a mode switch, but I know we avoided seeing a console, I wrote the code that did it. ;)
<Daviey> sladen: Wait, are you suggesting your team actually cares enough about server to bother replacing stuff?
<slangasek> infinity: yeah, we still drop to text on shutdown; there really shouldn't be any text on vt7 though unless something else is running amok
<infinity> slangasek: But that all got torn out in favor of upstart triggers.
<slangasek> oh?  I don't think that code was in effect at the time we switched to plymouth
<slangasek> so I think it bitrotted before that
<infinity> slangasek: In a default install, vt7 won't have text, on a messier one, there can be all sorts of stuff there (always is on mine).
<sladen> Daviey: oh yes.  We don't you a juju logo right now(tm)
<sladen> Daviey: oh yes.  We're doing you a juju logo right now(tm)
<slangasek> infinity: there shouldn't *ever* be text on vt7 (unless maybe you boot without 'quiet'), and if you're getting some, let's fix whatever's doing it :)
<infinity> slangasek: I've had output from any number of init scripts there (and sometimes errors/warnings from same).
<NCommander> cjwatson: will fix, but I perfer keeping the commit scripts between dove and omap separate
<infinity> slangasek: And while I think it's a noble goal to fix every daemon in main/universe to shut up, it's easier (surely) to not show the vt. :P
<slangasek> infinity: no, the intent is to fix it so the init scripts don't have vt7 as their stdout at all
<slangasek> but yeah, I can't speak to the current status of this
<infinity> slangasek: As in, make upstart shove it somewhere else?
<slangasek> yep
<infinity> slangasek: I can live with that.
<slangasek> and, y'know, log it
<infinity> Crazy talk.
<slangasek> (we have /var/log/boot.log working again)
<infinity> Right then.  ubiquity build failure reproduced.  Now to find line 27765 of templates...
<slangasek> it's right after line 27764.3
<infinity> Only according to plymouth.
<infinity> That looks suspiciously like a missing '.' in that template.
<slangasek> mdeslaur: so you're not seeing these plymouth crashes, then? :)
<mdeslaur> slangasek: hold your horses, I'm dist-upgrading some laptops
<slangasek> mdeslaur: ah, heh
<slangasek> it has been reported more or less continuously since maverick, though each rebuild of plymouth (or of some dependency of plymouth) causes the crash to show up in a slightly different place
<mdeslaur> slangasek: I did find a plymouth crash from 10 days ago in /var/crash
<slangasek> mdeslaur: hmm
<mdeslaur> ah, crud...today's updates broke unity on my aspire one
#ubuntu-release 2011-09-30
<infinity> slangasek: Quickie review and accept of my 6-character grub-installer change?
<mdeslaur> fyi: today's unity regression: bug 862743
<ubot4> Launchpad bug 862743 in unity (Ubuntu) "Desktop drawn with offset (affects: 22) (dups: 6) (heat: 144)" [Undecided,Confirmed] https://launchpad.net/bugs/862743
<slangasek> mdeslaur: by 'today' do you actually mean 'today'?  I don't see a new unity today
<slangasek> infinity: looking
<infinity> mdeslaur: That's not using positive language.  Unity doesn't regress, it just improves in reverse.
<mdeslaur> slangasek: unity (4.20.0-0ubuntu1), 5 hrs ago
<slangasek> hmm
<jbicha> lol
<mdeslaur> infinity: sorry...unity's present incremental improvement
<slangasek> infinity: you're saying that unity is wizard, but the wizard is Merlin?
<jbicha> but look at all those bugs fixed today in Compiz/Unity!
<slangasek> infinity: points off for misspelled changelog
<mdeslaur> jbicha: there you go, 20 fixed, and only 1 introduced, we're still ahead!
<infinity> slangasek: Wait, really?  Am I that tired?
<infinity> slangasek: Reject, I'll fix. :P
<infinity> SUPRIOUS!
<infinity> Wow.
<infinity> slangasek: Reuploaded. :P
<slangasek> :)
<slangasek> infinity: accepted
<slangasek> infinity: does this explain the ubiquity FTBFS?  I wasn't clear on how ubiquity FTBFS on 2 of 4 archs
<slangasek> oh right, because grub-installer is only used on two of those archs
<slangasek> hmm
<mdeslaur> slangasek: can't reproduce the plymouth issue, sorry
<slangasek> mdeslaur: lucky you, given that my followup was going to be to ask you to run plymouthd under valgrind :)
<mdeslaur> slangasek: heh, sounds like fun :P
<infinity> slangasek: Yeah, once ubiquity is refreshed with the new grub-installer, it will build happily.
<infinity> (which is my next move, once it publishes)
<infinity> Oh, that mksh upload reminds me...
<infinity> slangasek: I needed to review a dietlibc sync request today.  You cool with that going in if it looks alright to me?
<infinity> (And then we can reject mksh)
<slangasek> infinity: yes, no objections for dietlibc
<infinity> slangasek: Alright, I'll sync it after I resurrect a machine and do some local testing.
 * infinity rejects mksh for now.
<infinity> slangasek: Well, nevermind the dietlibc bump.  GCC ICEs while building it.
<infinity> slangasek: \o/
<ScottK> infinity: re: "Ugh.  This habit of doing major version bumps on Canonical-originating packages ..." see my response to Allison's call for UDS inputs on that very topic.  Since you'll (I imagine) be there, you can push it forward.
<ScottK> sladen: FYI, UVFe is a term it's been a few years since we used.
<ScottK> infinity: Also, thanks re Dapper server.  That was the first one I ran.
<infinity> slangasek: ubiquity inc.
<infinity> ScottK: Can I get a review/accepct of ubiquity?  I'd like to build some images some day. ;)
<ScottK> Depends on how complicate it is.
<infinity> Not very.
<infinity> You can skip everything under d-i, since it's just source package copies.
<infinity> The ubiquity changes are pretty small.
<ScottK> Done.
<ScottK> Sorry, had $WORK to finish first.
<ScottK> Or not.  (Error ID: OOPS-2099BB11)
<ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=2099BB11
<ScottK> Fourth try's the charm.  It's in.
<infinity> Danke.
<infinity> That oops has a pleasantly repetitive serial.
<ScottK> It does.
<ScottK> I hadn't noticed, I guess that makes you more autistic than me.
<ScottK> ;-0
<infinity> I didn't realise it was a competition.
<ScottK> Laney: Did you intend your changing the status of Bug 854264 to be an FFe approval?  It's nice to put a word or two in there so others know why you changed the status.
<ubot4> Launchpad bug 854264 in ubuntu-font-family-sources (Ubuntu) "UVFe & FFe: New upstream version of Ubuntu Font Family 0.80 (affects: 2) (dups: 1) (heat: 22)" [Wishlist,Fix released] https://launchpad.net/bugs/854264
<pitti> I suppose we'll need another armel abi bump in d-i for http://people.canonical.com/~ubuntu-archive/nbs.html?
 * pitti looks at fixing med-imaging-dev
<pitti> at this point I'm inclined to just remove eclipse binaries on armel and powerpc
<pitti> (FTBFS there)
<ScottK> Sounds reasonable.
<pitti> +queue has teh debian-med diff now
<pitti> I'm not sure why blends-dev shuffled the recommends: line on rebuild
<pitti> but I think it just removed packages which got removed
<ScottK> Looking before I go crash.
<pitti> at least it did that for the other blends packages I touched recently
<ScottK> It's late.  I've very tired.  I'm willing to believe you.
<ScottK> (I don't think anyone in Ubuntu uses the blends packages anyway ....)
<ScottK> Good night.
<pitti> sleep well!
<ScottK> Thanks.  4:59 until I have to be up again.
<infinity> pitti: d-i needs a rebuild anyway.  But yeah, need to bump omap4 kernels.
<infinity> pitti: Probably safe to do the d-i bump later in your day, if you want.  I was just waiting on the archive to settle.
<pitti> infinity: yes, not particularly urgent; I just looked at NBS to see what remains
<pitti> infinity: FYI, bug 862743 is a real sucker
<ubot4> Launchpad bug 862743 in unity (Ubuntu Oneiric) (and 2 other projects) "Desktop drawn with offset (affects: 51) (dups: 15) (heat: 314)" [Critical,Fix committed] https://launchpad.net/bugs/862743
<pitti> building a test package now, will upload in a bit
<infinity> Yeah, Unity's special.
<pitti> infinity: dpm was asking for getting the libgrip HTML documentation installed; I fixed the source to install it into libgrip-dev, does that sound acceptable to upload at this point?
<pitti> infinity: (for http://developer.ubuntu.com)
<infinity> I'm not really familiar with how developer.ubuntu.com fits into the grand scheme of things...
<infinity> But what's wrong with -doc packages? :P
<pitti> infinity: nothing in particular, but (1) binNEW, and (2) small package
<pitti> there's loads of packages which just install their docs into -dev to avoid excessive split-o-mania
<infinity> Yeah.  Fails if you later want to multiarch, though, doesn't it?
<infinity> But fair enough.  Docs ahoy.
<pitti> infinity: oh, how so?
<pitti> it's static file
<pitti> s
<infinity> No per-arch generation at all?
<infinity> Might be alright, then.
<infinity> Still a bit icky. ;)
<infinity> But whatever.
<pitti> infinity: nope, docs are generated by make dist
<pitti> that's the common case these days with gtk-doc
<pitti> (same for glib, gtk, and all the other libs)
<pitti> much faster, and there's no real reason to regenerate docs each time
<pitti> mind all those wasted entropy!
<infinity> Yeah, I remember this from doing telepathy release engineering.
<pitti> s/those/this/ (was going to write "electrons")
<infinity> Was a constant source of annoyance, actually. :P
<pitti> unity and libgrip uploaded; whee!
<pitti> a non-broken desktop, and already TWO WEEKS before release!
<infinity> It'll break still.
<infinity> See the sponsorship request in -devel. ;)
<pitti> yes, we are good at that
<pitti> infinity: sponsoring libcanberra, too, that looks good
<infinity> pitti: Need some reviews?
<pitti> infinity: if you are in the mood, that'd be nice
<infinity> I'm just fixing my local mirrors, happy to review when the diffs rolls in.
<infinity> s/rolls/roll/
<pitti> infinity: argh, forgot bug ref in libgrip; want me to reupload?
<infinity> Well, you just rejected it, so sure. :P
<pitti> er, what?
<infinity> Unless that was someone ninja accepting?
<infinity> Man, I wish this thing had an audit trail.
<pitti> I accepted David's libcanberra
<infinity> Oh.
<infinity> Grip, canberra.
<infinity> THEY BOTH START WITH LIB.
<pitti> yeah, hard to distinguish
<infinity> I stop reading after the first 3 characters.
 * pitti uploads libcranberry
<infinity> As for the bug ref, I don't care if you close it manually.
<pitti> ack, will do that then
<infinity> Argh.  The unity people really need to stop using this silly tool. :(
<infinity> "Hey look, we moved all our packaging from one debian-foo.patch blob to another, happy diffing."
<pitti> eww, yes; the actual diff is just a two-liner
<pitti> infinity: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1677
<pitti> (slightly easier to read)
<infinity> Yeah, I've learned to read these messes.
<infinity> And thanks to their magic packaging crazy, I prefer to review the actual source package instead of a branch.
<infinity> Cause I don't trust it.
<pitti> 3.0 (quilt) just doesn't play well with bzr maintained pacakges
<pitti> for mine I just keep 1.0, it's so much better for upstream/packaging in bzr
 * pitti asks didrocks to do that
<infinity> 3.0 (quilt) works fine, you just have to actually keep patches in bzr.
<pitti> yes, that's just silly if you already have everythign in proper revision control
<infinity> I did quilty packages in maemo git all the time.
<infinity> *shrug(
<pitti> what you want to do is "bzr merge <trunk>", not stuff everything into patches again
<didrocks> pitti: well, I haven't done the transition to source 3 on purpose, seb128 did when I wasn't there despite my warningâ¦ I'll revert for P
<infinity> In a Debian system, the source package is ALWAYS authoritative, nothing is ever in proper revision control. :P
<infinity> And people who think it is keep dropping changes.
<pitti> right, the two concepts are fundamentally incompatible
<didrocks> pitti: maybe not dropping for an SRU, or is it ok?
<pitti> but with source 1.0, you get a big diff.gz, but at least it's policy compliant (apt-get source gets you what is built), and doesn't break bzr
<pitti> didrocks: oh, for P is fine
<didrocks> ok
<infinity> pitti: I actually used to like that I could keep cherrypicks in debian/patches and not have random changes in my source, but to each their own.
<infinity> pitti: Made it more obvious (to me) when an upstream cherrypicked change got merged in.
<didrocks> infinity: not exactly the same when upstream is in bzr and you can bzr merge
<infinity> pitti: Cause it's basically silent if you've picked INTO your tree and then merge.
<pitti> infinity: right; but then "bzr merge" just DTRT without you having to mess with debian/patches and the like
<infinity> pitti: Whereas you get a nice "hey, the patch doesn't apply anymore" when it's external, and you remember to, like, document it.
<didrocks> infinity: we never do that for patches that are not upstream
<didrocks> infinity: for those, it's debian/patches
<infinity> didrocks: I did this for a long time with upstream in git and maemo building directly from git.
<infinity> But, like I said, others preferred your method.
<infinity> Both work.
<infinity> I'm not picky.
<infinity> Though maemo also had clever ways to nominate tags as upstream versions, etc, so you could re-roll a pristine orig from git at any time.
<infinity> And yet, if we get there soon with all the UDD/bzr stuff, I really hope I can still just blat a normal source package at an ftp server too.
<infinity> I'll be miffed if I can't.
<slangasek> are you not just referring to pristine-tar, which UDD uses?
<infinity> slangasek: Dunno.  Am I?
<slangasek> couldn't say for sure; pristine-tar is joeyhware, dunno if maemo would've been using that
<infinity> slangasek: Well, I can't be referring to whatever UDD uses precisely, because we still have to have an original orig.
<slangasek> you have to have an orig.tar.gz when you upload to the archive
<slangasek> but you can synthesize it from the UDD branch at any time
<infinity> slangasek: The maemo trick was that on a new upstream version, you say "this tag is the orig", this tag is the -1, and it would construct and upload for you.
<infinity> slangasek: (After that, of course, it hung on to the one it created and worked as a normal Debian archive would)
<infinity> The downside is that maemo's orig's never match the sums of upstream drops.
<infinity> Which annoys me.
<slangasek> oh
<slangasek> then yeah, not pristine-tar, because *that* is what pristine-tar gives you
<infinity> It took me a long time to really get into a new workflow where "tagging is uploading" too.
<Daviey> didrocks: Having converted eucalyptus from bzr merging to quilt, i can say i did not enjoy it.
<Daviey> It's near imposible to reconcile once changes have been tweaked, bzr blame is of little help.
<Daviey> Let alone measure the delta.
<didrocks> Daviey: well, we cherry-pick a lot from the unity trunk, not sure how often you need this
<Daviey> Hmm, although, that was slightly different - because the distro version was a fork, with out own orig tarball (not my choice.)
<infinity> Daviey: Ew.
<Daviey> infinity: yah
<Daviey> I'm told bzr looms is the 'right' fix for this issue.
<didrocks> yeah, I need to give bzr looms a try at some point :)
<Daviey> I'd just like bzr to suck in quilt patches, and generate them again at export/build-deb.
<Daviey> and i want a pony.
<infinity> Then you want the precursor to the precursor to UDD, back when Keybuk was working on it and it never actually became anything.
<infinity> Every patch was a branch, and it de/re-constructed on the fly.
<infinity> And there's no real reason a simple wrapper still couldn't do that, it would be much easier now that we have a standard (3.0 quilt) for this.
<Daviey> http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt
<Laney> ScottK: no, I mashed it to Triaged and then back to New
<Laney> didn't it take?
<Laney> yes, it did
<Laney> I was trying to undo the auto-confirmation...
<infinity> Oh, FFS.  unity is skewed now, no ARM images for me. :/
 * pitti feeds the armel buildd hamsters
<pitti> I wonder if powerpc ever catches up
<pitti> now that the "needs build" queue is down to 4, we got a LibO update coming :)
<pitti> but we better get that in today, so that it can build over the weekend
<pitti> infinity: ^ armel FTBFS fix, if you are so inclined
<Laney> tjaalton: I don't see the forward_pass change in your diff
<tjaalton> Laney: oops, good catch
<infinity> pitti: A reverse debian diff?  Well done.
<pitti> infinity: screw UDD and its pre-applied patches
<ogra_> hmpf
<pitti> a million ways to get it wrong, one undiscoverable one to get it right :(
<infinity> s/and.*//
<infinity> pitti: I always, always debdiff my uploads against a pristine apt-get source of the current archive version.  Pretty much because I don't trust anything.  Or myself. :P
 * ogra_ wonders why we have no code that recognizes zram swap and makes sure we don't offer hibernate on that 
 * Laney trojans debdiff
<tjaalton> Laney: new one attached
<Laney> ty
<tjaalton> damn
<tjaalton> the reason why it wasn't there was that I changed the priority
<tjaalton> so I need to revert that too :)
<tjaalton> so it's either keep the current pam-auth-update priority and add forward_pass, or change the priority (which then matches upstream suggestion of always having it below pam_unix)
 * infinity blinks.
<infinity>  Package: libreoffice-gcj
<infinity> -Architecture: alpha amd64 armel armhf hppa i386 ia64 mips mipsel s390 s390x sparc kfreebsd-amd64 kfreebsd-i386
<infinity> +Architecture: hppa kfreebsd-amd64 kfreebsd-i386
<infinity>  Section: java
<infinity> Ahh, the changelog is enlightening. :P
<Laney> that seems like an interesting upload for after Final Freeze
<Laney> tjaalton: I'm minded to approve the current diff
<tjaalton> Laney: if I change the priority backt to what it was?
<tjaalton> -t
<tjaalton> so, add forward_pass, keep priority, and re-think about it for P
<Laney> right
<tjaalton> cool
<Laney> get it picked back up in Debian for P :-)
<tjaalton> of course, I'll merge the packaging
<tjaalton> as soon as I'm accepted to collab-maint :)
<Laney> looks like it's being maintained by nmu anyway these days
<tjaalton> yeah
<Laney> alright, approving
<tjaalton> thanks!
<Laney> there we go
<tjaalton> Laney: subscribed ;)
<infinity> pitti: libreoffice seems reasonable to me, BTW.
<infinity> pitti: If you weren't also reviewing it already. :P
<infinity> pitti: (Then again, you probably know it better, so carry on)
<pitti> infinity: can do
<pitti> I already checked the debdiff when sponsoring
<pitti> accepted
<pitti> the world is one again
<ogra_> yeah
<Laney> please accept sssd (ffe granted)
<pitti> Laney: done
<doko_> please accept ghdl
<didrocks> ScottK: pitti: so, agateau has a new patch for Qt, hopefully this time really fixing bug #805303
<ubot4> Launchpad bug 805303 in xorg-server (Ubuntu Oneiric) (and 7 other projects) "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed with the default qt4 gui (affects: 148) (dups: 46) (heat: 670)" [Critical,Invalid] https://launchpad.net/bugs/805303
<infinity> pitti: Can you give alsa-lib some love?  Fixes sound on Pandaboards.
<Daviey> Can i ask for a server re-twirl please?
 * cjwatson -> out for a while, need to take daughter to speech therapy
<pitti> infinity: ... harder? (there was alreayd a fix yesterday) -- sure, looking
<didrocks> pitti: basically, there is 2 choices: either agateau patch Qt, either readd a removed symbol in gtk
<infinity> pitti: Yeah, I know.  I fail at replicating my test system in my uploads, apparently.
<infinity> pitti: Danke.
<pitti> didrocks: for the scrollbar "huge widget" bug?
<didrocks> pitti: yeah, that one
<pitti> didrocks: I'm afraid I don't know which is better
<didrocks> agateau: any preference? why did you remove the first symbol draft?
<didrocks> agateau: because you prefered set(enabled/disabled) ?
<agateau> didrocks: yes, it felt more in line with gtk api
<agateau> didrocks: updating the Qt patch is more elegant, updating the GTK patch is probably less build resource intensive
<infinity> Don't care about build resources, but correct and sane would be nice.
<didrocks> pitti: agreed then, Qt upload? ^
<didrocks> sorry for armel builders, once againâ¦
<infinity> We'll live. :P
<pitti> didrocks: Qt it is
<pitti> really, powerpc is a lot more worries right now
<pitti> we've got loads of armel builders, but the two powerpc ones haven't caught up for a week or more
<didrocks> pitti: oh? with universe stuff? previous Qt is already built on it
<pitti> didrocks: yes, with anything
<didrocks> (not the case for armel)
<pitti> universe keeps being pushed after main ones, of course
<didrocks> yeah
<didrocks> ok, bzr bd -S, and dput in 20 minutes then
<infinity> PPC keeps getting slammed by kernel PPAs. :/
<infinity> But it's never more than a few hours behind, so it's not the end of the world.
<Daviey> Did someone trigger the server rebuild?
<pitti> need to get offline for an hour or so, I'll be back on the train
<ScottK> Accepted qt4 based on what pitti said earlier.
<ScottK> Sooner started is sooner finished.
<ScottK> OK.  I would have if LP hadn't timed out.
<ScottK> Now it's done.
<cjwatson> back
<ScottK> The akonadi upload is a bugfix update from upstream.  Akonadi/kdepim is shaping up to be a complete disaster this cycle, so I want every fix in I can get.  I'd appreciate it if someone would review (we're waiting on Qt anyway).
<JohnLea> didrocks; we have a big problem with the dash search filters.  A range of problems that were supposed to be resolved by yesterday's release have not been fixed, and basically the 'filter results' section is a bit mangled.  ;-(  I have raised a number of new bugs, the bugs in question are: #863252 #863246 and #863240
<JohnLea> didrocks; I think we need to get these fixed for a day 0 SRU?
<didrocks> bug #863252, bug #863246 and bug #863240
<ubot4> Launchpad bug 863252 in unity (and 1 other project) "Dash - in the search filters, the "All" button should always be in the selected state when no other option in that filter category is selected (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863252
<ubot4> Launchpad bug 863246 in unity (and 1 other project) "Dash - the options in the "filter results" section are the wrong size, aligned incorrectly, and the button outline width is incorrect (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863246
<ubot4> Launchpad bug 863240 in unity (and 1 other project) "Dash - the "Filter results" text is the wrong size, wrong font weight, and aligned incorrectly in both the vertical and horizontal axis (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863240
<ScottK> It would be nice if people didn't develop right up until final freeze.
<didrocks> JohnLea: I think those bugs will need an image about before/after (from the description, there are quite a lot of changes)
<didrocks> JohnLea: anyway, I guess it's the release team/SRU team which can discuss if those bugs can qualifies or not
<JohnLea> didrocks; I've attached the images to the bugs, I have to go into a meeting now, speak soon
<JohnLea> didrocks; (also updated bug description)
<didrocks> JohnLea: sure, thanks
<infinity> So... Feature Freeze was a month and a half ago, and UI Freeze was a month ago.  I'm having a hard time finding sympathy for new bugs introduced by new features that turn out to have broken your UI that was still being worked on.
<infinity> (Not trying to sound harsh here, but this can't and won't work this way for the LTS cycle)
<infinity> JohnLea / didrocks: ---^
<dobey> infinity: thanks for the webkit upload
<infinity> dobey: Thanks for the fix. :)
<ScottK> infinity: If you want release team support for reverting stuff, I'm with you.
<didrocks> ScottK: it hasn't been pushed, it's just design still wanting some UI adjustement. I told JohnLea it was out of question before finale and to discuss himself with you for a SRU
<didrocks> I'm just passing the message around to ensure I don't find any agressive merge in trunk that I have to revert for next upload
<ScottK> I'm not on the SRU team, so it's not my call, but I don't think "Oh, we'd like to tweak the U/I" fits the SRU criteria.
<didrocks> ScottK: agreed as well, even if I'm not in that team
<ScottK> Actually none of those bugs are even listed as affecting Ubuntu right now, so not yet our concern.
<didrocks> I prefer to warn dx/design before the changes are done, hence I asked him to raise the discussion here
<ScottK> Good.
<ScottK> Although considering how well they generally manage to understand the concept of feature freeze, I'm not sure how much it will help.
<didrocks> ScottK: I guess and hope those kind of discussion can help them to raise the awarenessâ¦
<didrocks> this package fix an overwrite issue btw ^ (missing epoch)
<ScottK> I'll look at.
<ScottK> infinity: Would you please press the "I believe" button on my akonadi upload?
<ScottK> Someone beat me to it.
<ScottK> didrocks: It's in.
<ScottK> infinity: Thanks.
<didrocks> ScottK: thanks
<ScottK> (wasn't me)
 * infinity raises hand.
<didrocks> thanks to whoever acked it :-)
<infinity> It was a 2-second review. :P
<didrocks> ;)
<didrocks> indeed
<infinity> One line changelog, 2-character fix.  We need more of those.
<ScottK> infinity: I was thinking, it'd be nice if we had an audit trail on who accepted stuff.
<ScottK> Isn't that a nice idea.
<ScottK> infinity: even better would be one line change log, two character fix, 12 hour build ....
<infinity> ScottK: I've been up all night, we've had this conversation before, and you're just being ironic, right?
<ScottK> infinity: Yes.  Highly.
<ScottK> Sorry.
<infinity> Check.
<Laney> has someone filed a bug for that?
<ScottK> No idea.
<infinity> I'd guess there's been one since around the same time /+queue was first made public.
<infinity> But I have no idea.
<infinity> Someone else can review nautilus.  On the one hand, the changelog screams "we want this upload", on the other hand, I'm too tired to do it proper justice.  That's a fair few fixes to pore over.
 * infinity goes to try to nap.
<Laney> probably covered by bug #42831
<ubot4> Launchpad bug 42831 in launchpad "Mail notifications for administrative actions (dups: 1) (heat: 2)" [High,Triaged] https://launchpad.net/bugs/42831
<ScottK> Keep in mind in LP terms "High" means "We think we'll get to it someday".
<Laney> well, I did note the bug number
<Laney> I'm sure there are people who can cause priorities to be reassessed if they are so inclined
<infinity> Laney: Not really.
<infinity> Laney: Not without really irritating escalation processes and the like.
<Laney> I can believe there is bureaucracy there
<ScottK> So.  I'm looking at this Ubuntu font package.
<ScottK> Which leads me to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157#20
<ubot4> Debian bug 603157 in wnpp "ITP: ttf-ubuntu-font-family -- Ubuntu Font Family, sans-serif typeface hinted for clarity" [Wishlist,Open]
<ScottK> So is it a bug that you can't actually modify the source without non-free tools and it's in Main or does Ubuntu allow that?
<Laney> indeed, I understand that's the file format of a proprietary application called FontLab
<Laney> if http://www.ubuntu.com/project/about-ubuntu/licensing is policy, then I don't see any such requirement
<ScottK> Right, so it can be "Free" even if you need non-free tools to excercise it.
<Laney> then again, I don't see such a statement on the face of the DFSG either
<ScottK> True.  I could find it in DFSG #3 if I stare at it a bit though.
<Laney> I think Policy 2.2.1 is typically invoked
<ScottK> 2.2.1 doesn't specify editing though.
<Laney> plus a bit of FTP master case law
<Laney> see Joerg's statement further down in that thread
<ScottK> Right.
<ScottK> That was mostly about the license though.
<Laney> it has a bit about modification
<Laney> anyway, being signed up to the DFSG, I do agree with that interpretation
<ScottK> Looking at the package, it doesn't appear to use the shipped source to build the ttfs, so I think you're right.
<tkamppeter> Anyone from the release team arround? I get a lot of pressure from Ghostscript upstream (See http://ghostscript.com/irclogs/, search backwards for tkamppeter, starting at the point of now) about not using libcms1 as it is discontinued upstream and full of bugs. Instead I should use their heavily patched version, which fixes many segfaults (not only Apple-generated figures) but also color incorrectness.
<bdmurray> Could the release manager of p-series be set so I can target bugs to it?
<cjwatson> bdmurray: done
<bdmurray> cjwatson: thanks
<Daviey> Did anyone see my request for a server re-twirl?
<cjwatson> Daviey: apparently not.  Running now
<Daviey> cjwatson: Thanks!
<tkamppeter> Anyone has anything to say on my Ghostscript issue? Or better SRU?
<ScottK> tkamppeter: Probably better in "P" to get it fixed properly.
<tkamppeter> ScottK, so I will start a test program when P opens and if an O use complains he gets a personal fix from me (through a PPA). OK?
<ScottK> For oneiric, I think if there are specific issues, fixable with a specific patch they should go through SRU.
<slangasek> Daviey: you've closed bug #529714 without addressing the reason I reopened it...
<ubot4> Launchpad bug 529714 in samba (Ubuntu Oneiric) (and 9 other projects) "rhythmbox crashed with SIGSEGV in _nss_wins_gethostbyname_r() (affects: 104) (dups: 37) (heat: 670)" [Critical,Fix released] https://launchpad.net/bugs/529714
<ScottK> It's too late to update the library for oneiric.
<tkamppeter> ScottK, simply let us not advertize color management for printing, it is still in grow-in-and-stabilize phase.
<tkamppeter> ScottK, or can I post the move from the broken stock LCMS1 to the fixed Ghositscript-upstream-LCMS1 as an SRU?
<tkamppeter> ScottK, the library (lcms package) will not get updated on such a fix, GS will use a statically linked version supplied by Ghostscript upstream and tested by their commercial customers.
<tkamppeter> ScottK, this version is color-adjusted and anti-crash-proved on thousandfs of test files.
<Daviey> slangasek: Ah, apologies - did not.
<ScottK> tkamppeter: There are 44 reverse build-depends for liblcms1-dev.  Fixing it for ghostscript isn't enough.
<tkamppeter> ScottK, I will not touch the lcms1 package nor lcms1-dev. I will only switch the ghostscript package from using the lcms package to bringing its own internal lcms1 code which will get built into Ghostscript and only used by Ghostscript itself.
<tkamppeter> ScottK, so no other package can get broken by that.
<ScottK> If that one is better, why not use that for everything?
<Daviey> slangasek: zul is *on* *the* *case*.
<tkamppeter> ScottK, getting it into GS now is a simple flick of a ./configure script. Ghostscript works with it as it got already tested by the commercial customers of Artifex. Putting the changes into the general, shared library can easily break the interface to the other apps which use lcms1.
<ScottK> Code copies suck.
<ScottK> Someone should do something about this.
<tkamppeter> ScottK, this copy is short-termed as GS upstream already works on the LCMS2 switchover and then they will be able to upstreamize their patches to upstream LCMS.
<pitti> argh, disconnect; replying, sorry if you got this twie
<pitti> infinity, ScottK, cjwatson: whoever reviews the lightdm upload: it's a fairly large patch, please feel free to ask me about details; the AA profile is copied from gdm-guest-session (where it has worked for several cycles), except the update for /run
<pitti> sorry for landing this late, I just took over the bug assignment today, it slightly fell off the radar so far
<pitti> I tested it fairly thoroughly, though
<pitti> infinity: FYI, I pinged Sweetshark for the LibO failed to upload (missing pre-depends for xz compression); let's hope he's still online to get a fix today for building over weekend, I'll try calling him, too
<ScottK> That's pretty unlikely to be me reviewing it.
<ScottK> So don't anyone else wait hoping I will.
<pitti> I hope infinity can get to it
<pitti> now that lightdm allows running a guest session without a prior "real" user login, allowing the guest session to read all home dirs is pretty bad
<slangasek> Daviey: cheers :)
<tkamppeter> ScottK?
<ScottK> tkamppeter: yes?
<tkamppeter> ScottK, how should we procced with GS then?
<ScottK> pitti: Wouldn't it always be bad.
<ScottK> tkamppeter: I'm probably not the one to make the final decision.  I'd ask pitti, but I'd want the security team to agree to enabling a code copy at this point.
<jcastro> skaet: I made some changes to the juju parts of the technical overview to make it clear that it's a technical preview and where users can follow development, etc. so they're not stuck in a vacuum
<pitti> ScottK: I already said I'd rather not tear it apart for now; aside from the general "eww" of duplicate and heavily patched libraries, we didn't test that changed ghostscript
<ScottK> pitti: OK.  Then we should definitely leave it as is.
<pitti> infinity: I called Sweetshark about the LibO "failed to upload", new version shoudl come today still
<skaet> thanks jcastro
<pitti> ok, good night everyone!
<tkamppeter> pitti, ScottK, let us solve the Ghostscript problem next week.
<slangasek> skaet: the eglibc package uploaded to the queue is a no-code change to the packaging, to try to give apt enough information to properly handle upgrades when gcj-4.4 is installed (bug #853688).  Is this ok to accept?  It of course means we have to wait for builds before mastering any final images, but I wouldn't expect those to be happening just yet anyway
<ubot4> Launchpad bug 853688 in gcj-4.4 (Ubuntu Oneiric) (and 3 other projects) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed (affects: 17) (dups: 7) (heat: 92)" [High,In progress] https://launchpad.net/bugs/853688
<slangasek> looks like ~12h to build eglibc on arm
<lamont> slangasek: panda or bbg3/beaglexm?
<slangasek> lamont: I think that was a bbg3
<lamont> some fruit, eh?
<slangasek> yes, some sort of claptonesque drupe
<dobey> lamont: http://www.youtube.com/watch?v=Ye1e32J98Fs
 * slangasek accepts eglibc
<skaet> slangasek,  thanks for the explanation re: eglibc.
<pitti> slangasek: we'll need another LibO upload anyway, so eglibc shouldn't be critical path even
<slangasek> pitti: right, doh
<slangasek> pitti: bug #854622 - you say "Given that this was reproduced using a natty install"... where is that given? :)  The only natty comment I see is that it *wasn't* reproducible on a clean natty install
<ubot4> Launchpad bug 854622 in update-manager (Ubuntu Oneiric) (and 3 other projects) "Could not install libglib2.0 (affects: 1) (heat: 10)" [High,Invalid] https://launchpad.net/bugs/854622
<mvo> slangasek: I wonder if its time for the sledgehammer, a preinst that will do a md5sum check and move the right file in place?
<slangasek> mvo: er?  It's the *directory symlink* that needs to be cleaned up
<slangasek> if you don't fix that, the problem will always recur
<mvo> slangasek: oh, indeed, I missed the latest addition
<mvo> slangasek: ok, so I have one box where I can reproduce this, its exactly the same symlink as michael nelson, so this sounds like a preinst test/rm of the symlink will be enough to fix this? or am I missing something ?
<slangasek> mvo: yes, I believe that's correct
<mvo> slangasek: are you on it already or shall I give it a stab?
<slangasek> mvo: I'm not on it, feel free
<slangasek> mvo: btw, do you see any reason why on upgrades, apt would prefer to keep nfs-common back rather than replacing portmap with rpcbind? :(
<mvo> slangasek: not of the top of my head :) do you have a example bugreport or resolve log maybe?
<slangasek> mvo: I will soon
<mvo> ok
<mvo> I'm testing the glib fix in he meantime
 * Daviey looks at swift
<Daviey> It seems we no longer need to be anally retentive.
<slangasek> hmm?
<skaet> I think he's refering to some recent edits on the process page,
<Daviey> https://wiki.ubuntu.com/FinalFreeze?action=diff&rev2=9&rev1=8
<Daviey> swift package does introduce partial backport support, with condtional --with_python2 support.. which i'm not overjoyed about.  However, the upside is that it resolves a typo where the original only had 1 x -  "-with" .. so it's ok
<Daviey> Patch is neccessary.. it builds, please can it be accepted.
<slangasek> Daviey: I'm rather unhappy with these backport-enabling python2 kludges
<slangasek> yes, it's low risk, but I don't think it's something that should be done, period
<Daviey> slangasek: tell me about it..
<Daviey> I said i didn't want it, infinity said he thought it was appropriate.
<slangasek> hmm
<Daviey> I said i wouldn't block it being merged into the packaging branch, but i wouldn't sponsor it :)
<Daviey> I like debian/backport/$release shell scripts for munging the package myself.  Keeps debian/rules clean.
<slangasek> I like this thing called VCS branching
<Daviey> or that.
<ScottK> slangasek: variously doko and barry have had an action to produce something for lucid-updates to make it possible to backport dh_python2 packages there.  Get that done and the entire problem goes away (dh_python2 is already in Debian stable, so it's only an Ubuntu LTS issue)
<slangasek> yes, I know
<barry> ah, i didn't get a chance to ask doko about status on this :/
<slangasek> and I forgot to ask him until after he's gone afk
<barry> slangasek: between you, me, and ScottK, one of us will remember for monday ;)
<mvo> slangasek: http://paste.ubuntu.com/700064/ <- that fixed the lib2.0-data issue for me, quick double check appreciated, if it looks ok, I will upload
<slangasek> mvo: maybe also include the dpkg version check, with a bumped version to 2.30.0-0ubuntu3 ?
<mvo> slangasek: sure, I will add that as a additional safety guard
<slangasek> ok
<slangasek> LGTM then
<mvo> slangasek: uploaded  http://paste.ubuntu.com/700077/ now, should appear soon
<slangasek> mvo: thanks!
<mvo> theis update-manager upload is actually really useful, it fixed a crash during a natty->oneiric cdrom upgrade for me, when apt grows the mmap cache, we fixed the real bug in oneiric, but natty got not fixed
<mvo> the diff for u-m is pretty tiny too
<mvo> one more to go, then I can go to sleep :)
<slangasek> glib2.0 accepted
<mvo> thanks!
 * slangasek yucks at bug #863675
<ubot4> Launchpad bug 863675 in dpkg (Ubuntu Oneiric) (and 1 other project) "dpkg wrongly claims that a foreign-arch package is disappeared by a removed native-arch package (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/863675
<infinity> slangasek: Oh, ick. :/
<slangasek> yep
<infinity> I think the only sane thing to do is back out all the multiarch patches over the weekend.
<infinity> *waits*
<infinity> slangasek: But in more seriousness, have you found the general area where it might be going wrong, or just the external test case and a head scratch? :/
<slangasek> infinity: I've only gotten as far as the latter
<ScottK> Hmmm.  quickly upload by this barry dude.  Got watch that one closely.
<ScottK> ;-)
<barry> ScottK: most def :)
<ScottK> barry: Please don't mix in trivia like standards version changes in upload like this.  Did you in fact check that the package is 3.9.2 compliant?
<ScottK> Accepted anyway, but FYI.
<ScottK> skaet: There have been a number of upstream commits to kdepim/kdepim-runtime/kdepimlibs that address issues our users have been seeing (c.f longest release note in the history of the world discussion at the release meeting), so I'm updating again.
<ScottK> We need these in.
<ScottK> We'll still have upgrade issues, but it should be a lot more usable.
#ubuntu-release 2011-10-01
<ScottK> infinity: ^^^  Prety please ....
<infinity> ScottK: Bribery would help.
<ScottK> infinity: Thanks.  Anything you want me to cargo cult in in exchange?
<infinity> ScottK: I have a ubiquity upload coming later tonight, but not just yet.
<infinity> If you're around, a review would be lovely.  If not, I'll find someone else. ;)
<ScottK> OK.
<ScottK> Such a perfect time to have a dead powerpc buildd....
<infinity> Did we kill one?
<infinity> Apparently so.
 * infinity accepts grub2 and goes to bed.
<skaet> ScottK, understood.   infinity, thanks for getting them through.
<slangasek> cjwatson, infinity: thanks for the quick grub fix!  Now we just need to revert those nvidia/fglrx blacklists... :)
<stgraber> slangasek: just saw your comments in the bug. So seems like the nvidia blob is actually doing KMS now?
<slangasek> stgraber: no, it isn't, that's not the issue
<slangasek> stgraber: gfxpayload=keep hands a VESA framebuffer off to the kernel, which gets picked up automatically; and that apparently coexists fine with nvidia... but it also leaves the console in graphics mode, with nothing to set it to text mode for us in recovery
<slangasek> exact same thing happens with intel
<slangasek> now a C program to forcibly switch the console to text mode before launching the friendly-recovery menu would be trivial, but it's still a little late to go that route
<slangasek> so we should just use =text for recovery mode for this cycle
<stgraber> oh fun, that explains what komputes reported yesterday then
<slangasek> yes, indeed
<slangasek> if you remember his bug number, please dupe it :)
<slangasek> and then on the menu for today, I have bug #864149 :/
<ubot4> Launchpad bug 864149 in nvidia-graphics-drivers (Ubuntu Oneiric) (and 3 other projects) "initrd doesn't set Fr keyboard layout anymore => couldn't open root luks at boot (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/864149
<stgraber> I guess fixing that one will make my fix for bug 524605 obsolete (starting console-setup to have the keyboard layout properly set)
<ubot4> Launchpad bug 524605 in friendly-recovery (Ubuntu) "Keyboard layout isn't configured by the time friendly-recovery starts (affects: 1) (heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/524605
<slangasek> stgraber: not exactly
<slangasek> not unless we decide to always do console-setup in the initramfs... which we currently do not, for reasons of boot speed
<cjwatson> we do if it panics; it would be fairly straightforward to do that on entry to recovery mode too
<cjwatson> though I don't know whether it'd be better to just do it from f-r instsead
<cjwatson> *instead
<slangasek> cjwatson: for recovery mode, it all currently works
<slangasek> it's for regular boots, with luks root filesystem and binary video drivers where things are going wrong
<slangasek> because the binary video drivers are forcing FRAMEBUFFER=n for initramfs-tools, and console-setup keys on that
<cjwatson> ah, right
<cjwatson> well, again, the bits are all in the initramfs, it would be fairly easy to make c-s check the cryptsetup case too
<cjwatson> (but probably not for 11.10)
 * slangasek nods
<cjwatson> maybe.  I think it keyed off FRAMEBUFFER=n for a reason mind you
<slangasek> boot performance
<cjwatson> yes, but I don't think it was just that
<cjwatson> I have a feeling that it didn't work reliably unless the framebuffer was there
<cjwatson> perhaps because we couldn't set the font yet unless it was
<slangasek> ah
<slangasek> well anyway, setting FRAMEBUFFER=n is the wrong way for the binary drivers to handle this
<cjwatson> (that makes sense now I say it)
<slangasek> the question is whether we'll be able to sort out the right way in a timely manner
 * slangasek goes back to fiddling with his test nvidia box :)
<cjwatson> hmm, infinity got stalled on the flash-kernel-installer related bug he was working on and didn't upload ubiquity overnight; I think I'll do that now, it has several bug fixes which could use maximal testing time
<slangasek> ack
<ScottK> cjwatson: Your ubiquity upload adds gir1.2-soup-2.4 as a ubiquity-frontend-gtk depends.  Was that intentional (not mentioned in changelog)?
<ScottK> Actually I can see it's used in the code now...
<slangasek> cjwatson: is en_US.UTF-8 locale guaranteed to be present?
<ScottK> I think so.
<ScottK> Don't we seed it on everything?
<ScottK> BTW, I accepted it, but don't let that stop you asking questions ...
<slangasek> I'm not sure
<slangasek> hmm, promising lead on the nvidia-initramfs-framebuffer issue
<cjwatson> ScottK: yes, needed for the async geoname fetching code; it was already on all the relevant CDs as far as I could see so I didn't scruple
<ScottK> OK.  Thaks.
<cjwatson> slangasek: language-pack-en-base creates it and currently that's always there
<ScottK> Thanks even.
<slangasek> cjwatson: ok
<cjwatson> slangasek: ultimately it ought to be C.UTF-8 instead but I didn't want to risk that given that we were already using en_US.UTF-8 for a similar purpose elsewhere
<cjwatson> (thanks for asking questions though!)
<slangasek> sure :)
<slangasek> hummm, did we have another regression in pkgbinarymangler?  libxcb-render0 has changelog.Debian.gz listed in md5sums, but it's a symlink
<slangasek> same for a bunch of other desktop library packages
<slangasek> ah, and some of these builds are from June... I guess I should run debsums -s more often :/
<cjwatson> please don't tell me we have to rebuild the world
<slangasek> I don't think it warrants rebuilding the world for a wrong .md5sums
<slangasek> but there are a lot of wrong .md5sums on my system
<cjwatson> argh, ubiquity failed to build, not funny
<cjwatson> oh, missing build-dep I think :-/
<slangasek> ok, got a solution for bug #864149 I think; just need to test it on a non-nvidia system now too
<ubot4> Launchpad bug 864149 in nvidia-graphics-drivers (Ubuntu Oneiric) (and 3 other projects) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override) (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/864149
<cjwatson> slangasek: did you notice bug 862129?
<ubot4> Launchpad bug 862129 in samba (Ubuntu) "package samba 2:3.5.8~dfsg-1ubuntu2.3 failed to install/upgrade: subprocess new post-removal script returned error exit status 2 (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/862129
<slangasek> cjwatson: no, I hadn't.  what do you suggest?  ignoring errors from update-inetd?
<slangasek> not a new issue in any case; I don't see a reason to treat this as a blocker for 11.10
<cjwatson> the general problem isn't easy to solve; perhaps an explicit test that File::Temp is loadable, but that violates layers ...
 * slangasek nods
<cjwatson> it probably isn't, though I'd like to confirm that it doesn't show up in default upgrades
<cjwatson> or default upgrades after samba has been installed anyway
<cjwatson> didn't doc-base run into something similar?
<slangasek> I don't recall
<cjwatson> maybe that was more direct
 * slangasek accepts ubiquity
<cjwatson> ta
<slangasek> hmm, looks like I'm ENOTIME to finish testing this initramfs-tools change now; will have to upload it later this evening
<cjwatson> I suspect that the simplest fix for bug 770711 looks rather like http://paste.ubuntu.com/700779/ (though I'm not going to start testing that at this time of night) - does anyone object to the X-Python-Version bump there, for collections.OrderedDict?
<ubot4> Launchpad bug 770711 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Prefers to install to USB rather than to HD (affects: 3) (heat: 16)" [High,Triaged] https://launchpad.net/bugs/770711
<cjwatson> A backport does exist, but it's a fair chunk of code, and given that 2.7 is our default anyway ...
<Daviey> Seems easy enough to roll back if it does cause issues.
#ubuntu-release 2011-10-02
<ScottK> cjwatson: Particularly for things like the installer I think there is zero reason to be concerned about supporting python < 2.7.
<cjwatson> bug 864618 - anyone else think this is RC?
<ubot4> Launchpad bug 864618 in lightdm (Ubuntu) "UTF-8 locale no longer set (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/864618
<infinity> cjwatson: Quite.
<infinity> cjwatson: I'm curious why 'locale -a' returns *.utf8 rather than *.UTF-8, though.
<infinity> cjwatson: Given that we use the other naming nearly universally, wouldn't we want that tool to output the same format?
<cjwatson> s'always been like that ...
<infinity> Not saying it hasn't.  Just curious. :P
<cjwatson> I think .utf8 is glibc's preferred internal naming but .UTF-8 is what you see in SUPPORTED
<cjwatson> personally I see it as a good thing because it makes sure people NOTICE if they break locale aliases
<infinity> Heh.
<infinity> Well, hunting the bit that broke lightdm should be easy enough.
<Laney> I see "[+6.73s] DEBUG: Failed to find locale for language en
<infinity> As for the jasper thing, I think I might just sprinkle some syncs in and see if that magically fixes it.
<cjwatson>     - Add ability to set the language of a user from the greeter (LP: #803858)
<cjwatson>     - Set LANG variable based on the user language
<cjwatson>     - Add language selector into GTK greeter (disabled by default)
<cjwatson> fairly significant set of additions
<infinity> Just confuses me a tad that it's not trusting PAM's return and just going with it.
<infinity> So, entirely off-topic, but does anyone know off-hand if 'mount -o remount,ro /foo' forces a sync?
<infinity> ^--- accepted that libav upstream version bump with was basically just merging in the ~70 patches that were already in debian/patches, and then 2 or 3 small/isolated fixes.
<infinity> Seemed like a sensible thing to do so the security team would have a stable version to play with, rather than a stable version plus 70 cherry-picks.
<slangasek> nvidia-graphics-drivers - hurrah
<infinity> Those aren't words oft-uttered.
<slangasek> dude, console-setup, what's the deal
<slangasek> why does your build make my laptop overheat
<slangasek> yes, my ACPI tables are screwed up, but why is *console-setup* running hotter than running gcc? :P
<stgraber> slangasek: is your laptop shutting down because of overheat?
<slangasek> yes
<stgraber> is it also doing it when AC is unplugged?
<slangasek> I've got screwed up values in my ACPI, the critical threshold is lower than the passive cooling threshold
<slangasek> so the first time the kernel knows there's a problem is when ACPI tells it to panic-shutdown :P
<stgraber> yeah, I had a similar issue on my x201s until I noticed my power management setting was set to "performance" when on AC, setting that to the same value (don't remember) as when on battery "fixed" it
<stgraber> I can now happily 3 installs in kvm, do some other work and not have my laptop shutdown every 5 minutes
<slangasek> what "power management setting" do you mean?
<stgraber> some value in the BIOS power management section
<slangasek> it's ridiculous that there is any setting that would give this behavior
<slangasek> ok, next time it powers off I'll have a look :)
<slangasek> the other thing is that the fan fails to spin up appropriately
<slangasek> levels 0-7 are all "meh"
<slangasek> only disengaged/full-speed actually pushes any air :P
<slangasek> (and thinkfan doesn't support specifying full-speed :P)
<stgraber> fun. apparently that's one issue the x201s doesn't share with the x201, my fan seems to work fine (set to auto and running at 4531rpm according to /proc/acpi/ibm/fan)
<slangasek> apparently it's ckbcomp that chews the CPU up.  Really efficient, or really inefficient?
<stgraber> yeah! just reinstalled my server at home on Oneiric (used to be Hardy) using a single stack IPv6 network. Only issue I noticed was archive.u.c not having a AAAA record so had to switch to uk.archive.u.c
<slangasek> whee, 'totextmode' works for bug #864466
<ubot4> Launchpad bug 864466 in kbd (Ubuntu Oneiric) (and 3 other projects) "break=foo boot option incompatible with gfxpayload=keep (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/864466
<slangasek> oh, doh, no it doesn't
<slangasek> it just looked like it did because plymouth was being helpful :P
<slangasek> ah right, because totextmode didn't actually get copied to the initramfs
<cjwatson> slangasek: I tried to optimise ckbcomp earlier in the cycle, but ran out of time ...
<cjwatson> argh, why does oneiric now want to suspend my laptop every time I step away from it for a while
<infinity> Because GNOME knows best?
<infinity> Don't question it.
<slangasek> cjwatson: because the GNOME3 default sleep policy is ridiculous - though fortunately we at least now have a setting to change the policy
<cjwatson> I went into System Settings -> Power after the last time it happened and told it not to do this.  It did it again.
<slangasek> hmm
<slangasek> perhaps the setting isn't wired up correctly then
<cjwatson> I suppose it might be confused by apparently thinking I have two batteries
<infinity> Do you?
<cjwatson> No
<stgraber> cjwatson: http://paste.ubuntu.com/701188/
<stgraber> I gave up trying to do it through the UI last time...
<cjwatson> stgraber: ah, thanks!
<cjwatson> I'm sure this won't bother any of our users at all
<cjwatson> err.
<slangasek> well, the UI is supposed to address precisely those settings; if it's not doing so, I'd say that's a critical bug
<slangasek> I have these settings here:
<slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac false
<slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 1800
<slangasek> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
<infinity> Does the UI not touch all the settings that stgraber pastebinned?
<infinity> If it's exposing them but not actually setting them, that's unpleasant.
<cjwatson> slangasek: I had those values for sleep-inactive-ac and sleep-inactive-ac-timeout before, but sleep-inactive-ac-type was set to 'suspend'
<cjwatson> is it possible that that was introduced after an upgrade and not migrated properly?  maybe the UI would have done it if I'd changed to something else and back again
<stgraber> infinity: there's the "Suspend when inactive for:" in the power section of gnome-control-center but at least at some point this week it wasn't setting it properly...
<infinity> Grand.
<infinity> Perhaps we should be testing that control panel with some vigor on upgraded and fresh systems?
<slangasek> infinity: dunno, I haven't tested, I already set it by hand before the GUI existed
<stgraber> some actions are also missing from the UI. I kind of like my screen to just go blank when I close the lid but that option isn't in the drop down (though it's a valid value in the gsettings schema)
<infinity> Surprising suspend behaviour is one of the nastier user experiences. :/
<cjwatson> if I change sleep-inactive-ac-type to 'nothing' and then tell it to suspend after 1 hour in the UI, it remains at 'nothing'
<cjwatson> bug 864479
<ubot4> Launchpad bug 864479 in gnome-control-center (Ubuntu) "System goes to hibernate or suspend even when set to "Don't suspend" (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/864479
<cjwatson> shall I crank the priority on that and milestone it?
<slangasek> IMHO yes
<slangasek> (though probably -updates material at this point?){
<cjwatson> depends how big a change it is?
<slangasek> I'd like to see the schema fixed as well to give a sensible default policy on AC :P
<cjwatson> that would be a separate bug I think ...
<cjwatson> (though I agree)
<infinity> slangasek / cjwatson: Can I get one of you to review 'bzr diff /home/adconrad/debian-cd/' on antimony?
<infinity> Should fix the short image bugs I was seeing.
<cjwatson> um, well, the code's OK, I really can't vouch for accuracy of what it's intended to do ...
<infinity> And then I can get back to fixing jasper. :P
<infinity> cjwatson: The problem, in both cases, was that no one was accounting for the "reserved blocks" before the boot/ext partitions.
<infinity> cjwatson: On mx5, that's 1 sector, on omap, that's one track (32 sectors).
<infinity> Represented by these two errors:
<infinity> [164532.491847] EXT4-fs (sdb3): bad geometry: block count 1580032 exceeds size of device (1580031 blocks)
<infinity> [145254.594400] EXT4-fs (sdb2): bad geometry: block count 1505280 exceeds size of device (1505264 blocks)
<infinity> (Note those are in 1k blocks, not 512 byte, hence the count being a bit confusing)
<infinity> That is EXT4 is whining in 1k blocks, but the debian-cd code is in 512 byte sectors.
<stgraber> looking at the code of the power configuration plugin, the state of sleep-inactive-battery seems to change the value of sleep-inactive-battery-timeout but not the other way around. So having sleep-inactive-battery=False will set sleep-inactive-battery-timeout=0 but choosing sleep-inactive-battery-timeout=0 in the drop-down won't set sleep-inactive-battery=False
<cjwatson> infinity: seems plausible, then
<infinity> cjwatson: I can live with plausible.
<cjwatson> stgraber: sleep-inactive-battery was set to false for me, so I don't think that's my problem
<slangasek> stgraber: but is sleep-inactive-{ac,battery} even the right key, or does it need sleep-inactive-{ac,battery}-type?
<infinity> cjwatson: It can't actually make it more broken to add more space.  I'm just hoping all the cross-eyed reading made me get the right amount. ;)
<cjwatson> stgraber: (well, -ac)
<cjwatson> infinity: right, makes sense
 * infinity wonders if checking to see if /usr/lib/klibc/bin/reboot takes a --help argument will lead to his system rebooting.
<infinity> ... and maybe I'll try on another computer. :P
<stgraber> cjwatson: Poking through the UI I actually see both sleep-inactive-battery and sleep-inactive-battery-timeout being updated to the right value ... that gsettings stuff is way too magical. The only key that's not changed is sleep-inactive-battery-type but it shouldn't need to be changed anyway...
<cjwatson> infinity: I think it might actually give you a usage message by coincidence
<cjwatson> looking at the code
<stgraber> slangasek: I'd have expected timeout=0 + option being set to False to be enough for it not to do anything but maybe that's where the bug actually is :)
<cjwatson> stgraber: well, -type is what your paste changes
<cjwatson> stgraber: I guess I'll find out after the next time I come back to my laptop
<infinity> cjwatson: It did, yes.  Not a terribly helpful one.
 * infinity goes to look at the code instead.
<stgraber> ok, grabbing gnome-settings-daemon's code then as gnome-control-center seems to do what it's supposed to
<cjwatson> bug 864787 - d'oh
<ubot4> Launchpad bug 864787 in ntfs-3g (Ubuntu Oneiric) (and 1 other project) "Cannot mmap file /usr/lib/libntfs-3g.so (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/864787
<cjwatson> will fix tomorrow
<infinity> slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me?
<infinity> Maybe I should have asked that when we weren't horribly netsplit. :P
<infinity> slangasek / ScottK / anyone: Around for a quick review of jasper-initramfs for me?
<infinity> cjwatson: Or you, if you're not asleep or otherwise occupied? :)
<infinity> We really need a way to make cron.daily not run for a day after installation.  I have it running right now during oem-config-remove (yeah, I don't even have a login yet) and apt-xapian-destroyer-of-worlds is pretty much just telling me where to go and how to get there.
<slangasek> infinity: 'service cron stop' during the install maybe?
<infinity> slangasek: Maybe.  Would be nice to avoid it for some undetermined amount of time post-install too, though.
<infinity> If your very first user experience is "everything is slow", it kinda sucks.
<infinity> I assume it's anacron going "holy crap, we haven't booted in FOREVER" and just firing everything.
<slangasek> hmm
<slangasek> I'd rather we figure out if we're running things we shouldn't need to and stop doing that, than just deferring everything 24h and leaving stuff out of date
<infinity> See -devel too.
<infinity> But yeah, I don't think a universal defer is sane.
<infinity> And I think that if you happen to install at 4am, or whenever daily is MEANT to happen, sucks to be you.
<infinity> But anacron running daily unconditionally after install is broken.
<infinity> Or during install, even.
<infinity> oem-config-remove-gtk timed out a dbus call due to apt-xapian.  Oh dear.
<infinity> So, part of the problem here is installing a desktop OS to an SD card on a cell phone.
<infinity> But still, this can't be pleasant on desktop hardware either, just less awful.
<Laney> Don't we run under {,io}nice?
<infinity> We, being.. The installer?
<infinity> Niced up or down?
<Laney> Jobs spawned from anacron. Niced to be ... nice
<infinity> Oh, yes.
<infinity> Generally.
<infinity> But on slow systems, now amount of nice can fix this sort of thing.
<infinity> s/now/no/
<stgraber> "nice ionice -c3 update-apt-xapian-index -q" (from cron.daily/apt) but that's probably not enough on a system with very slow I/Os
<infinity> It's really not.
<Laney> I guess, yeah.
<infinity> update-apt-xapian-index is vicious.
<infinity> It brings some of my laptops and netbooks with real hard drives to their knees.
<infinity> On SD, it's... Well... Hahaha is the only real description.
<infinity> And part of that is mvo needing to profile the heck out of it, and he knows.
<infinity> But I still think the general idea of "anacron running cron.daily within seconds of the install completing" is never going to be the best user experience.
<stgraber> infinity: touching /var/lib/apt/periodic/update-stamp should be enough to delay it for a while
<infinity> stgraber: That would solve the update-apt-xapian-index one, I guess?
<infinity> stgraber: Which is the big one for now.
<Laney> Still, having it delayed just long enough for you to get down to some real work also sucks.
<infinity> (anacron is still the actual complaint for me, I think, but that workaround might be lightweight enough to even be doable for release)
<stgraber> yep, that's the one being checked just before calling update-apt-xapian-index
<Laney> you can probably touch /var/spool/anacron/cron.daily
<infinity> I might do one or both of these as an ARM-only hack, if people aren't keen on doing it to, say, ubiquity.  But I'll toss it around tomorrow when people are "at work".
<infinity> Thanks for the ideas and digging.
<stgraber> I guess touching /var/spool/anacron/cron.daily just before unmounting /target in ubiquity would be a good way of avoiding most of the pain
<infinity> Might need to happen earlier than that for the oem-config case.
<infinity> What's the default delay for cron.daily?
<Laney> Aaaargh. Why has my compose key mapping disappeared and where has the UI gone?
 * Laney wonders why these things are breaking after final freeze
<infinity> It'll fire 5 minutes after boot.
<infinity> Yeah.  Maybe I'll just hack around it in jasper for ARM for now.
<infinity> And revisit it in ubiquity later, when I can generalise an oem-config/live-install solution that works for both.
<infinity> (Well, okay, I guess it's just touching it early if oem-config mode, and later if not, but whatever)
<infinity> I have gin and tonic calling me.  Beckoning, even.
#ubuntu-release 2012-09-24
<phillw> oooh, yaboot?!
<hyperair> hmm? i thought banshee was going to wait until next week to be approved?
<cjwatson> Urgh, who accepted banshee?
<cjwatson> Thanks for wasting my time.
<cjwatson> hyperair: Unfortunately there's no way to leave notes in the queue for people who don't read IRC before processing it.
<phillw> cjwatson: thanks for the email, I have replied.
<iulian> olli: OK, I will try that fix later on today (I have to leave quite soon). You can check on LP to see if libunity-webapps had an upgrade or something (or #ubuntu-unity, they should know).
<Laney> hmm
<iulian> olli: And regarding the version of bamfdaemon - I've got 0.3.0-0ubuntu2 installed.
<Laney> should we decron and do a full image set to b2?
<jamespage> all node related syncs are for the switch from /usr/bin/node -> /usr/bin/nodejs in Debian
<jamespage> (I'll get that added to release notes as well)
<psivaa> there are two OVERSIZED entries in cdimage.u.c for quntal amd64 and amd64+mac, i guess this is not so alarming since there is no cd support?
<xnox> psivaa: depends, i thought the OVERSIZED check has been adjusted for the new target size.... therefore it can be alarming
 * xnox now ponders about MB MiB units....
<psivaa> xnox, both are 764 and 765 M's , but i suppose for quantal 800M is allowed?
<xnox> psivaa: the text of the warning is miss leading. See that i386 751MB doesn't have warning.
<xnox> psivaa: yeah 8000 but base 2 or base 10?
<xnox> psivaa: yeah 800MB but base 2 or base 10?
<Laney> http://www.wolframalpha.com/input/?i=800+MB+in+MiB
<Laney> seems likely
<psivaa> xnox, the size is less than 800M base 2
<tumbleweed> psivaa: otherwise known as 800MiB
<xnox> Laney: I like that link! Didn't know WOlfram did that!
<Laney> wolfram does all
<tumbleweed> or jsut use GNU units
<xnox> Laney: so the text of the warning should be modified to say "above target size %s" and ideally substitute that value.
<xnox> or just leave at above target size.
<xnox> and it does look like amd64 is oversized =(
<psivaa> tumbleweed, i see :)
<psivaa> xnox, i guess so there will be something done to trim it?
 * xnox is  not on release team =)))))
<ogra_> xnox, just take a look at debian-cd :)
<ogra_> it has (($foo * 1024 *1024)) everywheer
<xnox> ogra_: I like $foo =)
<ogra_> heh
<psivaa> lol
<xnox> bytes is so unambigious.
<psivaa> ogra_, i am just wondering if those two oversized images will be rebuilt soon, will they :)?
<jamespage> Daviey, I have a new upstream bugfix release prepped for ceph - OK to upload now or would you prefer if I waited until after beta-2?
<jamespage> its seeded but does not ship
<ogra_> psivaa, no idea
<psivaa> ogra_, ok, thanks
<psivaa>  size change may not affect our test results too much, but just wanted to confirm, we are continuing the testing on those images
<ogra_> i would assume so, but for respins better wait for someone from the release team
<cjwatson> psivaa: the oversized warning is wrong; for now, ignore it
<cjwatson> haven't got round to adjusting those limits
<Daviey> jamespage: please upload, that will be fine.
<cjwatson> it won't fit on a CD, but that was what was agreed for 12.10
<ogra_> it was 1G now, wasnt it ?
<cjwatson> 800M
<ogra_> oh, k
 * jamespage was wondering where nodejs had got to
<jamespage> Daviey, ack - ta
<psivaa> cjwatson, ok thanks,that helps
<Daviey> jamespage: why the Architecture s/linux-any/any/ ?
<xnox> cjwatson: "Sep 04 20:59:28 <stgraber>	plars: the limit was already changed by slangasek" no other sources. Note that amd64[+mac] have oversize markers, but i386 does not. Although all three are >>705MB but i386 is below the magical 762.9MiB (as per Laney's link above)
<cjwatson> xnox: the code is authoritative :-)
<xnox> the warning text is misleading though =)
<cjwatson> xnox: sod the warning text, the limit is wrong
<xnox> cjwatson: well, I either have no access or don't know where it is =)
<cjwatson> lp:ubuntu-cdimage
<xnox> ah, ok.
 * ogra_ still hasnt got his head arund all that python stuff :)
<xnox> "This branch may be out of date, because Launchpad has not been able to access it since 2012-08-17."
<cjwatson> lib/cdimage/tree.py:DailyTreePublisher.size_limit in this case
<cjwatson> oh damn
<cjwatson> well you're out of luck until I switch it to fully hosted, sorry
<cjwatson> take my word for it for the moment :)
<jamespage> Daviey, actually hold fire - its in the queue twice - I think SpamapS may have already done this
<xnox> cjwatson: the code is authoritative :-)
<ogra_> lol
 * xnox "a wise man taught me that"
<cjwatson> http://paste.ubuntu.com/1224250/ then
<cjwatson> I mean, it has 800000000 there
<cjwatson> but that obviously isn't working
<ogra_> nah, you could just have made that up in pastebin *g*
<Daviey> jamespage: SpamapS's seem to include an additional fix?
<cjwatson> I'll look at it when I have a chance ...
<cjwatson> oh, wait
<cjwatson> my apologies, I'm completely wrong, I was misled by the units on cdimage.ubuntu.com
<cjwatson> ok, yeah, in that case we *do* need to do something about the oversizedness and you're right it's just the warning text
<cjwatson> sigh.  coffee.
<Laney> what did we decide the limit was?
<cjwatson> 800MB (decimal)
<Laney> then yeah
<cjwatson> though I wonder if that should be 800 * 1024 * 1000 * 1000
<cjwatson> err, 800 * 1024 * 1000
<jamespage> Daviey, yes he did - but he also did not do the python-ceph linux-any -> all change
<cjwatson> since that's what "decimal" MB usually means
 * jamespage scratches his head
<Laney> You have: 800 MB
<Laney> You want: bytes * 8e+08
<Laney> that pasted well
<cjwatson> But decimal MB per disk manufacturers usually means 1000s of KiB
<cjwatson> Because the world sucks
<Daviey> jamespage: but why did you do that change?
<jamespage> Daviey, didrocks and I discussed it after the last set of MIR actions
<cjwatson> slangasek: ^- should we bump the size limit to 800 * 1000 * 1024, do you think?
<xnox> we agreed on a number 800 but not the units.... *sigh*
<Daviey> jamespage: did he say why
<Daviey> jamespage: It seems an odd request..
<jamespage> Daviey, the package has no specific architecture requirements in Ubuntu
<cjwatson> hmm, https://en.wikipedia.org/wiki/Megabyte alleges that disks are actually pure powers of 10
<cjwatson> not sure that matches my experience but maybe I can't be bothered to check now
<xnox> cjwatson: I'm guessing what matters is that we fit on the common 1GB usb-sticks when unpacked using usb-creator.
<jamespage> Daviey, suggest that you reject my upload and I'll catchup with SpamapS when he starts later today
<Daviey> jamespage: considering we only release linux.. linux-any == any.. So i'm suprised it was made a fuss.
<xnox> cjwatson: as we target typical media sizes, not numbers.
<jamespage> Daviey, it was not 'fuss' - it was a suggestion for when it was next uploaded...
<Daviey> jamespage: ah, ok.
<Daviey> Did someone else just reject that?
<cjwatson> xnox: not that simple because the 800MB was known to be an artificial target for the purposes of controlling the rate of bloat
<cjwatson> Anyway, easy fix is drop a langpack from amd64
<cjwatson> I'm doing that now
<Daviey> who did that? ^
<xnox> cjwatson: yeah, cause "disk manufacturers" 1GB gives me 953.6 MB
<cjwatson> Daviey: a phantom queuebot bug - it's still in unapproved
<Daviey> cjwatson: no, it was uploaded twice
<cjwatson> oh
<Daviey> cjwatson: I just tried to reject, and was told it was already rejected by LP.
 * cjwatson accepts alsa-tools to give the publisher something to do along with his seed change
<xnox> cjwatson: \0/
<xnox> when do we start milestone images publishing?
<xnox> Today or Tuesday?
<Laney> when we get a Conrad
<xnox> Laney: I see.
 * xnox off to do a quick ubiquity upload then.....
<Laney> ...
 * xnox is only trying to annoy Laney =)
<Laney> it's all good fun eh
<xnox> Laney: it's to fix top errors.ubuntu.com crasher
<xnox> bug 1027648
<ubot2> Launchpad bug 1027648 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file." [High,Confirmed] https://launchpad.net/bugs/1027648
<Laney> great
<Laney> let's see it!
<xnox> https://code.launchpad.net/~xnox/ubiquity/fix-value-errors/+merge/123727
<Laney> I mean in the queue :P
 * xnox mutters something incomprehensible in Russian and mentions Laney three times
 * Laney assumes that they are nice words
<cjwatson> any chance we could get the yaboot-installer fix in the queue, if we're respinning for ubiquity anyway?
<cjwatson> not mandatory but might help the powerpc folks
 * xnox waits
<Laney> I'll look after lunch
<Laney> at both
<Laney> unless someone else gets there first
<xnox> Laney: cause yaboot needs to be included in the ubiquity upload.....
<Laney> oh, like that is it?
<xnox> Laney: due to the funny way we repackage udebs in ubiquity.
<Laney> fine, sessioninstaller can wait
<cjwatson> well, yaboot-installer does, not yaboot
<cjwatson> xnox: I tried having the udeb-producing source packages also spit out debs, and it was indescribably painful to maintain so I stopped :-)
<cjwatson> believe me this sucks less
<ogra_> ls ../
<ogra_> bah
<xnox> cjwatson: I totally agree. And Build-using: X is also path to fail.
<cjwatson> Build-Using is only useful if you can get the binaries in a useful way
<xnox> cjwatson: Build-Using should get you `apt-get source $pkgs` unpacked as tarball components. And auto-substitute the version numbers in the control file. Otherwise it's just dfsg metadata hack on top of the real problem: cannot build-dep on a source package instead of binary package.
<xnox> which totally makes sense for all the toolchains and compilers we have in the archive.
<cjwatson> I don't agree
<cjwatson> It's useful to have a way to tell the archive "don't garbage-collect this source"
<Laney> accepted, to lunch
<cjwatson> Build-deps wouldn't help for that
<xnox> Laney: thanks.
<xnox> cjwatson: ok. I only think with "i want to bootstrap a new arch" hat, cause I don't have "archive admin" hat yet ;-)
<jamespage> ^^ buddycloud-server was (hopefully) the last sync with Debian due to the node -> nodejs binary name migration
<mterry> ^ that's the last bit of the webapps feature story
<jbicha> so even when we get webapps working for quantal, it'll just be fancy bookmarks since we're not doing any chromeless mode?
<mterry> jbicha, fancy bookmarks, sure.  That can tell when they are open
<mterry> I did not want to advocate for them squeezing in more features  :)
<jbicha> it just doesn't seem very useful yet, especially since we have the shopping integration in the dash home & the music lens
<Laney> so, one of these packages is the one that gives us the new launcher webapp icons?
<jbicha> & the feature still has the disappearing/duplicate icons problem
<mterry> Laney, new launcher webapp icons are in unity-webapps-common.  They are added to launcher by default by unity, if they are present.  The recent ubuntu-meta update just puts the packages in the image
<mterry> jbicha, U1 is still a server side fix coming
<jbicha> mterry: are the 2 Amazon launchers & 2 U1MusicStore launchers in the dash known yet
<mterry> jbicha, amazon should only have one icon at a time, but it does hide and reappear
<mterry> jbicha, they are working on a fix for that
<mterry> jbicha, and U1 team is working on theirs
<mterry> jbicha, but yeah, for a feature that will cause more commercialization concerns, I wish it at least worked flawlessly  :-/
<stgraber> cjwatson: jbicha just noticed that gcompris somehow got into the ubuntu-desktop packageset when it's a universe package only seeded in edubuntu and was in the edubuntu packageset for 12.04. Any idea of what happened there?
<cjwatson> good question ...
<ogra_> it moved secretly to restricted ? :P
<ogra_> ah, no, that would have just ignored it
<cjwatson> hmm, probably something to do with the weirdness around Edubuntu DVD seeding
<cjwatson> Let me see if that can go away nowadays
<xnox> Laney: ubiquity ^^^ =) to go with yaboot and webapps stuff
<Laney> great
<cjwatson> I'd like to do the accept on that if you don't mind
<cjwatson> as a test case for process-accepted-bugs-job
<Laney> go for it
<skaet> olli, mterry, popey - what is the status with the fix to libunity-webapps?    Is there anything ready to be tried?
<mterry> skaet, no.  Are you talking about the Amazon launcher?
<olli> skaet, the bamf/window management issues seems to be resolved
<skaet> mterry,  no window management/missing appmenu function.
<skaet> olli,  great.   has something been uploaded?   if so, details please.
<Laney> err
<Laney> those launchers are literally just opening tabs in my browser
<cjwatson> process-accepted-bugs-job: hooray, glorious success
<Laney> is that right?
<mterry> Laney, the chromeless mode got dropped for time reasons
<Laney> I was under the impression it would still be a separate firefox window
<mterry> Laney, so yeah, they open tabs, and are supposed to reflect the open/closed status of the tab
<cjwatson> bug 745799 should no longer be an issue through this freeze; assuming that holds, I'll remove all the obsolete code and close that bug on Friday
<ubot2> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,In progress] https://launchpad.net/bugs/745799
<cjwatson> or thereabouts
<mterry> Laney, that was the grand vision, and will be in 13.04
<Laney> OK I could "quit" it
<olli> skaet, I don't know what resolved it, asked here yday - I have libunity-webapps0-2.3.8-0ubuntu2 which provides the missing *so.0, but the changelog doesn't hint at any update
<olli> I was not able to verify what happened
<Laney> ... would it be controversial to suggest delaying installing this by default?
<olli> happened as in what fixed what I was seeing (I did an update/upgrade)
<skaet> olli,  would like make sure we've got fix firmly identified, so we don't get "surprised" later.   I'll update my broken system and let you know what I find.
<Laney> hmm.
<olli> skaet, willcooke will get in touch with you
<Laney> cjwatson: nice one
<skaet> olli,  have applied the latest updates,  rebooted machine.   No change in behaviour,  still no menus.
 * skaet working with willcooke now
<popey> skaet, does a "sudo apt-get install ubuntu-desktop^" (with the hat) pull any missing bits in?
<skaet> popey,  yes.   libunity-webapps0 is in that set (with some others)
<popey> thats the issue then, something didn't come in or something was removed previously
<jbicha> Laney: I'd prefer it wait for 13.04 but I'm of course not RT
<plars> mvo: psivaa was just asking me about https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1052605 - is this a problem that really needs to be fixed in precise, for upgrade purposes, or is it strictly quantal?
<ubot2> Launchpad bug 1052605 in update-manager "ERROR:root:getListFromFile: no '/usr/share/update-manager/removal_blacklist.cfg' found: exception during Precise to Quantal upgrade on amd64+mac" [High,Confirmed]
<xnox> jbicha: http://www.flickr.com/photos/diegoe/4843409030/
<xnox> http://blogs.gnome.org/diegoe/2010/07/30/annual-gnome-soviets-meeting/
<mvo> plars: quantal is fine I think, but I will double check - in a meeting right now
<cjwatson> plars: FWIW the way it works is that we can fix a lot of upgrade bugs of this type just in quantal, because the release upgrader downloads a tarball of upgrade code from quantal as one of the early things it doe
<cjwatson> *does
<skaet> popey, applied, reboot has menus and proper behaviour again.   Thanks.
<skaet> iulian ^ if your system is also still affected....
<plars> cjwatson: interesting, do you consider this one critical enough to make a target of opportunity? If it's not a regression, I would think the answer is normally "no", correct?
<popey> skaet, yay.. cc: olli ^^
<cjwatson> the question of regressions makes less sense for upgrades
<cjwatson> and I thought I already made it a target of opportunity by accepting the rls-q-incoming nomination :)
<Laney> didrocks: I don't see any sign of the upstream changes in overlay-scrollbar?
<didrocks> Laney: really? the previous upload was a native upload, which was wrong, I did a tarball of it and merge-upstream it, let me check
<Laney> didrocks: https://launchpadlibrarian.net/117169400/overlay-scrollbar_0.2.16%2Br353-0ubuntu2_0.2.16%2Br356-0ubuntu1.diff.gz
<Laney> I see the same when diffing the unpacked source packages manually, just to be sure
<didrocks> Laney: but, the upstream changes are in 0.2.16+r356 tarball normally
<didrocks> Laney: let me check
<didrocks> Laney: maybe the +rev353 naming was wrong
<didrocks> Laney: yeah, so they were backported, confirmed in -0ubuntu2
<jdstrand> skaet: hey, so what is the status of getting a bug fix into beta2 right now? I have a fix for ufw (would affect all images). It probably isn't worthy of a respin on its own, but would be nice to have fixed since it contains a fix for a bug found during iso testing
<didrocks> Laney: but at least, now, we have a real package with an upstream tarball and packaging change separated
<jdstrand> (iso testing from last time)
<didrocks> Laney: which wasn't the case before
<Laney> didrocks: OK, fair enough, thanks for looking
<didrocks> Laney: thanks for checking :)
<Laney> we should have it for the Qt fix anyhow
<didrocks> Laney: yeah, not sure if you want it for beta2 proper
<didrocks> Laney: or just upgrade it afterwards
<skaet> jdstrand,  we haven't started spinning the images yet,  so if its safe,  put it on the pad as an opportunity target and go ahead with upload.
<jdstrand> skaet: it is low regression potential and passes QRT
<didrocks> confirming it's fixing/workarounding the issue
<Laney> i'll take it into proposed
<didrocks> sounds the safest :)
<jdstrand> skaet: ok. where is the pad?
<jdstrand> skaet: should this target quantal-proposed or just quantal? (it is a python package with only one build)
<skaet> http://pad.ubuntu.com/ubuntu-release
<jdstrand> skaet: thanks. added
<slangasek> cjwatson, xnox: we did agree on the units, we said 800MB. :)  There was a discussion on list where pitti found that the USB sticks he tested were pure decimal.
<cjwatson> OK
<slangasek> cjwatson: if we want to fudge to make powerpc fit though, it's not the end of the world
<xnox> slangasek: yes, 800MB apart from MB is ambiguous. Are we using "disk-manifacturer's" MB (aka decimal / base 10) or the computer science MB (aka base 2).
<xnox> slangasek: in other words can we define the sizes in bytes please =)
<slangasek> xnox: it's not ambiguous, we have a Units Policy. :)
<xnox> slangasek: yeah, thanks for reminding me about it.
<xnox> slangasek: cdimages.ubuntu.com does not compile with the Units Policy.
<xnox> slangasek: it uses M when it means Mi and it uses K which doesn't exist (should use Ki)
<xnox> ... or I got all of it backwards.
<xnox> http://cdimages.ubuntu.com/daily-live/current/
<cjwatson> slangasek: powerpc isn't currently oversized
<cjwatson> xnox: that's apache's fault and I haven't found a way to do anything about it
<cjwatson> P.S. the official hostname is cdimage.ubuntu.com
 * xnox blames chromium's auto remembering host names
<Laney> iulian: shotwell ^^^ is for you
<highvoltage> stgraber: unity is reaaaaly slow on edubuntu on kvm, is that normal and if so, something that should be release noted?
<stgraber> highvoltage: slower than on beta1?
<tumbleweed> highvoltage: does it at least work?
<highvoltage> stgraber, tumbleweed: yes
<stgraber> highvoltage: what's your screen resolution in the VM?
<stgraber> here it's pretty slow by default but that's because kvm is being weird and sets up the screen at 2360x1770 :)
<highvoltage> stgraber: 1024x768
<stgraber> hmm, weird. it's reasonably fast here once I get the resolution down to 1280x800
<highvoltage> I rebooted into installer only and that's at least a lot better
<stgraber> highvoltage: what video driver are you using in kvm and how much memory do you have allocated to the vm?
<stgraber> (but yeah, I think Ubuntu should issue a generic, Unity completely sucks in VMs, please use something else kind of warning)
<highvoltage> stgraber: cirrus 9mb with 1500MB RAM
<highvoltage> (I guess the 9mb video ram is the reason why I don't get a massive default resolution)
<stgraber> highvoltage: ok. I'm using vmvga 9MB, also with 1.5GB of RAM
<kenvandine> that unity-lens-photos upload is a trivial fix to a crasher that affects 103 people
 * xnox ... and me.
<Laney> exactly 103!
<Laney> :P /me looks
<Laney> skaet: Do you fancy considering the seed change?
<skaet> Laney,  fancy - no,  but if its fixing crashers, and is safe,  yeah,  rather it in now before we spin images.   Just don't want things to get worse though....
<Laney> It's not to fix crashers, it's to seed the packages which bring the webapp launchers in
<skaet> Laney,  ok,  yes.
<Laney> up to The Public to decide whether this makes things get worse :P
<Laney> done
<Laney> kenvandine: and yours, thanks for that
<kenvandine> thx
<Laney> there will be some promoting from -proposed to do before spinning
<Saviq> hey, re https://bugs.launchpad.net/ubuntu/+source/ubuntu-font-family-sources/+bug/1048600
<ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [High,Fix committed]
<Saviq> I've tracked the Qt bug down and worked around it https://bugs.launchpad.net/ubuntu-font-family/+bug/744812/comments/53
<ubot2> Launchpad bug 744812 in ubuntu-font-family-sources "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [High,Confirmed]
<Saviq> it's not a proper fix, 'cause that would break API, and requires work across backends and platforms
<Saviq> here's the patch https://launchpadlibrarian.net/117079074/fix_medium_font.diff
<Saviq> and packages are built in the mentioned PPA to test the impact
<stgraber> skaet: We might have a late edubuntu-live and edubuntu-netboot upload to change our default session on LTSP from Unity to gnome-classic (with fallback to gnome-fallback).
<cjwatson> I think I'm going to need to upload for bug 1054323 once I figure out what the problem is
<ubot2> Launchpad bug 1054323 in grub-installer "Installer fails at 'grub install dummy' on PowerEdge Hardware in EFI mode" [High,New] https://launchpad.net/bugs/1054323
<cjwatson> Quite possibly grub2 rather than grub-installer
<Laney> we should probably switch to making images for b2 ...
<stgraber> skaet: waiting to hear from highvoltage but considering how little progress the unity team has done on making it working in VMs, it doesn't seem likely we'll be able to ship with it in quantal
<skaet> stgraber, ack.
<Laney> stgraber: I'll proxy skaet and tell you to put it on the pad :P
 * skaet chuckles.   Thanks Laney ;)
<stgraber> Laney: yeah, will put a "no need to rebuild for now" note until we know what we'll be doing
<skaet> stgraber, is arm going to be available for edubuntu for beta2?
<stgraber> skaet: nope, ARM is staying daily-only for 12.10, we won't release it
<xnox> stgraber: to be honest all you need to do, is change blur effect to static & disable fade-in / fade-out. And all of those are just compiz settings.
<xnox> stgraber: I did that on my machine it's flying fast now.
<stgraber> xnox: well, unity doesn't start at all on LTSP, so no
<xnox> stgraber: ah
<stgraber> and unity explodes in interesting ways when using 16bit color depth
<tumbleweed> :)
<Laney> skaet: Shall we go ahead and change default_milestone and decron now?
<xnox> stgraber: i'd expected to expload in a rather dull way when using 16bit color depth
<stgraber> xnox: on 16bit: https://launchpadlibrarian.net/114128260/unity-16bit-quantal.png. It gets worse when you try to actually do something with it (like open a window) :)
<ogra_> use the door then :P
<ogra_> wow, modern art
<skaet> Laney,   please
<skaet> (and thanks!)
<Laney> skaet: it's alright, I've spotted infinity now :-)
<skaet> :)
<ogra_> cjwatson, is it normal that there is an amd64.squashfs file at http://cdimage.ubuntu.com/ubuntu-server/daily/current/ ?
<njin> bug 1048361
<ubot2> Launchpad bug 1048361 in ubiquity "installer stuck in download packages even if not connected or download not selected" [Undecided,Confirmed] https://launchpad.net/bugs/1048361
<cjwatson> ogra_: mm, I think probably a weird leftover - removed, thanks
<ogra_> cjwatson, so hggdh seems to still see bug 1054143
<ubot2> Launchpad bug 1054143 in debian-installer "armhf-omap4: Beta 20120924 server image fails to install with "no kernels found"" [High,New] https://launchpad.net/bugs/1054143
<ogra_> and comparing the .list files beween x86 and arm server images i dont see a pool on the arm side
<plars> xnox: regarding adding encrypted volumes at install time from ubiquity...
<plars> xnox: shouldn't I be able to do something with it after creating it?
<plars> xnox: oh, I see, I have to change it after creating it, and add the mountpoint then
<infinity> Laney: Did someone take my name in vain?
<hggdh> ogra_: and I confirmed it on bamboo-feeder and on a manual install
<ogra_> hggdh, yeah, something is weird with the images ...
<Laney> infinity: We wouldn't dare.
<ogra_> or infinity messed up d-i completely when bumping the ABIs :P
<Laney> I was going to do some nusakan twiddling, but then you showed up.
<infinity> ogra_: Seems unlikely.
<xnox> plars: if you are a casual user of debian-installer (netinst / alternate / server cds), you will find the current implementation very intuitive. As in, it's a tad disorientating.
<ogra_> thus the :P
<infinity> Laney: Feel free to twiddle what you were going to twiddle, if you were halfway there.
<Laney> no, I was 0%
<plars> xnox: heh
<infinity> Laney: Oh.  Well, thpt.
<xnox> plars: and somehow you should now upfront, that you are meant to create a separate /boot partition before creating the encrypted volume.
<xnox> s/now/know/
<plars> xnox: btw, I just got an error 141 from ubi-partman trying to remove an encrypted volume I had just created
<xnox> plars: hmmm.... =( shouldn't get 141, it should not let you do that in the first place. At least I did add guards against it. Please file a bug with steps to do it.
<Laney> infinity: I'll do it. It's just disabling cron and other similar things.
<plars> xnox: yes, doing that now... waiting on apport at the moment
<infinity> Laney: Sure, please do.  I'm tearing through queues and such.
<xnox> plars: what did you try to remove? The underlying partition, the ecrypted "disk" or the final filesystem?
<plars> xnox: the underlying partition
<xnox> plars: not good.
<xnox> plars: there are all sorts of guards missing, same as seen on panda boards with the sd-card. The installation medium is not properly guarded. The encrypted volumes / lvm make the discovery of unguarded partitions easier.
<Laney> there
<Laney> I'll not do any spins or such fun until the promotions are done
<infinity> So, I'm going to let the evolution 3.6.0 final stuff through, since it would be nice to see it heavily tested.
<Laney> sigh
<Laney> can we get overlay-scrollbar yanked from proposed please?
<Laney> it slays thunderbird
<infinity> Lovely.
<infinity> And can do.
<ogra_> ogra@anubis:~/Desktop/images$ mount-image-partition quantal-server-armhf+omap4.img 2 /mnt
<ogra_> ogra@anubis:~/Desktop/images$ find /mnt -name *kernel-image*
<ogra_> ogra@anubis:~/Desktop/images$
<infinity> Have you filed a bug and/or poked the appropriate people?
<ogra_> cjwatson, am i assuming right that this is wrong ?
<Laney> someone else commented on the bug
<Laney> I'll poke now
<ogra_> (i.e. there should be a kernel-image udevb in the pool, or not ?)
<ogra_> *udeb
<plars> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1055640
<ubot2> Launchpad bug 1055640 in ubiquity "ubi-partman error 141 when removing encrypted partition" [Undecided,New]
<highvoltage> ogra_: where is mount-image-partition from!?
<ogra_> highvoltage, my own script
<cjwatson> ogra_: I'm on a call
<ogra_> i have a bunch of image fiddling tools here
<cjwatson> I'll get back to you
<ogra_> thx
<skaet> infinity,  we may get a reverted kernel,  discussing with kernel team now.
<infinity> Laney: Removed.
<ogra_> highvoltage, http://paste.ubuntu.com/1224895/
<Laney> infinity: cheers
<highvoltage> thanks, ogra_!
<infinity> skaet: Kay.  Then I don't have to feel bad about letting in some userspace bits. :P
<cjwatson> ogra_: that test is certainly wrong though; I wouldn't normally expect to see *kernel-image* on images
<ogra_> cjwatson, hmm, where should i look for it then ? i thought it is in pool
<cjwatson> kernel-image is only for use when building d-i
<ogra_> oh, k
<cjwatson> no point in shipping the kernel-image udeb when we have a perfectly good kernel we booted with
<cjwatson> the bug as described there looks more like debconf template misplacement
<cjwatson> hm, no
<plars> xnox: is there a bug open already that you are aware of for the fact that the mount point dropdown is available, but greyed out on the create partition screen for that feature?
<ogra_> argh
<ogra_> http://paste.ubuntu.com/1224904/
<ogra_> not necessarily related, but definitely a bug as well
<cjwatson> well, maybe a bit excessive, but at least it has the kernel we want
<cjwatson> germinate has no subarch handling (and no obvious way to have it) so this kind of thing does tend to happen
<infinity> Ugh.  Why does gtkhtml have such restrictive shlibs? :/
<ogra_> well, in live-build we remove the supefluous headers as well, i guess debian-cd would need a similar hack to clean that up
<cjwatson> never mind for now though :)
<ogra_> nah, it wont fix my problem for sure :)
<cjwatson> any way to boot this under emulation?  I'd like to play around a little
<ogra_> only omap3
<cjwatson> alternatively if somebody could stick 'set -x' near the top of /var/lib/dpkg/info/live-installer.postinst for me and get a log ...
<hggdh> heh
<cjwatson> 'cos it looks as though arch_get_kernel_flavour isn't working right
<cjwatson> Oh, I'm an idiot
<cjwatson> Never mind
<cjwatson> I forgot to set SUBARCH
<cjwatson> Because I was clever and thought it wasn't needed
<ogra_> cjwatson, http://paste.ubuntu.com/1224911/ in case you want to play with omap3
<cjwatson> No need for now, but thanks
<infinity> SpamapS: Is your ancient lucid mysql SRU still wanted?  If so, can you and tumbleweed get together to make the queue have both SRU fixes in it?
<ogra_> cjwatson, geez, you are fast !
<cjwatson> Obvious once I saw it
<cjwatson> Would be nice if somebody fixed the lying .list files on ARM, mind
<ogra_> heh
<ogra_> yeah, added to my TODO already
<cjwatson> ta
<ogra_> it picks the wrong partiton
<xnox> plars: when you select "physical volume for encryption" the mount point should correctly become insensitive.
<xnox> plars: possibly I should hide it completely to avoid any daubt.
<cjwatson> as I think I said before I don't think we should hide it - that creates different confusion ("where did that disk space go?")
<cjwatson> not to say there aren't other UI possibilities
<xnox> plars: I couldn't quite implement the dialog as per design doc. In the design you can select all options in one go, including the mountpoint / fs for the encrypted fs.
<xnox> plars: but it didn't seem safe, that late in the cycle. Maybe next cycle.
<plars> xnox, skaet: sure, we need to make sure it's release noted though I think right?
<xnox> plars: release noted - what?
<SpamapS> infinity: yes I believe its still wanted. I'll check the status.. not sure why its been sitting so long
<cjwatson> ^- live-installer critical for arm server
<infinity> cjwatson: Yeah, looking already.
<xnox> plars: once the encrypted partition is setup there is no way to remove it. So as per your bug, I should fix and make sure it's not possible to remove that disk / partition.
<infinity> cjwatson: Hard to review the shell cut in there without knowing what archdetect returns, which I've entirely forgotten. :P
<xnox> plars: there are plenty of places where: ubiquity implementation != design doc.
<plars> xnox: I'm talking about the other issue - that the selection of mountpoint from the create an encrypted volume screen is unimplemented
<cjwatson> infinity: Those lines are copied from bootstrap-base.postinst, if that helps.
<cjwatson> It'll return things like armhf/omap4.
<infinity> cjwatson: Heh.
<infinity> cjwatson: Right, accepted then.
<plars> xnox: the option is there on the screen though, which is a bit confusing.  We can see what skaet thinks though
<infinity> (Based on the cut, not on the cargo-culting)
<cjwatson> Ta
<ogra_> hggdh, ^^^ your fix
<infinity> Tempted to reject gtkhtml, not because there's anything wrong with it, but because the moment someone accepts it, all its rdeps need to be rebuilt. :/
<Laney> Why /are/ the shlibs like that?
<infinity> Laney: I honestly don't know.  Perhaps to allow them to experiment with adding/dropping (especially the latter) symbols during a devel cycle?
<infinity> Laney: Since 4.5 is unstable and all.
<infinity> Laney: That's the only explanation I can come up with for the << part.
<Laney> Dunno. Reject it and speak to Robert
<infinity> Laney: Well, it can't be retroactively fixed.  A new upstream will break all the old packages regardless.
<Laney> there aren't very many rdeps anyway, if it turns out to be necessary
<infinity> Laney: The rebuild is necessary no matter what he does to the new shlibs.
<seb128> Laney, what package?
<Laney> gtkhtml4.0
<infinity> seb128: gtkhtml4.0
<infinity> seb128: The shlibs have a >> and <<, rather than just a >>
<Laney> I meant speak to him to find out if it's really necessary
<seb128> some GNOME components are like that
<seb128> did robert_ancell add those?
<infinity> seb128: He's just cargo-culting from previous versions, I suspect, so it's hard to tell who, if anyone, knows the rationale. :P
<infinity> -libgtkhtml-editor-4.0 0 libgtkhtml-editor-4.0-0 (>= 4.5), libgtkhtml-editor-4.0-0 (<< 4.6)
<infinity> +libgtkhtml-editor-4.0 0 libgtkhtml-editor-4.0-0 (>= 4.6), libgtkhtml-editor-4.0-0 (<< 4.8)
<infinity> Etc.
<infinity> Anyhow, the rdep list is tiny, if the buildds clear up a bit, I'll just accept gtkhtml and rebuild the few rdeps.
<plars> xnox: I also get an unusual warning when creating the encrypted partition, saying that no modifications can be made because it's in use as a physical volume for an encrypted volume (I didn't try to change anything though, I was just waiting for it to get created)
<infinity> But perhaps I'll reject it for now, and accept it from rejected later. :P
<seb128> Laney, infinity: my guess is that Debian did it because usually evo and gtkhtml need to be on a same serie
<infinity> seb128: That doesn't seem like a sane rationale from broken shlibs.
<infinity> s/from/for/
<infinity> seb128: Anyhow, it's also no huge deal, since almost nothing links to it.  We'll just do the rebuilds in a bit.
<seb128> where almost nothing is only evolution?
<infinity> I wish I'd noticed when I was processing the evo queue entries, though.
<infinity> Cause I could have done gtkhtml first. :/
<Laney> and "xiphos", whatever that is
<infinity> If evo had, I dunno, versioned build-deps, that would totally work.
<cjwatson> It's an operating system composed entirely of ogg codecs
<ogra_> LOL
<Laney> That sounds nice
<seb128> Laney, infinity: the shlibs is this way since added in Debian: http://anonscm.debian.org/viewvc/pkg-evolution?view=revision&revision=1192
<ogra_> but its a bible browser it seems
<cjwatson> ah, gnomesword as was
<seb128> Laney, infinity: I think it's because gtkhtml is no used out of evo and they handle it as a semi private lib, not bothering changing soname on abi changes
<seb128> they = upstream
<Laney> evo itself only appears to have a >= dep
<seb128> right
<infinity> Laney: ?
<Laney> in its autotooling
<seb128> the idea is to prevent updating gtkhtml to new_serie without updating evo
<Laney> It only asks for gtkhtml >= 4.5.2
<Laney> well, gtkhtml-4.0
<infinity> Laney: Oh, I thought you meant the package. :P
<infinity> (The binary package)
<Laney> Nein.
<Laney> And now, I'm going to purchase some delicious food for dinner
<Laney> tata
<infinity> seb128: It seems like a pretty annoying abuse of shlibs, but it's a big "I don't really care" given the rdep list is tiny.
<seb128> k
<seb128> Laney, enjoy, you made me hungry, I should think about dinner as well! ;-)
<infinity> seb128: That said, evo uploads could have versioned build-deps on gtkhtml, which would prevent what just happened.
<infinity> seb128: (Which is that evo uploaded and built against the old version JUST before the new version was considered)
<seb128> infinity, yeah, that looks like an error
<infinity> seb128: Well, they were *uploaded* in the right order, but upload and build aren't a guaranteed FIFO, unless you actually wait for the builds to be done and published. :P
<infinity> (And versioned build-deps would be entirely correct, if the intent is to keep them in lockstep)
<seb128> yeah, as said looks like a packaging overlook (the build-dep should have been bumped)
<infinity> Check.  Stopping talking now.  Not important enough to waste time on.
<seb128> (done)
<infinity> seb128: Maybe a new set up uploads with a versioned build-dep would be nice, so I can blat those through the queue when I decide to let gtkhtml4.0 out.
<infinity> s/set up/set of/
<infinity> I think I might need a big pot of Monday coffee.
<seb128> infinity, where uploads = evo with versionned build-dep?
<infinity> seb128: Yeahp.  And I think there might be a plugin too.
<infinity> evolution, evolution-rss, xiphos
<seb128> ok
<infinity> Those would be the three r-build-deps.
<seb128> I will get that uploaded for quantal-proposed
<seb128> so you can ack them when you feel like doing it
<infinity> Many thanks.
<infinity> You're me second favourite French developer.
<infinity> s/me/my/
<infinity> I also can't type.
<xnox> plars: it's unusual.... simply because there was no ecryptfs support in ubiquity before. It's a standard warning shown by d-i. And it is meant to tell you that you won't be able to modify the partitions.
<seb128> infinity, who is the first one?
<cjwatson> xnox: erm, I think you may mean no luks support?
<xnox> Laney: what about xiphos? =)))) xiphos is good.
<infinity> seb128: benh gives me free wine, you can't compete.
<cjwatson> we've had ecryptfs support for yonks
<xnox> cjwatson: yes, I do.
<seb128> infinity, I see, that's because I didn't bring you some smelling cheese at UDS
<infinity> seb128: :)
<cjwatson> I'm not convinced that that warning is usual, though.  Sounds like something being done out of order.  It's only supposed to happen if you try to modify the partition underlying an existing encrypted volume.
<cjwatson> But plars said he saw it when creating a new volume.
<xnox> cjwatson: d-i shows it when you activate encrypted volumes. always.
<xnox> cjwatson: I can silence it, and the fact that "remove/change" buttons are insensitive, should give the clue that you can't change these any more....
<cjwatson> Oh, is this partman-crypto/confirm?
 * cjwatson wishes people wouldn't paraphrase error messages, because it means I can't grep for them and have to guess.
<cjwatson> Or, well, messages.
<cjwatson> I thought you asked me whether to silence partman-crypto/confirm some days ago, and I said if and only if partman/confirm is silenced, and you said it was; so I assumed you had done that already.
<xnox> cjwatson: partman-crypto/confirm_nochanges
<cjwatson> Yeah, you asked about that too.
<cjwatson> 13:11 <xnox> cjwatson: partman-lvm|crypto|md like showing /confirm /confirm_nochanges /confirm_nooverwrite, should those warning be shown in manual partitioning or not?
<xnox> cjwatson: that is what I did. bug partman-*/confirm_nochanges where not silenced =)
<cjwatson> 13:15 <cjwatson> if and only if the corresponding ones for plain block devices are shown
<cjwatson> 13:20 <xnox> they are not.
<cjwatson> 13:20 <xnox> thanks.
 * xnox doh
<xnox> the confirm & confirm_nooverwrite are silenced across the board.
<xnox> the confirm_nochanges where not.
<xnox> and still are not. But maybe they should be, as part of crypt, lvm (upcomming) and raid.
<xnox> as these are the places where nochanges are used, and well the installation medium is the same as the disk.
 * xnox will think about it, and maybe reuse the warning on the top for these.
<plars> xnox: so, one of the things I'm trying to sort out here, and still struggling with, is how to create an encrypted swapspace. Would I need to create 2 separated encrypted volumes to do that? (one for swap, one for root)
<plars> If I try to create a normal swap area, then as soon as I create the encrypted volume I get an "Unsafe swap space detected" (Title not paraphrased) dialog box
<cjwatson> Bug 1054323 is beta-2-critical.  I'll fix it after dinner.  Doesn't require a ubiquity upload as ubiquity takes care of that bind-mount itself.
<xnox> plars: LUKS doesn't support partitions. So yes, you need to create two encrypted volumes.
<ubot2> Launchpad bug 1054323 in grub-installer "Server Installer fails at 'grub install dummy' in EFI mode" [High,In progress] https://launchpad.net/bugs/1054323
<plars> xnox: ok
<xnox> plars: this is until we have adv-lvm, cause then you will be able to create VG in the encrypted partition & create as many LVs as you need.
<plars> xnox: got it
<stgraber> skaet, infinity: 3 packages getting to the queue now for edubunty. edubuntu-live and edubuntu-netboot for bug 1055635 and arkose for bug 1055677 (nice to have that I just noticed and fixed)
<ubot2> Launchpad bug 1055635 in edubuntu-live "Enable gnome-fallback by default for LTSP Setups" [High,Confirmed] https://launchpad.net/bugs/1055635
<ubot2> Launchpad bug 1055677 in arkose "arkose crashes when uid 1000 doesn't exist" [Undecided,New] https://launchpad.net/bugs/1055677
<stgraber> I'll update the pad and approved the FFe for the gnome-fallback change
<stgraber> *approve
 * skaet --> lunch
<stgraber> cjwatson: hmm, looks like we have one more packageset weirdness ;) edubuntu-live should be in the edubuntu packageset, not ubuntu-desktop :)
<stgraber> cjwatson: and it looks like your refresh earlier dropped gcompris from ubuntu-desktop but didn't add it to edubuntu (that or I refreshed my report at the wrong time and it got fixed since)
 * infinity decides he might need some sort of breakfast or lunch or something.
<stgraber> would be great if someone could check the diffs for arkose, edubuntu-live and edubuntu-netboot. They should all be pretty trivial to review, except maybe for edubuntu-live that bundles a langpack refresh (easy enough to ignore though).
<infinity> stgraber: I'll get to them shortly.  None of it's wildly urgent (as far as images go), as we're waiting on a kernel now. :P
<stgraber> infinity: right
<stgraber> infinity: well, actually, I'd like to get edubuntu-live fairly soon to see if pkgbinarymangler (or whaterver strips the locales) does the right thing now as having a langpack installer that's not translated kind of sucks :)
<stgraber> and I'm not completely sure I did the right magic on LP to avoid the striping part of the process (and can't really test ...)
<infinity> stgraber: Did you actually change something?  The changelog claims that you're hoping LP won't strip.  Hope isn't actually enough to make it work. :P
<stgraber> infinity: yeah, I changed a setting in the LP template the "do not include in langpack" bit was set, I unset it
<stgraber> "include in langpack" I mean...
<stgraber> now I'm hoping that not being included in langpacks mean it won't strip it, that's the bit I'm not 100% sure about ;)
<infinity> Yeah, no.  Doesn't relate at all.
<infinity> It'll get stripped because the source is in main.
<infinity> Unless pitti's made pkgstriptranslations WAY smarter than it used to be.
<infinity> We could also blacklist it.
<stgraber> oh, why is that source in main?
<stgraber> bug 788671 apparently, checking
<ubot2> Launchpad bug 788671 in edubuntu-live "[MIR] edubuntu-live" [High,Fix released] https://launchpad.net/bugs/788671
<stgraber> ah, that bug in LP was fixed, I can easily get universe packages included in langpacks nowadays. I'll drop it from the seeds...
<infinity> Kay.  If you drop it from the seeds, I'll mangle the archive to demote it to universe.
<infinity> Which is less hassle than adding it to blakclists.
<stgraber> infinity: seed updated
<infinity> stgraber: Source demoted.
 * infinity wonders if he made the publisher cycle...
<stgraber> cjwatson: I guess that also explains why your script put it in the ubuntu-desktop packageset instead of the edubuntu one
<infinity> stgraber: I'm going to go find breakfast, and revisit this when I get back, assuming the archive's settled.
<highvoltage> I wish I could live in infinity's timezone for a bit.
<stgraber> infinity: ok, thanks
 * stgraber needs a "review all edubuntu hacks and replace them by something reasonable" work item for next cycle... remembering all these seeds/LP/cdimage/... hacks is getting difficult
<infinity> stgraber: Well, we just got rid of one. :P
<infinity> stgraber: You could just have a standing WI that's "every time you see crack, replace it with a better drug."
<highvoltage> stgraber: well they should be seperate work items for each hack, imho
<highvoltage> stgraber: I also want a work item to actually make work items for all my todo list items (and I guess yours too) so that we can actually try to get other people to do them
<stgraber> I guess 90% of them can be covered by "make the seeds reasonable and update cdimage to stop pretending edubuntu-dvd and edubuntu are different things"
<stgraber> that'd cure most of my edubuntu-related headaches
<highvoltage> stgraber: do we still get the unity-lens-shopping package in edubuntu? I think it should probably be removed if it's still there due to https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1054282
<ubot2> Launchpad bug 1054282 in unity-lens-shopping "No obvious way to restrict shopping suggestions from displaying adult products" [Undecided,Confirmed]
<stgraber> highvoltage: yes, we still inherit it from ubuntu-desktop and can't easily get rid of it for the same reason
<highvoltage> stgraber: I was afraid you'd say that
<stgraber> highvoltage: we can use our usual trick of adding a conflict on edubuntu-live, though that's one of those "hacks" I was talking about that we really should avoid (as it's making our live image different from a netboot/debootstrap image)
<stgraber> highvoltage: if you want me to kill that lens, please file a bug against edubuntu-live. I don't mind doing it but it needs to be documented and we really need to design a cleaner way of dealing with those packages starting with 13.04
<highvoltage> stgraber: yep
<stgraber> introducing a new edubuntu-desktop-blacklist package conflicting against these packages we don't want and being itself a recommend (not depend) of edubuntu-desktop, should do the trick. (As in, it'll prevent these packages from being installed on any edubuntu system but won't prevent the user from installing them later on)
<jbicha> ooh, that's an interesting trick
<highvoltage> jbicha: yeah, it doesn't do the trick completely though since it won't remove unwanted packages in the case where someone does a netinstall and chooses the Edubuntu task, or if somoene installs it from a minimal system
<stgraber> yeah, we're getting good at these ;) so far we're putting them all in edubuntu-live, that's a package only installed in the live environment so that lets us remove some packages without actually causing any post-install side effect, though that nice trick doesn't work with netboot/debootstrapped systems and so qualifies as a "ugly hack" :)
<stgraber> highvoltage: nope, the trick I proposed above will work with these cases. It's only our current implementation that doesn't.
<highvoltage> stgraber: https://bugs.launchpad.net/ubuntu/+source/edubuntu-live/+bug/1055705
<ubot2> Launchpad bug 1055705 in edubuntu-live "[UIFe] Please remove unity-lens-shopping package from Edubuntu installation" [Critical,Confirmed]
<stgraber> thanks
<stgraber> I'll reject my edubuntu-live upload then and re-upload with that one added
<highvoltage> stgraber: great
<seb128> highvoltage, Ubuntu hater ;-)
<stgraber> infinity: uploaded a new edubuntu-live including the conflict with unity-lens-shopping that was discussed earlier
<iulian> Laney: I cannot see shotwell in the queue. Did somebody accept it?
<hallyn> hi - qemu-kvm FTBFS in quantal on powerpc.  Should I upload the fix to quantal-proposed?  Or just wait until release?
<stgraber> hallyn: go ahead with the upload
<iulian> Laney: Apparently somebody already did that.
<hallyn> stgraber: to -proposed?
<iulian> Too bad that irclogs.u.c doesn't log the notices as well. It would've been easier to just grep the notices from queuebot.
<Laney> iulian: looks like it
<Laney> my money would be on infinity
<stgraber> hallyn: is qemu-kvm one of these packages that can create archive skew?
<stgraber> hallyn: I had a very quick look and saw a -common arch all package, so I assumed -proposed might make sense (didn't look at the exact dependencies though)
<hallyn> Daviey: bug 1054329, ping ?
<ubot2> Launchpad bug 1054329 in augeas "[FFE] Sync augeas 0.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1054329
<hallyn> Daviey: i ask bc if that'll be ack'd i'd rather push the fix for the other bug from friday (split lines in modprobe) just once against it :)
<hallyn> stgraber: ok, will push to -proposed, thanks.
<stgraber> hallyn: for bug 1054329, I'm interpreting Laney's comment as a +1 (no FFe needed, just bugfix, go ahead, but do a fakesync)
<ubot2> Launchpad bug 1054329 in augeas "[FFE] Sync augeas 0.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1054329
 * hallyn googles fakesync
<tumbleweed> hallyn: syncpackage can do it
<hallyn> tumbleweed: thanks, was just seeing https://wiki.edubuntu.org/fakesync which claims that as well.
<hallyn> but so what do i do about pushing it to -proposed?
<hallyn> oh, -d quantal-proposed?
<tumbleweed> syncpackge probably doesn't knwo how to do that
<hallyn> zounds
<tumbleweed> but it can produce the source package that you would upload, then you can change it :)
<hallyn> so use --no-lp (which manpage suggests might be done automatically)
<hallyn> thanks, trying
<Laney> it's easy to do manually too
<Laney> it's the debian .debian.tar.gz/.diff.gz/whatever, the Ubuntu .orig.tar.whatever and a fakesync changelog entry
<hallyn> makes sense.  i'm a bit afjeered though :)
<hallyn> syncpackage way seemed to work...
<Laney> yeah, but it's good to know what it does in my opinion
<hallyn> Laney: so (you commented) RT approval for FFE not needed for the augeas sync, but do i need a separate approval to push to quantal-proposed?
<Laney> no
<hallyn> Laney: agreed, and thanks, your descriptoin makes sense
<hallyn> cool, thanks.
<Laney> nps
<cjwatson> stgraber: I didn't notice my change earlier changing gcompris at all - it was just a refresh so that I had a consistent baseline
<cjwatson> or at least that's all I meant to do
<cjwatson> stgraber: main/universe shouldn't make any difference for ubuntu-desktop vs. edubuntu packagesets FWIW
<stgraber> cjwatson: my bad, was looking at desktop-core instead of ubuntu-desktop. gcompris indeed didn't move from there.
<seb128> ^ that one would be good to approve, the bug it fixes is a segfault with quite some duplicates coming daily
<stgraber> infinity: thanks! (assuming that ^ was you)
<infinity> It was.
 * infinity eyeballs that cups-pk-helper upload, and wonders if maybe there might be a missing include somewhere.
<Daviey> ogasawara: Is that kernel intended for Beta 2?
<ogasawara> Daviey: yes, we'd discussed with skaet and infinity earlier but in #ubuntu-kernel
 * skaet nods
<Daviey> There is nothing which suggests this is a respin trigger
<Daviey> But presumably all flavours will need a respin for this?
<skaet> yes.
 * cjwatson rushes to finish testing grub-installer
<Laney> there's no first spins yet :-)
<skaet> exactly ;)
<cjwatson> though I guess I have time while linux builds
<Daviey> Oh!
<Daviey> I thought i saw one.
<skaet> milestone's been set up,  but cron shouldn't be running ...
<cjwatson> quantal builds are indeed disabled in cron
<Daviey> ogasawara: I am right in saying this isn't an ABI toucher?
<ogasawara> Daviey: right, no ABI bump
<Daviey> superduper
<cjwatson> Does it need a d-i rebuild so that the new kernel is used in the installer?
<cjwatson> Hmm, looks like probably not
<Daviey> it's all graphics related.
<cjwatson> Well, it affects the console, but I don't think the installer has the i915 drm bits in it.
<cjwatson> So should be OK.
<cjwatson> ^- grub-installer critical for b2 server (UEFI), please review
<infinity> cjwatson: I'll review in a sec.
<cjwatson> ta
<skaet>  stgraber,  is there going to be an arm edubuntu image this time around?   if not,  can we remove it from the default path (so don't slow down on it during builds)
<stgraber> 16:16 < skaet> stgraber, is arm going to be available for edubuntu for beta2?
<stgraber> 16:17 < stgraber> skaet: nope, ARM is staying daily-only for 12.10, we won't release it
<stgraber> so yeah, can be removed from the build commands
<skaet> thanks stgraber,  sorry,  missed it in the backscroll.
<skaet> infinity, ^
<phillw> stgraber: are the ARM guys thinking that there will be a lubuntu release? (Just so I can let my boss know :P )
<stgraber> phillw: The choice to build for a specific architecture or not is up to the flavour leads, though at this point, if lubuntu never had an arm release, it's too late to make one for 12.10.
<phillw> stgraber: just that is has sat there on the daily bullds ever since they asked permission to have one.
<stgraber> looks like lubuntu had a temporary ac100 image built, probably because ubuntu wasn't quite working on it at the time
<skaet> infinity, can you score up the linux build so we know it goes into the next armel and powerpc slots?
<stgraber> but it hasn't been built for the past 3 weeks
<stgraber> ogra_: can you comment on lubuntu armhf ac100 desktop pre-install? is that still useful/built or can I flush it from the tracker?
<phillw> afaik, they have confirmed it as installing, but whilst julien (gilir) did give permission, it is up to the ARM guys to test. They needed a low RAM system for some kit & chose lubuntu.
<stgraber> yeah, that was a temporary thing for the ac100 IIRC, as it wasn't built recently, my guess is that it's no longer needed, but ogra should be able to confirm that
<phillw> we are happy to have them, after all, lubuntu is for low-resource machines.
<phillw> well, if you can check. We have no objections.
<slangasek> stgraber: Ubuntu is not and will not be working on ac100; I don't know why the lubuntu image build has been stopped
<slangasek> Ubuntu desktop works on armhf only if we have binary drivers, and AFAIK there are none in the archive for ac100
<infinity> stgraber: We switched ac100 from ubuntu *to* lubuntu, nothing temporary about it.
<stgraber> slangasek: ok, that makes sense. That's unfortunate that we still don't have a tegra2 blob packaged (or that we can distribute, not sure which is the issue)
<stgraber> infinity: ok, so someone should look into fixing the build or maybe just tweak default-arches so that it actually builds (haven't looked into it besides reading phillw's comment above)
<infinity> stgraber: We occasionally have them, and occasionaly not, but we can't rely on having one that work at any given point.
<infinity> s/work/works/
<infinity> stgraber: It's in default-arches.  It might not be in cron...
<infinity> Oh, no, there it is.
<cjwatson> Shouldn't need to be in cron if it's in default-arches ...
<infinity> #35 1 * * *	buildlive lubuntu daily-preinstalled && for-project lubuntu cron.daily-preinstalled
<cjwatson> Well, the whole flavour does, sure
<infinity> Yeah. :P
<stgraber> hmm, then maybe it's just the cdimage => tracker magic that needs tweaking
 * stgraber has a look
<infinity> Given that said subarch is the only thing that builds for that flavour.
<phillw> guys, please do not shoot the messenger, lubuntu were asked to hold a low RAM version or ARM. The last thing i want is for a fight :'(
<infinity> phillw: There's no fighting.
<stgraber> No iso.qa.ubuntu.com product found for lubuntu/daily-preinstalled/quantal-preinstalled-desktop-armhf+ac100; skipping.
<infinity> stgraber: http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/ <-- Implies it's been building recently, so it could just be the tracker magic.
<stgraber> so post-qa doesn't know what to do, that's the problem
 * stgraber fixes
<cjwatson> phillw: Please don't confuse debate about why it isn't working with fighting!
<cjwatson> Yeah, looks like just tracker integration
<phillw> cjwatson: as a guy who does not have a ppc machine, I'm getting used to that area of releasing / maintaining different archs :D
<phillw> infinity: just by the way, did you manage to find the time to put the lubuntu iso's onto a diet?
<stgraber> ok, post-qa has been updated, next build should be posted properly
<infinity> phillw: Nope, can do a bit of that this afternoovening.
 * stgraber greps to check if anything else needs fixing
<stgraber> according to grep, the lubuntu ac100 image was the only one failing to post to the tracker, so looks like we're all good now (assuming my fix worked)
<phillw> infinity: as lubuntu is for low spec machines, having isos' at CD size really would help us.
<phillw> I'll take the flack off Julien (gilir) in his abscence.
<phillw> infinity: can you trip in just Lubuntu-PPC builds after your work? I'm hoping cjwatson has gotten the yaboot fix in via the ubiquity rebuild? Or am I really way off in my thoughts?
<cjwatson> yaboot-installer, not yaboot, but yeah, that fix was in ubiquity 2.12.3.
<cjwatson> Which has built everywhere.
<cjwatson> However since earlier conversation indicated there aren't any candidates yet, there's no point worrying about single-architecture respins right now.
<infinity> phillw: The whole world's getting rebuilt for shiny new kernels sometime anyway, probably no rush just yet to be doing one-offs, unless someone really wanted to test the yaboot thing RIGHT NOW.
<cjwatson> It'll get caught up in the rebuild of everything.
<infinity> cjwatson: Jinx, I guess I was being too verbose.
<phillw> infinity: I do actually pay attention :) I know you are awaiting a new kernel.
<phillw> cjwatson: is the ppc release at http://iso.qa.ubuntu.com/qatracker/milestones/238/builds of any use, or should I tell them not to waste time testing?
<Laney> not if you want that fix
 * Laney presses a butan
<phillw> Laney: can you or stgraber remove that suite, please?
<phillw> I will send an email out, but not all testers are on the mailing list.
<phillw> Laney: thanks :)
<Laney> dear old queuebot
<phillw> Well, 21:00 UTC has passed, do you guys have an ETA for the QA release of Beta 2?
<phillw> "Whenever", is not the answer :P QA are used to shortened test times. Any crumbs to tell the QA guys?
<infinity> phillw: After all the kernels are built and no one has another other last-minute critical bits that hold us up for another hour or three.
<infinity> phillw: Also, depends on people being around to press buttons (I have plans tonight, so I won't be)
<phillw> infinity: In the absence of skaet, can I reasonably ask testers to look at beta 2 in 12 hours time, or is that a time stamp still not being able to be confirmed?
<skaet> phillw,  yes,  that should be about right.
<infinity> phillw: Instead of saying "test something in 12 hours", you're better off just saying "test the next image".
 * skaet likes that better
<phillw> I know you guys on -release work to that last minute, but when can we ask to testers to come crawl over everything?
<infinity> Deadlines we can't meet just make everyone grumpy.
<phillw> infinity: I love the wooshing sound that deadlines make as they pass my ear :)
<phillw> you guys release the QA-Beta 2 when you are ready. and for that side of thinking... you will just have to trust me. The testers would rather hold back & then blast the QA release that piddle along with the dailies. You guys & Gals? Just make it work. And you always do.
<Laney> dpkg is so hideous on this machine
<Laney> I think I need to join team SSD
<xnox> plars: thanks a lot for your bug reports. Very useful. I will see how many I can fix.
<xnox> keep them comming ;-)
<skaet> infinity,  why did you accept the gst-* set?
 * skaet assumes it was you
<skaet> never mind
<skaet> seeing they're universe now.
<skaet> infinity,  the new build linux kernel (amd64) updated and loaded fine on my laptop.    We should be good to go when armel/armhf/powerpc finish building.
 * skaet --> dinner
<infinity> skaet: I know.
<skaet> k
<phillw> skaet: may I have a PM?
 * smartboyhw is also wondering what last-minute kernels can disrupt beta 2 build..
<cjwatson> smartboyhw: https://launchpad.net/ubuntu/+source/linux/3.5.0-15.23 has the bug references
#ubuntu-release 2012-09-25
<infinity> Right, then.  Out for the evening, will try to swing by to spin some images in ~6-7h, but if someone else notices the kernels are done and beats me to it, I won't complain.
 * skaet checks and sees armel/armhf/powerpc still building linux,  sigh.
 * phillw hides as skaet mentioned ppc and armhf which include lubuntu :/
 * skaet sees that linux has published on all architectures
<skaet> who just accepted glib2.0 to proposed?
 * skaet starting off image builds
<skaet> infinity, cjwatson - I've started off the image builds now for all the images on nusakan.    Should be emerging on the iso tracker as Beta 2.
 * skaet --> back to zzz
<infinity> skaet: glib2.0 in proposed is replacing one that was FTBFS on arm*.
 * infinity also decides to nap for a bit.
<ogra_> that flash-kernel upload above fixes a critical bug for arm images, please someone let it in
<ogra_> bug 1055938
<ubot2> Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Confirmed] https://launchpad.net/bugs/1055938
<Laney> ogra_: can you put it on the pad as respin trigger?
<ogra_> oh, yeah, sorry, forgot about it
<ogra_> added to the issues
<Laney> if you want respins then respin trigger is the place for it
<Laney> rebuild trigger
<ogra_> stgraber, lubuntu is the image for ac100 and it will stay like that
<ogra_> stgraber, so please keep it :)
<ogra_> done
<Laney> and mark the affected images?
<ogra_> hmm, which kubuntu arm images are there ?
<babyface_> are today's server isos under building?  it shoud be ready at UDT 7:00.
<Laney> yes
<Laney> they aren't on cron, so disregard any timing expectations you have
<Laney> usual milestone thing
<babyface_> Laney, ok. thanks.
<Laney> but I see them in progress
<babyface_> Laney, yes, I saw that, too. but it costs too much than usual
<babyface_> [2012-09-25 06:46:33] lb_testroot
<babyface_> P: Begin unmounting /dev/pts...
<babyface_> P: Begin unmounting filesystems...
<babyface_> P: Saving caches...
<babyface_> Reading package lists...
<babyface_> Building dependency tree...
<cjwatson> *costs* too much?
<babyface_> cjwatson, yes, normally they should be ready at UTC 7:00
<ogra_> $3.23/byte ?
<cjwatson> if you mean takes too long - around milestones we're building lots of things together, so you can expect some queueing
<cjwatson> babyface_: as Laney said, they are not being built from cron today, but manually, so forget your timing expectations
<babyface_> cjwatson, ah, ok. thanks
<cjwatson> and there we go.  patience is a virtue. :)
<ogra_> hah
<babyface_> cjwatson, thanks.
 * Laney 's ISP has decided that alioth isn't a service he needs access to today
<cjwatson> xnox: oh, we were talking about partman-crypto/confirm_nochanges the other day in response to plars' report, but that's *not* what he reports in bug 1055819
<ubot2> Launchpad bug 1055819 in ubiquity "'Partition in use' error when creating encrypted volumes" [Medium,Confirmed] https://launchpad.net/bugs/1055819
<cjwatson> and that sounds more like what I originally understood him to mean
<cjwatson> xnox: that indicates an attempt to modify the partition while locked (partman-base/partlocked with partman-crypto/text/in_use substituted in) and indicates a logic error somewhere, not just a warning that should be silenced
<cjwatson> xnox: perhaps we're trying to traverse into locked partitions while building the cache or something?
<xnox> partman-base/partlocked
<xnox> hmm....
<xnox> i have logs open currently let me see.
<xnox> cjwatson: yes, we do hit that upon rebuilding the cache. And I do store the 'partlocked' flag in the cache when it does, to later correctly set all action buttons insensitive on that partition. But I still fall through to showing the error dialog.
<cjwatson> It should be possible to check for lockedness without having to hit the error
<cjwatson> Look for the presence of a 'locked' file in the relevant partition directory under /var/lib/partman
<cjwatson> Likewise for disks
<cjwatson> I think in this case it's better to have a look-before-you-leap pattern, so that we don't accidentally silence *un*expected errors
<cjwatson> Plus, it'll be quicker
<xnox> Ok. "Likewise for disks" - is there an easy way to get a locked disk? installation medium?
<cjwatson> (Traversing takes noticeable time, anything you can do to minimise it will make the partitioner snappier - compare https://wiki.ubuntu.com/Ubiquity/PartitionerOptimisation)
<cjwatson> disks> presence of a 'locked' file under the device directory in /var/lib/partman
<cjwatson> installation medium is handled separately IIRC
<xnox> ok.
<xnox> cjwatson: what's the best way to detect that "partition" is in fact the acting_filesystem within encrypted volume. (i) Filter on the name '*crypt' (ii) transverse to disk -> crypt_realdev -> locked status (iii) something else?
<xnox> to mark "remove partition" button insensitive, as it's not possible to remove it.
<xnox> (well partman doesn't support removing it from that menu)
<cjwatson> I'd be inclined to suggest looking up the logic that partman-crypto itself uses and mimicking it.
<xnox> ok. i will check that.
<cjwatson> You could fish out the crypt_realdev file without actually having to traverse to that partition in debconf.
<xnox> true.
<cjwatson> So something like that's probably the best way.
<xnox> well, as I'd add crypt_realdev to the diskcache, it will be simply dict lookups.
<cjwatson> Quite.
<cjwatson> ^- would be good if somebody could process that, as there are scattered reports of failures on precise systems with the new dual-signed index files
<xnox> ha. partman-partitioning disables resize & delete if the device labe is == 'loop' nice and generic
<Riddell> settings bug 1055967 to critical, ubiquity can't start :(
<ubot2> Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967
<cjwatson> are you able to work on a fix?
<Riddell> I don't think I know where to start, I'm just poking about randomly
<Riddell> mdeslaur_: presumably you'd object to reverting that dbus change?
<mdeslaur_> Riddell: uhm, yes. Either start the bus yourself, or don't make whatever is trying to start it setuid
<cjwatson> ubiquity has to go to some contortions for this kind of thing because it's not fully frontend/backend-separated, but mostly I don't care because it's the installer damnit
<cjwatson> But we do call os.setgid and os.setuid when calling dbus-launch, if I'm looking in the right place (which isn't clear)
<cjwatson> Does dbus object to the presence of a saved-user-ID?
<mdeslaur> cjwatson: yes, it does:
<mdeslaur> ++      is_setuid = (ruid != euid || ruid != suid ||
<mdeslaur> ++                   rgid != egid || rgid != sgid);
<cjwatson> Apparently so, yeah
<Riddell> the CVE says "NOTE: libdbus maintainers state that this is a vulnerability in the applications that do not cleanse environment variables, not in libdbus itself"
<cjwatson> Riddell: entirely untested, but maybe try http://paste.ubuntu.com/1226425/
<cjwatson> popey: so this precise unity SRU consists of nux + unity + unity-2d, right?
<mdeslaur> Riddell: they said that, and then decided that the best fix would be in libdbus itself
<mdeslaur> Riddell: this is an upstream patch, if you don't fix it now, you'll have to fix it soon when the new dbus hits
<Riddell> cjwatson: making a USB disk with persistent storage so I can test that
<mdeslaur> cjwatson, Riddell: sorry for the inconvenience, I wasn't expecting this to be problematic
<cjwatson> I would prefer to fix this without reverting, of course, but we also do have a release to get out - on Thursday, not whenever the next upstream release of dbus hits
<Laney> heh
<Laney> I was just wondering where those were
<popey> cjwatson, yes, hang fire, needs some additional testing on ARM, should I revert back to verification-needed?
<cjwatson> popey: Yes
<popey> cjwatson, all of them?
<cjwatson> No need for that
<popey> ok, ta
<Riddell> cjwatson: hmm that just leaves me with a black screen (X running but nothing on top of it)
<cjwatson> Riddell: /var/log/installer/dm might help?
<Riddell> cjwatson: nothing much in that, just initializing extensions and finishes with Loading extension GLX
<skaet> Riddell,  can you give me more background on what you're seeing/which image, etc.    I'm seeing Ubuntu and Lubuntu on the ISO tracker have results so not sure if its a pervasive issues or not.
<skaet> ?
<Riddell> skaet: it only affects the kde frontend of ubiquity
<skaet> Thanks Riddell.
<cjwatson> Which is actually kind of curious since I thought we ran dbus-launch for all frontends.
<cjwatson> Maybe it matters less elsewhere.
<Riddell> the same problem occurs when running ubiquity from a the full live session
<Laney> can we have gtk+2.0 copied to release?
<Laney> I'd like to accept the one in proposed
<skaet> Laney,   scope of impact?
<Laney> well, the fix is for something in the printer dialog
<Laney> opportunity target if you want to think of it like that
<Laney> the one I'd accept is to fix overlay scrollbars for Qt applications
<skaet> bug #?
<Laney> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1053891 fixed with the copy to release
<ubot2> Launchpad bug 1053891 in gtk+2.0 "GTK print dialog does not allow printing and does not show options of a remote DNS-SD/Bonjour printer" [High,Fix committed]
<Laney> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1005677 fixed with the accepts
<ubot2> Launchpad bug 1005677 in ayatana-scrollbar "Re-emergence of "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)'" Makes vlc and other Qt apps crashing crashing" [High,In progress]
<Laney> I'll reupload overlay-scrollbar with -v to close the bug
<skaet> Laney,  ack,  have added them both to the pad then.
<Laney> I never know if I'm allowed to do copies myself
<xnox> I have a couple of ubiquity bugfixes for advanced-crypto. From my point of view they are opportunity targets if all desktop cds with gtk ubiquity are respun.
<xnox> bug 1055819
<ubot2> Launchpad bug 1055819 in ubiquity "Ubiquity should avoid partlocked error when rebuilding disk cache" [High,Fix committed] https://launchpad.net/bugs/1055819
<xnox> bug 1055815
<ubot2> Launchpad bug 1055815 in ubiquity "No mountpoint option when manually partitioning with encrypted volumes" [Medium,Fix committed] https://launchpad.net/bugs/1055815
<xnox> bug 1055640
<ubot2> Launchpad bug 1055640 in ubiquity "ubi-partman error 141 when removing encrypted partition" [High,Fix committed] https://launchpad.net/bugs/1055640
<xnox> none of these are marked as critical. all of them are in lp:ubiquity.
<xnox> Add to the pad? Which section?
<Laney> upload, add to opportunity targets and then mark the affected images with your numbe
<Laney> r
<xnox> Laney: what about the Kubuntu's live session / ubiquity-dm not starting at all?
<Laney> what about it?
<Laney> is there a fix?
<xnox> wait for that as well, or upload as is, and reupload if that one gets added.
<xnox> no, not yet.
<Laney> is there likely to be one quite soon?
 * xnox is not working on it. Riddell, any news / progress?
<skaet> xnox,  what Laney said.  :)
<Riddelll> I'm poking at various things but I doubt I have any real ideas how to progress it
<Laney> it's not like ubiquity takes hours and hours to build
<Laney> might as well upload and then upload again if necessary IMHO
<skaet> have all the necessary bits for arm landed?   We need to respin those to get the images and testing infrastructure usuable for them.
<Laney> was just flash-kernel AFAIK, so yes
<skaet> there was also the glib2.0 that adam uploaded last night to fix FTBFS
 * skaet nudges infinity to remember to update the pad, when he lands things. :P
<Laney> I don't see evidence of that
<cjwatson> he didn't upload anything.  he accepted an upload to quantal-proposed.
<cjwatson> which is still building anyway.
<Laney> yeah
<skaet> Laney,  http://irclogs.ubuntu.com/2012/09/25/%23ubuntu-release.html#t06:33
<cjwatson> yep, which says he accepted it, not uploaded
<cjwatson> anyway, it only needs to be on the pad if it's intended to land in quantal pre-b2
<skaet> yeah,  corrected.
<cjwatson> which amounts to a question of whether it's problematic for ARM not to have the changes in https://launchpad.net/ubuntu/+source/glib2.0/2.33.14-1; it hasn't resulted in uninstallability
<skaet> yep,  jsut looking at it,  and looks like the fixes in it were from pitti to clean up some testing infrastructure,  so not critical I think.
<cyphermox> infinity: evo is now in the queue for the buil-dep change re: gtkhtml
<cjwatson> skaet: those are the post-2.33.14-1 changes
<Laney> they're all trying to resolve the FTBFS
<cjwatson> 2.33.14-1 was a new upstream
<Laney> which started with -1
<cjwatson> https://launchpad.net/ubuntu/+source/glib2.0/+changelog - ARM is currently on 2.33.12-3
 * skaet nods
<Laney> cjwatson: so can I copy gtk+2.0?
<Laney> In general can people copy stuff if it's all built and such?
<skaet> well,  its looking close to finishing at this point.   And it looks like the other architectures are on -14,  so wait for it to finish,  then copy?
<cjwatson> I would rather people didn't just copy at the moment
<skaet> since its still building?
<cjwatson> err, gtk+2.0 is built
<cjwatson> different packages
<cjwatson> but since we have another things we need to change on ARM anyway, seems sensible to take this one
<skaet> yeah,  cross wires on package names
<Laney> it's mainly because I want the fix in queue
<cjwatson> Laney: so go ahead, 'sru-release -r quantal gtk+2.0'
<Laney> ty
<Laney> do I need to wait for publisher or anything before accepting the new one?
<xnox> anything else for ubiquity? it picked up flash-kernel & grub-installer.
<cjwatson> Laney: new what wheree?
<cjwatson> *where
<Laney> new gtk+2.0 in queue
<cjwatson> no need to wait for the publisher
<cjwatson> xnox: not afaik - as said, if we find a fix for the KDE frontend we can reupload
<xnox> ok
<tumbleweed> why on earth is pbuilder-scripts aimed at the proposed pocket? (and do we really need more pbuilder wrappers?)
<Laney> I wonder if it still has those conflicts :(
 * Daviey questions the validity of doing uploads that simply add a Homepage to debian/changelog
<Daviey> err, control
<tumbleweed> Daviey: the point of those uploads is to give the uploaders a sense of achievement and show them how things work
<tumbleweed> of course they are pointless, otherwise
<Daviey> tumbleweed: How many of them until that task is complete ?
<tumbleweed> Daviey: it's endless :) (although I wish they'd do something vaguely more useful than missing home pages - spelling mistakes are more valuable)
 * xnox likes that suddenly spelling mistakes are welcome =)
<micahg> actually, Homepage uploads can be useful if there's no watch file
<micahg> as well as helping to upstream bugs and look for patches
<Laney> I'd rather a watch file upload
<xnox> watch file would be more useful though...
<Laney> or both
<xnox> with all spelling corrections....
<micahg> they're not mutually exclusive, maybe add a note to the bug fixing initiative to check for watch file as well as homepage
<tumbleweed> unfortunately, writing a watch file isn't as easy
<Daviey> tumbleweed: I disagree.. nearly all watch files are easy.. They only really become complicated if you need to repack IMO.
<jbicha> Home page does show up in Software Center so it's kind of useful to users
<tumbleweed> Daviey: you should tell me debian sponsorees that - it can take a lot of back and forth to get them to produce a working watch file
<Daviey> tumbleweed: I helped someone this week write a dfsg repack one.. It needed a few back and forth's.. The issue was they they didn't know how to test it.
<stgraber> skaet: who do I ping about the amazon and ubuntuonemusic launchers not being overideable through gsettings as I was promised they'd?
<stgraber> something seems to override the overrides at session open time, adding those launchers even when the system wide setting specifically disables them
<stgraber> the problem seems to be the session migration script being stupid and always adding them...
<skaet> popey,  ^  who should stgraber talk to.       stgraber,  best open a bug to track this.
<skaet> ?
<stgraber> skaet: well, I have a fix for it but that's going to be a unity-webapps-common upload, not an edubuntu-specific package
<stgraber> I'm not planning on waiting for the unity guys to fix their stuff this time around, I was told that the workaround we put in place would work, ...
<skaet> stgraber, ack.
<stgraber> skaet: popey isn't in this channel btw
 * skaet just noticed
<skaet> olli,   who should stgraber work with on this,  mterry?
<olli> skaet, stgraber, reading
<xnox> ubiquity added as opportunity trigger [16]
<Laney> neat
<stgraber> olli, didrocks: I'm going to upload http://paste.ubuntu.com/1226871/ in 30min unless someone comes up with something better.
<didrocks> stgraber: you should contact the webapps team, it's them who are responsible of the migration script
<didrocks> stgraber: didn't check as I didn't upload that package
<stgraber> didrocks: ok. I just filed bug 1056274 about it. My fix certainly works even if it's not a generic fix for the issue, so unless I get a reply on the bug with a better one, I'll just push that and they can always improve it after beta2 is out
<ubot2> Launchpad bug 1056274 in webapps-applications "Icons are getting added on Edubuntu systems even though we override the system wide key" [Undecided,New] https://launchpad.net/bugs/1056274
<stgraber> skaet: ^
<olli> stgraber, didrocks I asked alex-abreu to touch base with you
<alex-abreu1> stgraber: do you have a branch w/ the migration patch?
<stgraber> alex-abreu1: nope, but it's added to bug 1056274 and was briefly reviewed/discussed by mterry and kenvandine in #ubuntu-desktop
<ubot2> Launchpad bug 1056274 in webapps-applications "Icons are getting added on Edubuntu systems even though we override the system wide key" [Undecided,New] https://launchpad.net/bugs/1056274
<skaet> stgraber, ack.
<alex-abreu1> stgraber: ok for now, I'll work on a better fix upstream
<alex-abreu> stgraber: thank you
<stgraber> skaet: fix uploaded, should hit the queue in a few minutes
<skaet> stgraber,  ok.   I've updated the pad.   Respin Edubuntu as soon as it lands?
<Laney> might want to wait for ubiquity too
<skaet> infinity,  https://launchpadlibrarian.net/117296378/buildlog_ubuntu-quantal-armel.glib2.0_2.33.14-1ubuntu2_FAILEDTOBUILD.txt.gz
<skaet> looks like armhf is ok though now.
<stgraber> skaet: might as well wait for ubiquity
<skaet> stgraber, Laney, xnox -  does it make sense to wait for ubiquity for the arm respins as well?
<Laney> yeah, was doing
<stgraber> Laney: can you look at webapps-applications?
<xnox> skaet: yes.
<Laney> waiting for it to get diffy
 * Laney eyes the hplib diff
<Laney> hplip
<xnox> skaet: arm desktop images that is. Since ubiquity embeds flash-kernel with a bugfix.
<skaet> xnox,  k
<infinity> skaet: I wasn't the one that accepted glib.  Either way, didn't really need padding, I was watching it.
<Laney> someone want to score ubiquity/armel to make sure it gets in next?
<Laney> 2 builders ...
<stgraber> Laney: doing
<stgraber> done
<skaet> infinity,  hadn't seen you in channel this morning,  so leaving reference.
<Laney> ty
<Laney> webapps accepted
<Laney> possibly score that up too if you want it for respins
 * skaet really wants that queue logging.....  :P
<stgraber> will do
<stgraber> Laney: well, no need actually, it's arch all so it's already building
<Laney> oh, cool, didn't notice
<plars> skaet, didrocks, and anyone else interested: orca seems to quit reading after the welcome screen on ubiquity now, I'll have a bug# for you in a moment
<skaet> plars,  thanks.
<didrocks> plars: thanks, can you please assign Luke to it?
<plars> didrocks: will do
<didrocks> thanks ;)
 * cjwatson attempts to strace the kubuntu ubiquity-dm failure
<Riddelll> one workaround for the kde ubiquity issue is to change from a KApplication to a QApplication and just avoid much of dbus usage
<cjwatson> That's not a bad long-term solution, TBH; I've wanted to get rid of our reliance on pykde for ages
<cjwatson> But it probably has some UI effects so I'd like to figure out the underlying bug anyway ...
<cjwatson> http://people.canonical.com/~cjwatson/tmp/ubiquity-dm.trace.xz FWIW
<cjwatson> ah, I see, failure possibly not where I thought it was
<cjwatson> haha
<cjwatson>         # KApplication won't initialise if real UID != effective UID.  On
<cjwatson>         # the other hand, we can't talk to D-Bus unless the effective user
<cjwatson>         # is the live CD user.  Oh dear.  The solution is to use saved IDs:
<cjwatson>         # if we hide our rootliness in the saved IDs, then neither
<cjwatson> Apparently I documented this last time I fought with this stack ...
<cjwatson>         # KApplication nor D-Bus will spot it.
<cjwatson> And now the assumptions have changed
<cjwatson> So maybe QApplication is the right answer after all
<Riddelll> it's mostly calls to icon loading and one dialogue that need changed I think
<cjwatson> Riddelll: How big a change would that be to the UI and the code?  Do the other uses of kdeui (KMainWindow, KIcon, KMessageBox) need to change too?
<Riddelll> yes they do
<cjwatson> And KGuiItem
<Riddelll> but it's not too hard I think
<Riddelll> loading icons by path rather than name
<Riddelll> replacing the KMessageBox probably needs a few lines of extra code
<cjwatson> Riddelll: Any visible effect on UI?
<cjwatson> The stuff from the KApplication header doesn't seem *desperately* necessary
<Riddelll> here's my quick incomplete version http://starsky.19inch.net/~jr/tmp/kde_ui.py
<cjwatson> accelerators, common menu entries, KConfig, session management, help invocation
<Riddelll> yeah, we don't use most of that
<Riddelll> I need to go out for an hour or two, can tidy up that code once I'm back
<cjwatson> QtCore.KGuiItem and QtCore.KMessageBox presumably wrong :)
<Riddelll> I said it was incomplete :)
<cjwatson> OK - I think this is the right direction, just note you'll need to change ubi-usersetup too
<cjwatson> the use of kdeui has long been a pain so if we can ditch it at the same time then great
<skaet> ogra_, just to confirm,  you'll be testing ac100 on lubuntu again?
<skaet> infinity,  can you score up the powerpc build,  so we can get ubiquity built and coherent across the architectures,  and kick off the arm rebuilds.
<skaet> infinity,  never mind,  just saw it was done...
<cjwatson> Yeah, it's already scored up sufficiently that more won't make a difference.
<cjwatson> It's just waiting for active builds to complete.
 * skaet nods
<ogra_> skaet, as always, yes
<skaet> phillw, ^  ;)
<skaet> ogra_ ,  thanks.
<plars> skaet: is there a reason why there are no netboot images posted on isotracker yet?
<skaet> plars,  they need to be manually set,  and they appear to have been overlooked for setting up. :P   doing now.
<plars> skaet: upgrade is not there either
<skaet> plars,  should be sorted now.
<skaet> (netboot, and upgrades)
 * skaet sees ubiquity is now pending publication for powerpc...
<skaet> infinity, are you around to kick off the arm rebuilds?
<infinity> I'm around.
<infinity> I need to catch up with backscroll to see who's rebuilding what and why.
<Laney> it's for flash-kernel
<Laney> AIUI, anyway
<infinity> Ahh, indeed.
<infinity> Ugly bug.
<skaet> infinity,  pad should be up to date, but ...  edit if something missed
 * infinity wonders about that "arm" pipeline on the pad.
<infinity> That looks like it'll just rebuild all live images, period, not just ARM.
<infinity> As does the "desktop" pipeline.
<infinity> So, we get to build ARM images twice. :P
<plars> xnox: so if I've previously done an lvm install, and now I want to do manual partitioning, what's the best way to go about that? I don't seem to have a good way to take care of the things LVM left behind from the partitioner
<plars> xnox: or is this all related to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1042647
<Laney> I think skaet designed it as favours which do/do not include ARM
<ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New]
<cjwatson> I suspect the pad predates ARM being moved into daily-live for many flavours.
<infinity> Laney: Yeah, what cjwatson said.
<skaet> cjwatson,  arm part was accurate for beta 1
<infinity> I think someone just faithfully turned daily-preinstalled into daily, and didn't think that this meant we now just have two of (almost) everything.
<cjwatson> skaet: The ARM -> daily-live change predated that by some way, though.  I suspect we just never noticed the problem, or else somebody edited it on the fly.
<skaet> cjwatson,  ok.   Excuted those sets last night when I did the full rebuild.
<skaet> but if we can get it more efficient, +1.
<ogra_> there is still one preinstalled lubuntu image thouh
<ogra_> *though
<infinity> ogra_: Yeah, I know.  I'll fix this all up before I (re-)spin anything.
<ogra_> thx
 * cjwatson rereads the pad in detail
<cjwatson> infinity: actually, I think what's happening here is that the flavours that include arm are *only* built in the ARM section
<cjwatson> so the ARM section is building images for x86 as well, in reality
<infinity> Oh, yeah.  I just noticed the lack of "ubuntu" in the "main" section.
<infinity> Still, totally not as advertised. :P
<cjwatson> So it's confusing but not inefficient, as I read it
<skaet> infinity,  only respins expected at this point though are the arm ones.
<skaet> though
<cjwatson> And Kubuntu, or else it can't ship
<cjwatson> See earlier conversation with Riddelll re bug 1055967
<ubot2> Launchpad bug 1055967 in ubiquity "ubiquity kde frontend is broken in current kubuntu daily builds" [Critical,Confirmed] https://launchpad.net/bugs/1055967
<infinity> skaet: Sure, but the current layout of the pad means that respinning ARM respins all ubuntu desktop images, etc.
<infinity> Not that this bugs me.  If we have a new ubiquity, I'd rather do all live images.
<phillw> infinity: so, a respin of all of Desktop editions? It's no problem, just I'd like to inform the testers so they don't go testing something that is due for replacement :)
<skaet> infinity,  it was just individual invocations.
<infinity> phillw: There's no such thing as wasted testing.  If they find bugs and file them now, that's better than doing so in a day.
<skaet> infinity,  not sure we want to do a full respin on the other architectures,  since testing started very late, and not sure its as critical there.
<infinity> phillw: This culture of "waiting for the golden RC image" needs to die in a fire, otherwise people sit around twiddling their thumbs until 2 days before a final release.
<phillw> infinity: with the excpetion of ppc, the lubuntu ones were behaving. It is more a case of keeping the testers in the loop :)
<phillw> infinity: oh, you need not fear that! They love to go play, just keeping them informed is also nice :)
 * cjwatson bisects memory sizes in KVM; oh what fun
<phillw> cjwatson: does a respin with ubiquity bring in your changes for Lubuntu ppc-Desktop?
<skaet> infinity,  pad has the images that need to be respun.  use individual lines and ARCHES=... to just get the necessary respins.
<infinity> skaet: Yes, I know.  I was saying that "as written", it implies that would somehow just do ARM.  Either way, with new ubiquities, we really should be testing them.
<cjwatson> phillw: I guess
<skaet> infinity,  was accepted as opportunity target,  not as a respin trigger
<phillw> great :)
<cjwatson> Any current respin would pick up the yaboot-installer fix I merged; no idea whether it's already in
<cjwatson> Check versions in the manifest file for that
<cjwatson> (it's EOD for me now so I'm not going spelunking for it)
<phillw> cjwatson: okies, again, thanks for the time you spend on this pesky flavour ;)
<cjwatson> *shrug* wasn't anything Lubuntu-specific about it :)
<phillw> cjwatson: I was refering to ppc :)
<phillw> bug 1040544 was still there today.
<ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up on PPC" [Undecided,Confirmed] https://launchpad.net/bugs/1040544
<cjwatson> powerpc is an architecture, not a flavour. :-)
<cjwatson> Yeah, like I say, that bug is likely not an installer problem.  Can't help you with that.
<phillw> i was close!
<phillw> x-org bug?
<cjwatson> See my mail.
<cjwatson> From a day or two ago, whenever it was.  No point going over it again.
<phillw> I'll go dig it out, I knew I had something to do today :/
<phillw> ..
<infinity> cjwatson / Riddelll : So, I don't see any interesting updates on this ubiquity/kubuntu bug.  Was that going to be dealt with $later?
<Riddelll> cjwatson: I'll take a look in a minute
<Riddelll> infinity rather
<infinity> Danke.
<doko> may I accept packages in no package set, which fix ftbfs issues?
<infinity> doko: Better to check seeded-in-ubuntu(1) to make sure it doesn't appear to land on any images, but yes.
<Laney> well, feature freeze still applies ...
<infinity> Laney: FTBFS fixes aren't features. :P
<Laney> If they /only/ fix the FTBFS, then indeed.
<Laney> but that's not how the question was worded
<infinity> That was the implication.  doko's smart enough to know if he's misrepresenting himself. :P
<doko> infinity, I'll let python3.3 to you ...
<Laney> I thought the implication was "can I break FF to fix FTBFS?"
<Laney> :-)
<infinity> Laney: No, the implication was "we're in a hard freeze and I want to accept FTBFS fixes in the queue"
<doko> I'll do that later after the freeze =) but currently debian doesn't have many new upstream versions
<infinity> doko: Do I want to know what's wrong with py3.3 that you're pawning off on me?
<infinity> Oh, the sync in the queue.
<skaet> infinity,  after some discussion with plars in another channel,  preference is to hold off of the respins for ubuquity for ubuntu other than the arm platform.   There are some other fixes they'd like to see included before retesting.   However if none of them land,   a respin later tonight/tomorrow morning of the i386/amd64/etc.  and retest then.
<infinity> doko: That python3.3 Debian upload doesn't seem to imply that it contains the changes from the last Ubuntu upload...
<doko> infinity, it does
<infinity> skaet: Yeah, I was holding off until I heard back about kubuntu as well.
<infinity> doko: Just your infamous lack of verbosity in changelogs at work here? :)
<infinity> skaet: But for now, I might just spin some arm/ubuntu-desktop images for people to test Oli's fix.
<infinity> s/some/one/, since we only build one...
<skaet> thanks infinity,  yes please.
<infinity> skaet: Building now, then.
<NCommander> ogra_, ping who is responible for updating the ARM OMAP install instructions
<phillw> NCommander: I *believe* it is elfy
<phillw> NCommander: https://wiki.ubuntu.com/QATeam/QuantalTestcaseUpdates
<phillw> although that may well be seperate to install instructions :)
<Daviey> cjwatson: hey, i'd really like to make our squashfs available outside of the iso, vi cdimage..  Can we make this happen?
<skaet> cjwatson,  after a bit of spelunking, not spotting the yaboot-installer merge you were referencing earlier.   Do you have a bug number handy?
<infinity> skaet: https://launchpad.net/ubuntu/+source/yaboot-installer/1.1.22ubuntu2
<infinity> skaet: Included in https://launchpad.net/ubuntu/+source/ubiquity/2.12.3
<skaet> thanks
<Riddelll> cjwatson, infinity: able to eye over the changes I just pushed to ubiquity?
<Riddell> xnox: ^^
<cjwatson> Daviey: sure, easy enough
<cjwatson> Riddell: ubiquity/plugins/ubi-usersetup.py still uses PyKDE4.kdeui.KIconLoader
<cjwatson> Riddell: Can we ditch the misc.drop_privileges_save() / misc.regain_privileges_save() pair around the QApplication constructor, or does QA still need that?
<Riddell> cjwatson: sure you have the latest version?  I changed ubiquity/plugins/ubi-usersetup.py
<Riddell> cjwatson: mm yes it does work without the privilages changes, fixing
<cjwatson> Riddell: Yes, I'm sure I have the latest version - r5696
<cjwatson> ubiquity/plugins/ubi-usersetup.py:463:        from PyKDE4.kdeui import KIconLoader
<cjwatson> Ah, you just forgot to remove the import, I think?
<Riddell> cjwatson: oh aye, fixing
<cjwatson> tests/run-pyflakes would have told you if xnox hadn't partially broken it by removing all the print_function imports :)
<cjwatson> I'm going to put those back - Python 2 or no Python 2, it's too useful to have a sufficiently functional pyflakes
<cjwatson> Riddell: oh, if you rejected that, can you make it UNRELEASED again in bzr?  I'd like to make a few minor changes at the same time
<Riddell> ok
<cjwatson> (and delete the tag I guess)
<Riddell> done
<skaet> infinity,  what order will the respun arm images be emerging in?
<skaet> plars is eagerly awaiting the arm server one.... ;-)
<infinity> skaet: Uhm.  That one.  I only respun ubuntu-desktop/armhf+omap4.
<infinity> skaet: I'll do server right now for him. :P
<phillw> can someone quickly check to see if ubiquity has forgotten to ask people to ensure their (laptop) is plugged into the mains? I've just got this by email & am asking the OP to raise a bug.
<infinity> skaet: (I figured desktop was enough to test the bugfix, since the world will more than likely get respun for a whole new ubiquity later, but server's on the way too now)
<skaet> infinity, ack.
<cjwatson> Riddell: nearly finished ...
<cjwatson> Riddell: r5701 has everything I care about; be my guest for another upload
<cjwatson> stgraber: FYI you can make changes to post-qa in the public cdimage branch in future.  I'm porting your changes across now
<cjwatson> Daviey: done now for future builds, I think; and as a free bonus I put the .squashfs files in place for the current ubuntu-server/daily build
<Daviey> cjwatson: hah, i did that a few days ago.. but was obv. lost.
<Daviey> I love free bonuses!
<Daviey> thanks.
<cjwatson> did which, dropped them manually into place?
<stgraber> cjwatson: ok, thanks
<Daviey> cjwatson: I dropped it manually a few days ago.
<cjwatson> yeah, that ain't gonna persist without help ;)
<Daviey> in a .squashfs/ .. so it wasn't visible
<Daviey> Well yeah.. i knew that :)
<cjwatson> FWIW, it'd be nice if, whenever anyone feels the need to touch the published cdimage/releases trees by hand (beyond the known times when it's necessary such as the odd tweak when publishing milestones) they mention it here
<cjwatson> I can imagine things getting out of hand fairly easily
<Laney> what /is/ the public cdimage branch? the one lp:ubuntu-cdimage imports from?
<plars> ogra_: ping?
<cjwatson> Yeah, unfortunately the mirroring is broken right now
<cjwatson> Which I plan to fix before 12.10
<cjwatson> bzr+ssh://nusakan/srv/cdimage.ubuntu.com/bzr/cdimage/
<cjwatson> for those with access
<plars> ogra_: next round of armhf images are not going to work, I think we need something else in the flash-kernel fix
<cjwatson> the cdimage branches are mid-reorg - it should all be a lot more rational by the time I'm done
<Laney> Fair. Because I was wondering if I was really supposed to be trying to push to a branch on people.c.c
<cjwatson> Nah, that basically dates from a previous era in LP branch management
<cjwatson> Seeing as cdimage is older than Launchpad
<hallyn> hi all - stgraber found that latest quantal was failing in kvm-spice.  I opened bug 1056381 to track it, and list there what I needed to fix it.
<ubot2> Launchpad bug 1056381 in xserver-xorg-video-qxl "error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381
<hallyn> summary: need spice and spice-protocol 0.12, and a bunc hof patches from xserver-xorg-video-qxl upstream
<hallyn> i suppose maybe i should push those and everything depending on them into a ppa...
<hallyn> biab
<stgraber> the final set of changes required doesn't seem too scary especially as it's limited to spice which isn't that commonly used (or we'd have noticed it being broken earlier I'd think)
<infinity> plars: The images I just spun still don't work?
<plars> infinity: they flash-kernel fix is no good, I just tried it via the netboot image and it failed
<infinity> plars: What's the failure mode?  Do you have logs?
<plars> infinity: yeah, one sec
<plars> infinity: http://paste.ubuntu.com/1227506/
<plars> infinity: somewhere, the boot partition is getting removed, so setting the label rather than formatting it was not the right fix
<infinity> plars: Uhm.  Wow.  That so shouldn't be happening at all, given that we just re-use that partition.  Or, did so in the past.
<plars> infinity: that's the best explanation I have at the moment... looking at the mmc card, there is no partition on it it seems
 * infinity fears he's going to have to delve into f-k this afternoon.
<infinity> plars: Well, it will be "invisible" after the rename, which is sort of the point.
<infinity> plars: Ish.
<infinity> plars: I'll block off some time this afternoovening to look at it.
<plars> infinity: but my guess is that was the command complaining that there was no /dev/mmcblk0p1
<infinity> plars: Can you test the server image I spun and confirm that it fails the same(ish) way?
<plars> infinity: yep, is it done?
<infinity> queuebot claimed it was done a while ago.
<infinity> About an hour ago or so.
<infinity> 20120925.2
<infinity> I'm going to run and get some lunch/dinner/whatver and then settle in for an evening of figuring this out.
<hallyn> stgraber: should i slap an 'ffe' on that bug?
<hallyn> well lemme see how mcuh i can cram into a ppa before i have to run
 * hallyn wonders if he can figure out how to do a sync from debian to ppa
<plars> infinity: that was desktop actually I think, but I can check it with that one too
<infinity> plars: No, I did server after desktop.
<stgraber> hallyn: by your description of it, xserver-xorg-video-qxl should be a bugfix only cherry-pick, so won't need a FFe. Not sure about spice and spice-protocol, if those are also just bugfixes, then no need for an FFe.
<infinity> 14:23 -queuebot:#ubuntu-release- Builds: Ubuntu Desktop armhf+omap4 [Quantal Beta 2] has been updated (20120925.2)
<infinity> 15:11 -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+omap4 [Quantal Beta 2] has been updated (20120925.2)
<infinity> ^-- From /lastlog
<cjwatson> hallyn: if syncpackage can't do it, copy-package in lp:ubuntu-archive-tools likely can.
<cjwatson> It should be a swiss army knife for basically all the things LP itself allows doing with copies.
<infinity> I suspect sync can't target PPAs, but copy certainly can.
<hallyn> cjwatson: will try copy-package, thx
<hallyn> oh, sync-package --nolp should do what i need
<hggdh> infinity, plars: I am running the server install now
<infinity> hggdh: Thanks.
<plars> hggdh: awesome, go for it :)
<infinity> hggdh: If it doesn't fail, cool to know, if it does, the more detailed you can get the logging, the shinier.
 * plars needs to go afk for a bit anyway
<hggdh> infinity: ack. Should take anothe 10 min
<plars> infinity: I have a failed case sitting right in front of me if there's anything you can think of that would help
<infinity> Right.  Ima go grab some Subway and pretend that's a healthy meal.
<infinity> Jared wouldn't lie, right?
<hggdh> nevah
<cjwatson> hallyn: syncpackage --no-lp can be used for that kind of thing, yeah, but it's kind of crude.
 * micahg would suggest backportpackage in place of syncpackage --no-lp if not copying to the archive proper
<micahg> *planning on copying to the archive proper
<plars> hggdh: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1056482 has what I've captured of it so far
<ubot2> Launchpad bug 1056482 in flash-kernel "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,New]
<TheLordOfTime> so... anyone here mind answering a question about the retracer for me...?  regarding a quantal crash bug i saw in passing.
<hggdh> plars: I will add to it
<TheLordOfTime> or should i poke around elsewhere?  (nothing from -bugs thus far)
<hallyn> cjwatson: heh, sorry.  my old copy of ubuntu-archive-tools doesn't have copy-package, i'll fetch a new one and look through it
<hallyn> there it is
<hallyn> --to-ppa-name.  nice :)
<hallyn> all right.  next time.
<hggdh> plars: flash-installer works on -server
 * skaet --> afk for evening.
<plars> hggdh: oh? interesting
<hggdh> plars: just checked mmcblkp1, seems correct
<cjwatson> Riddell: still up?
<cjwatson> Riddell: I'm going to go ahead and reupload ubiquity
<xnox> plars: infinity: well 2.12.4 ubiquity with the flash-kernel fix landed after the 20120925.2 build unless I am reading it wrong.
<xnox> wait. 20120925.2 has ubiquity 2.12.4, never mind me.
<xnox> cjwatson: I guess i'm down to port py3flakes....
<cjwatson> once there is a pyflakes that doesn't throw errors on Python 3 print(file=...), you can drop print_function again :-)
 * xnox is happy and off to cook some dumplings with meat. comfort food after seeing that commit notification =)
<cjwatson> poor xnox ;-)
<xnox> cjwatson: barry is joining on the py3flakes effort @ uds-r
<barry> yeah, that one made me cry too :)
<cjwatson> I'm not in a desperate rush; leaving print_function in mostly lets it do a fine job
<cjwatson> somebody please review that ubiquity upload?  should fix kubuntu
<RAOF> I'll trade SRU reviews if someone would like to give colord a push into precise-proposed. It'd be nice to verify that it does indeed fix the 5th most common 12.04 crash report.
 * cjwatson -> bed; if you need to fix ubiquity further, upload a .6 :)
 * xnox likes the black market of bird seeds for reviews&button pushing on various queues =)))))
<infinity> plars: Oh, wait.  You said that was a netboot.  Was that writing the netboot image to an SD card, or booting via PXE?
#ubuntu-release 2012-09-26
<plars> infinity: writing the image to card, then booting from that, and selecting the default install options, so I'm wondering if it's something in the partitioning step that clobbered it
<plars> infinity: fwiw, the target appears to correctly be sda (the usb stick) though
<jbicha> hi, could gnome-shell get accepted, as it needs to rebuild against the new mutter that was accepted earlier
<RAOF> Hm. Queuebot seems to be missing everything not going to quantal?
<stgraber> RAOF: like that one? ^
<RAOF> Heh. Indeed, like that one :)
<RAOF> Just a bit slow, I take it :)
<RAOF> Ok. precise queue is now down to a single page again.
<stgraber> yay
<skaet> infinity,  did the arm flash issue get resolved for desktop or not?
 * skaet can't tell from pad or backscroll... 
<infinity> skaet: Looks like it's resolved for server (and probably desktop, though no one confirmed that directly), but seems to still be occasionally goofy for netboot.
<skaet> thanks infinity,  thought plars was still seeing issues was desktop, but if its resolved, that's good.
<plars> infinity: I've seen a report from someone that it works on desktop, just netboot seems to be causing me grief now
<plars> skaet: ^
 * skaet nods
<infinity> Mmkay.  I'm slightly less concerned about netboot, but I'll test it nonetheless.
<infinity> We should be good to go to respin everything qith ubiquity on it for the most recent upload thereof.
<skaet> any other pain points emerging?   or should this be it?
 * skaet goes to stare at iso tracker
<plars> skaet: seeing some missing options in the installer
<plars> ex. no "install alongside" option if you have a previous version of ubuntu on the drive
<skaet> plars, is there a bug number?
<infinity> plars: On ARM, or in general?
<plars> and no reinstall option if you are installing the same version (unless it's intended to not really be a separate option.. I'm slightly more skeptical of this one since it could be an interpretation of install spec)
<plars> infinity: in general
<plars> skaet: yeah, sec
<skaet> also,  any progress from TheMuso on the orca stopping reading after ubiquity?
<plars>  bug #1056571  bug #1056587
<ubot2> Launchpad bug 1056571 in ubiquity "Missing "reinstall" option when installing same version of Ubuntu" [Undecided,New] https://launchpad.net/bugs/1056571
<ubot2> Launchpad bug 1056587 in ubiquity "Install alongside option missing when installing quantal over precise" [Undecided,New] https://launchpad.net/bugs/1056587
<skaet> thanks plars
<plars> skaet: he replied asking for details, so I updated the bug with more information on *exactly* which screen it stopped on
<infinity> skaet: If you respin the world now, you should catch triggers 5, 17, 13, and 16.
<infinity> skaet: I could also promote gtk+2.0 and overlay-scrollbar from proposed and pick up trigger 14.
<skaet> infinity,  and 11?
 * skaet thought gtk2.0 was trigger 11.
<infinity> skaet: Oh, and 11.  gtk+2.0 is also 14 (as in, the overlay-scrollbar thing is tied up with gtk being fixed/changed, and overlay-scrollbar needing to change with it)
<skaet> infinity,  gotcha.
<infinity> skaet: Anyhow, if we want to do that, can't start rebuilds for ~1h.
<skaet> How about we respin kubuntu now,  so its ready when Riddell shows up.     Others we can see what the flavors want,  and decide on a respin of Ubuntu early tomorrow?
<infinity> skaet: GTK is in kubuntu too.  If we decide to promote gtk+overlay, there's very little that doesn't need rebuilding.
<infinity> (And "seeing what flavours want" doesn't change that things should be tested with the new installer upload, etc.  We should probably just do a full respin overnight)
<infinity> skaet: Between GTK (if we take it, and we probably should) and ubiquity (which is already in), that touches literally every image built on nusakan except core.  I saw we JFDI.
<infinity> s/saw/say/
 * skaet was staring at what had been tested already
<skaet> lubuntu's the one that's been tested the most,  and I know they want some of the powerpc fixes.
<infinity> lubuntu's folks already told me they were prepared for respins.
<skaet> ok infinity,  lets respin
<infinity> And, regardless, it's Tuesday, if this is the last image, I'll eat my hat.
<infinity> skaet: Right, let me promote the gtk and overlay stuff.
<infinity> skaet: Which should put us in respin land in ~45m.
<skaet> ok
<skaet> infinity,  can you stay up long enough to kick off the full respin?
<infinity> skaet: Given the above timing, I think I can line it up now and hit <enter> three times on my way out the door for the evening. :)
<skaet> infinity,  goodness,  thanks.
<skaet> ok,  I'll go mark the iso tracker we're respinning.
 * skaet not sure we need a wubi respin
<infinity> It's still got the gtk change.
<infinity> And overlay-scrollbar.
<skaet> ok then we do.
<infinity> The only thing that doesn't strictly need a rebuild is core, and it really doesn't matter if we rebuild it or not, since I can validate it in about 20s.
<skaet> however,  please special case Edubuntu to just the shipped architectures.
<skaet> (ie.  waiting on arm for it is a waste of time,  since that's not shipping, and its in the defaults)
<infinity> I can just drop ARM from default-arches for Edubuntu for now.  *shrug*
<skaet> what ever works,  I'll let you and stgraber decide when to add it back, if that's the route you prefer
<infinity> I'll drop it from defaul-arches in production, so there's an obvious diff against bzr that people can scratch their heads over.
<infinity> It's less prone to screwing up that way.
<skaet> ok.
<stgraber> sounds good
<skaet> ubuntu server images don't have any issues reported against them.   Much point in respinning them?  (already respun for 5)
<plars> skaet: none that I see, other than arm which was already done
<plars> skaet: we still have 2 bugs on arm server that, for different reasons, seem to require that most people install from serial
<plars> skaet: but those were both in beta1 also
<infinity> stgraber: "bzr diff /srv/cdimage.ubuntu.com" look like a good enough reminder for you?
<skaet> infinity,   ok,   leave ubuntu server out of the full respin then,  unless we get some specific fixes for them.
<stgraber> infinity: yep
<infinity> skaet: ubiquity is on the server images too.
<skaet> infinity,  yeah, but 16 is down as opportunity target,  and 5 has already been applied.
<skaet> infinity,  can you turn off the auto erase of images so we can keep the current ones until after we ship out beta 1.
<skaet> beta 2 rather
 * skaet needs sleep it appears
<infinity> If a new one is broken, but an old one isn't, don't we want to actually fix what broke it?
<skaet> turning off the auto erase means that if we have a regressions,   we can do some direct comparisons quickly, rather than worry about loosing the image
 * infinity nods.
<infinity> That's the justification I was hoping for. :P
<skaet> iso tracker marked now as rebuilding all images except server
<skaet> I figure we can redo that one quickly enough tomorrow,  if needed.
 * skaet --> zzz
<apw> i see linux-lowlatency needs updating, i would like to get an update building but do not want to disrupt the beta efforts.  I would propose uploading it to quantal-proposed as normal and letting it out after freeze.  if that is good?
<cjwatson> apw: seems reasonable, especially since it only builds on fast architectures
<apw> thanks
<cjwatson> Does the current version still have that cluster of i915 bugs?
 * apw checks
<cjwatson> (Or, what is the update for?)
<infinity> apw: It only lands on ubuntustudio images anyway, and I'm not against respinning those once it's built.
<infinity> apw: But toss it in proposed, and we can sort it from there.
<apw> ok the current version has half of the i915 fixes, but not the latest reverts, this rebuild would bring those
<infinity> Seems worth it.
<apw> ok
 * infinity should get some sleep tonight.
<cjwatson> Right.  Stick it in -proposed anyway and then we can choose, as the man says.
<apw> makes sense, thanks
<ogra_> urgh
<cjwatson> popey: does rsalveti's comment in bug 1046392 indicate sufficient testing to you?
<ubot2> Launchpad bug 1046392 in unity-2d "Update dependency on the renamed libgeis" [Undecided,Fix committed] https://launchpad.net/bugs/1046392
<cjwatson> since you were the one who said it needed more testing on ARM
<infinity> apw: Do I get a meta too?
<infinity> apw: Err, no ABI bump, nevermind.
<infinity> apw: Not awake, clearly.
 * ogra_ sees bug 1056482 anfd wonders if in-target behaves differently between netinst and a normal install ... i tested the fix in a locally hacked up server image and there it worked
<ubot2> Launchpad bug 1056482 in flash-kernel "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,New] https://launchpad.net/bugs/1056482
<apw> infinity, :) have a coffee
<infinity> apw: A nap is probably more sensible.
<ogra_> have both :)
<ogra_> (in the right order indeed)
<popey> cjwatson, yes
<cjwatson> popey: how about on oneiric?
<popey> cjwatson, i tested on oneiric, but not arm oneiric. :S
<popey> hmm
<popey> i can do that cjwatson, I'll get back to you
<cjwatson> thanks
<Laney> coffee. a good idea.
 * cjwatson is at coffee == 2 and still zonked
<Laney> zoiks
<Laney> I ought to acquire a grinder and level up in the coffee stakes
 * ogra_ wonders if there is something bind mounting /dev in server and desktop installs that is missing in netboot ...
<ogra_> so that in-target doesnt find /dev/mmcblk0p1
<infinity> That's entirely possible.
<ogra_> thats my only explanation i can get to
<cjwatson> It's a bit unlikely that server and netboot would differ.
<cjwatson> desktop vs. server/netboot, certainly
<ogra_> live-installer ?
<infinity> live-installer versus base-installer.
<ogra_> right
<infinity> There are subtle differences there.
<cjwatson> Oh, if that's calling f-k then possibly, yes.
 * ogra_ has just a test of all server images running, will go for netinst once they are done and inspect 
<cjwatson> plars: as a general rule, could you please attach full syslogs to bugs rather than just quoting sections of them?  we often need to go through more context than people think is needed
<cjwatson> (installer bugs, that is)
<cjwatson> ogra_: Except flash-kernel-installer.postinst appears to bind-mount /dev itself ...
<ogra_> hmpf
<cjwatson> mount -o bind /dev /target/dev
<cjwatson> if ! in-target flash-kernel; then
<cjwatson>         umount /target/dev || true
<cjwatson>         error "flash-kernel failed"
<cjwatson> fi
<cjwatson> umount /target/dev || true
<cjwatson> Which would appear to be the section that's failing here?
<ogra_> i'm not sure it could be the dosfstools above
 * cjwatson curses incomplete logs
<ogra_> (or rather i think its more likely its that)
<ogra_>               export VOLID=$(blkid -o value $(findfs /)|head -1)
<ogra_>                 # hide the boot partition from udisks automounting
<ogra_>                 bootdev=$(get_machine_field "$machine" "Boot-Device")
<ogra_>                 [ -b $bootdev ] && in-target dosfslabel $bootdev "SERVICEV001"
<cjwatson> Ah, no
<ogra_> no bind mouonting there
<cjwatson> It's installing u-boot-tools
<cjwatson> So it must be the section that installs Required-Packages
<ogra_> oh, so its past that step, right
<cjwatson> And indeed, no bind-mount there
<cjwatson> I'm inclined to suggest that maybe live-installer ought to change here to be more in line with bootstrap-base
<ogra_> live-installer is fine
<infinity> cjwatson: Didn't live-installer have some bindmounts commented out?
<ogra_> it bindmounts before running the postinst
<cjwatson> Right, setup_dev is commented out in live-installer.postinst
<infinity> cjwatson: (But, in this case, live-installer is actually the one that works)
<ogra_> so all of it is wrapped
<cjwatson> ogra_: What bind-mounts before running what postinst
<cjwatson> ?
<cjwatson> NOUNS
<ogra_> heh
<ogra_> one sec
<cjwatson> infinity: huh.  exactly backwards from what I'd expect ...
<infinity> cjwatson: Indeed.  But the server and desktop images both work, while netboot fails.
<infinity> cjwatson: That's the curiosity.
<cjwatson> bootstrap-base (as in netboot installs) leaves /dev bind-mounted onto /target/dev for most of the rest of the installation, I think.
<ogra_> hmm, i'm sure we implemented some /dev bindmounting in l-i around beta1
<cjwatson> (Just from code inspection; haven't checked recently.)
 * ogra_ cant find it
<cjwatson> No.
<cjwatson> But in any case, as you say, live-installer isn't the one that's broken here.
<cjwatson> So would that qemu beagle test you suggested be a reasonable way for me to reproduce this?
<cjwatson> I think I need to see it in action.
<ogra_> cjwatson, it should, behaves like a beagleboard without all the nasty HW bugs :)
<cjwatson> Heh.  It'll save me having to debug lowmem mode right now.
<infinity> Oh dear, I just realised we have meetings in 4 hours.
<infinity> This isn't going to be a good day.
<infinity> At all.
 * infinity runs off to try to force himself to nap.
<infinity> Emphasis on the "run".  Maybe I can tire myself out.
 * ogra_ glares at the flash-kernel-installer.postinst and thinks its all wrong ... 
<ogra_> it is actually calling "in-target update-initramfs -c -k $(uname -r) || true" around line 74 ...
<ogra_> long before flash-kernel is actually ready
<cjwatson> ogra_: which of the many boot images should I be using with qemu-system-arm -M beaglexm then?
<ogra_> and then it calls flash-kernel again in the end
<ogra_> cjwatson, one of the gzipped img files (if you refer to netboot)
<cjwatson> yes.  which one exactly?
<infinity> cjwatson: boot-img-fb.gz or -serial.gz, depending on if your commandline is setting up a serial console.
<cjwatson> OK
<ogra_> cjwatson, ise the fb one
<ogra_> *use
<ogra_> or hack my script to not steal the serial console if you use --serial
<ogra_> and indeed create a target device before
<ogra_> (for --root)
<cjwatson> That gives me "qemu: hardware error: no boot device found"
<cjwatson> Do I need to uncompress the img file?
<ogra_> did you unzip it ?
<ogra_> ah
<cjwatson> (feel free to point me at wiki directions)
<ogra_> :)
<cjwatson> ogra_: Hah.  Not quick, is it.
<ogra_> lol, nope
<ogra_> i'm at the hostname setup alread and started after you though
<cjwatson> Mine's still loading additional components.
<ogra_> (and my omap3 test that i did before failed :/)
<cjwatson> Oh, I suppose that could be slow network.
<cjwatson> Duh.
<ogra_> yup, i use the server image here
<ogra_> (and i have a local mirror of ports for netinst())
<cjwatson> Yeah, but I want to see the failure.
<ogra_> right, i just want to inspect the postinst inside the image atm
<cjwatson> I expect I'd have a local mirror if I worked on ARM all the time.
<ogra_> i'm pretty sure the failure is that unconditional update-initramfs call in the postinst
<ogra_> there is no bind mounting at all
<cjwatson> But I want to understand why this differs between live-installer and bootstrap-base, in case this is a consequence of a bug elsewhere.
<ogra_> and it happens directly after apt-install
<ogra_> it very likely is
<cjwatson> I don't have a problem if it turns out to be solely an f-k-i bug and you want to fix it there.
<cjwatson> But I also don't want to have a system composed of patches for its own bugs, when we could just fix them directly, if that's what needs to be done.
<cjwatson> Hence investigation.
<ogra_> well, the update-initramfs call definitely needs some bind mount logic ... but it would still be good to know why the environments differ
<ogra_> so yes, i will fix it in f-k in the end
<ogra_> hrm
<ogra_> why does my image have the wrong postinst
<cjwatson> The reason I don't find that argument compelling yet is that the environment that fails is the one that is *more* likely to have an appropriate bind-mount already.
<ogra_> hmm
<ogra_> ogra@anubis:~/Desktop/images$ cat /mnt/.disk/info
<ogra_> Ubuntu-Server 12.10 "Quantal Quetzal" - Beta armhf+omap (20120925)
<ogra_> now why does the md5 match 25.2
<cjwatson> In what way is it wrong?
<ogra_> dont we put the .x into the info file ?
<ogra_> (the content agrees that it isnt 25.2 (teh f-k fix isnt there))
<cjwatson> What's the URL for this image?
<ogra_> http://cdimage.ubuntu.com/ubuntu-server/daily/20120925.2/
<ogra_> aha
<ogra_> the timestamp for omap4 is at 21:00
<ogra_> omap is 9:00
<ogra_> looks like that wasnt rebuilt
<ogra_> oh, and we now publish all squashfs'es
<infinity> ogra_: Oh, no, I only did omap4, I forgot we were still building omap.  Feel free to spin an omap/server image (everything else is rebuilt by now)
<ogra_> ah, awesome
 * infinity passes out now.
<ogra_> we'll excuse you at the meeting if you sleep in :)
<cjwatson> squashfses> only for the server image
<ogra_> ah, k
<cjwatson> (well, strictly, only for squashfs-base images, but that's just ubuntu-server at the moment)
<ogra_> i thought you wanted to disable that ...
<cjwatson> I explicitly enabled it; it was never previously enabled
<cjwatson> so not sure what you mean there :)
<ogra_> i pointed you to the amd64+mac squashfs yesterady and understood you wanted to disable it :)
<ogra_> but then i misunderstood
<NCommander> ogra_, I'm looking through the backscroll, how goes the f-k fixing?
<ogra_> if nobody minds i'll do a respin of omap server now
<ogra_> NCommander, only affects netinst ... who uses that anyway :P
<cjwatson> ogra_: I deleted that because it wasn't currently being emitted by the code
<ogra_> ah
<ogra_> omap server running
<cjwatson> ogra_: It was there because Daviey had inserted it manually and hadn't either updated the code or cleaned up afterwards, so it was faithfully copied across by subsequent builds
<ogra_> k, your recation just made me think it was unwanted ... i just interpreted to much :)
<cjwatson> Nah, I just care about consistency :)
<NCommander> ogra_, .oO(I do)
<ogra_> NCommander, ah, then it is because of you that we debug this now :)
<ogra_> (just adding a fix to f-k wold be easy btw ... but that wouldnt explain why the envs differ)
<Riddell> could I get a rebuild of kubuntu amd64 and amd64+mac and powerpc?  they're oversized and I just removed a langpack from the seed
<cjwatson> sure
<cjwatson> though they looked *way* oversized
<cjwatson> oh, bah, daily-checks has the wrong limits so quotes them wrongly in mail
<cjwatson> that explains some weirdness I've noticed in the past
<cjwatson> I'll see if I can fix that in a bit
<cjwatson> Riddell: on its way
<plars> cjwatson, ogra_ : sorry, just woke up... I intended to attach the full syslog and partman but fell asleep first. They are both attached now
<plars> for https://bugs.launchpad.net/bugs/1056482 that is
<ubot2> Launchpad bug 1056482 in flash-kernel "/dev/mmcblk0p1 is not a block device when installing flash-kernel" [Undecided,New]
<plars> I'll try to go through it again in just a bit, since it worked on server and desktop, I'm guessing it might be something with the default partition selection for guided/full install
<plars> however, I can confirm that it looks like it's trying to install to /dev/sda (the usb stick): /dev/sda1 is mounted as /target/boot and /dev/sda2 is mounted as /target
<cjwatson> We think it's more likely to be a difference between the base system installation methods at this point
<cjwatson> Since there should be no difference in the default partition selection between server and netboot
 * Laney erks at that server failure
<Laney> dpkg-deb: file `/srv/cdimage.ubuntu.com/ftp/pool/main/d/debootstrap/debootstrap-udeb_1.0.42_all.udeb' contains ununderstood data member
<Laney> +data.tar.xz     , giving up
<ogra_> hmm, my omap server build finished 30min ago
<ogra_> but there is still no 20120925.3/
<ogra_> err
<ogra_> or rather no 20120926 i should say
<cjwatson> Laney: yeah, I was trying to comprehend that
<cjwatson> dpkg was upgraded an hour ago
<cjwatson> 2012-09-26 11:17:41 upgrade dpkg 1.15.5.6ubuntu4.5.0.ISPATCHED.10.04.1 1.15.5.6ubuntu4.6
<cjwatson> oh dear
 * cjwatson takes this to #is
<Laney> ah, so they had backported that patch from 1.15.6 and something happened to it
<cjwatson> Yeah.  Fixed now
<cjwatson> ogra_: Try again
<cjwatson> ogra_: It failed due to the problem Laney and I were just discussing
<cjwatson> Fortunately this was downgraded in time not to affect the Kubuntu build in progress
<Laney> on the bright side, I just found out that "ununderstood" is a real word
<doko> could somebody let python2.7 build in quantal-proposed?
<Riddell> cjwatson: those kubuntu images still have language-pack-kde-de on them, should we have waited a bit for the seed change to get picked up?
<ogra_> ah, thanks !
<ogra_> cjwatson, hmm, with try again you meant i should re-run for-project ?
<ogra_> or should it magically appear on cdimage ?
 * ogra_ runs it again
<cjwatson> Riddell: Yes
<cjwatson> Riddell: Seed changes that affect tasks need a publisher run that's doing something else
<cjwatson> (i.e. publishing a package)
<cjwatson> Riddell: I'll accept something from universe
<cjwatson> ogra_: I meant do the build again, since it failed very early
<ogra_> right, well, buildlive was fine
<cjwatson> buildlive wasn't the bit that failed
<ogra_> for-project is running
<ogra_> yep
<cjwatson> You can do just the cron.daily* part, yes
<ogra_> and done :)
<cjwatson> Riddell: We can try again in half an hour or so
 * ogra_ lols about the recent spam .... "ever wanted to sit like an executive ? buy and executive arm chair"
<ogra_> *an
<skaet> good morning ogra_,  cjwatson
<ogra_> heya
<skaet> :)
<cjwatson> morning
<cjwatson> ogra_: so for this qemu/beagle test, which disk should I partition, mmcblk0 or sda?
<ogra_> sad
<ogra_> heh
<ogra_> sda
<skaet> ogra_,  working through the backscroll ( and not had sufficient caffine yet), but I can't tell if we still have issues with the flash kernel on the arm ports or not yet.    Impression I've got is that we're ok on desktop and server, but netboot is still???   Is this accurate?
<ogra_> yes
<cjwatson> there's something wrong with netboot that I don't believe we fully understand yet
<cjwatson> I have a test running at the moment
<ogra_> right, i wanted to look into it as well, but am fighting on several other fronts
<skaet> thanks cjwatson.  is issue likely to be beyond arm then for netboot?
<skaet> ogra_,  are arm images basically sane at this point, or are there other blocker bugs that should be added to the under investigation list?
<ogra_> skaet, still pending desktop tests here
<ogra_> server are all fine
<ogra_> skaet, working around the netboot issue with a flash-kernel hack is trivial btw ...
<ogra_> (two bind mount/umount lines)
<skaet> thanks ogra_
<ogra_> if we havent fixed it based on teh environemt difference by end of my day i'll happily upload a fix
<cjwatson> skaet: I don't know yet.
<ogra_> (or i could even do that now and we leave it sit in proposed until needed)
<skaet> thanks cjwatson
<skaet> ogra_  sounds good.
<ogra_> ok. will do then
<skaet> thanks.  :)
<skaet> xnox,  any feedback on the bug with latest images: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1056707 ?
<ubot2> Launchpad bug 1056707 in ubiquity ""Unsafe swap space detected" dialog displayed too late if swap is created after an encrypted partition and makes manual partitioner unusable" [Undecided,New]
<xnox> skaet: standard debian-installer behaviour.
<cjwatson> displayed too late is standard; making the partitioner unusable seems rather a shame though
<NCommander> xnox, that sounds like a bug to me. Having unencrypted swap is a bad thing, plus hosing partman is worse
<xnox> skaet: as in, exactly the same behaviour is present on alternate/server cds since... forever.
<NCommander> xnox, just because the behavior been around since the dawn of time doesn't mean it ain't a bug
<cjwatson> xnox: I'm not aware that it makes the partitioner unusable as described in d-i
<cjwatson> Are you saying that it does?
<xnox> NCommander: true. I agree it's a bug. I simply don't know the best way to correct this.
<xnox> cjwatson: it bails out on commit, let me check d-i quickly.
<cjwatson> Anyway, if it isn't a regression from d-i then there's no reason to consider it RC
<xnox> cjwatson: d-i "This program will now abort"
<xnox> please diable the swap space or configure encrypted swap and run the setup again.
<xnox> but then it returns to the partitioner.... hmm...
<ogra_> how else would you create encrypted swap if not in the partitioner
<skaet> cjwatson, agreed,  if its not a regression,  its not release critical for beta 2.
<xnox> cjwatson: hmm... but the bug described is different.
<xnox> cjwatson: activate encrypted volume, then create swap, then click "Install now" and installation starts and yanks you back from "timezone" step back to guided partitioning.
<cjwatson> encrypted swap is really most easily done by way of encrypted LVM
<cjwatson> it's a right pain to encrypt independently
 * ogra_ ponders over bug 1056410
<ubot2> Launchpad bug 1056410 in ubiquity "changing drive partitioning on ARM Quantal does not work" [Undecided,New] https://launchpad.net/bugs/1056410
<cjwatson> Riddell: I've kicked off those Kubuntu builds for you again
<Riddell> lovely
<ogra_> heh, xaos ... that still exists ?
<tumbleweed> and seeded, even
 * ogra_ wonders if joey ever accepted his patch to add a .desktop file 
<ogra_> tumbleweed, yeah, i know, i seeded it some years ago :)
<tumbleweed> edubuntu: where we put all the fun stuff :)
<Laney> xaos is awesome
<ogra_> yeah, edubuntu is a fun playground
 * smartboyhw finds Ubuntu Studio better:P
<ogra_> back then it was a mix of both big desktops and streched even between server and desktop
<highvoltage> sssh, we don't ever say that out loud ;)
<ogra_> with unity added today it even mixes three desktops :)
<tumbleweed> or the "client" and server, as I note ubuntu people saying recently (urgh, I really dislike that use of the word client)
<ogra_> tumbleweed, +++
<ogra_> and +1!!!11!
<highvoltage> what is tripple plus? some weird php thing?
<smartboyhw> +1
<ogra_> its a plus doubleplus :)
<smartboyhw> Google+++
<ogra_> newspeak ;)
<highvoltage> ah I see
<ogra_> sigh, not looking at my bug mailbox for 1h during a pre-milsetone day is dangerous
 * ogra_ notices 100 new bugs within 1h
 * smartboyhw agrees:)
<ogra_> i guess i should leave some teams :)
<stgraber> ogra_: I guess you're in ~ubuntu-installer? :)
<smartboyhw> ogra_, er .....no:P
<ogra_> stgraber, yep, and since someone of PES asked me a quaestion about an armhf buildfailure i'm in ubuntu-webapps too
<ogra_> they tend to add me to their teams to give me access to their private bugs :)
<smartboyhw> ogra_, that's good:P
<Laney> hah
<Laney> I bet webapps is getting some well mannered email at the minute
<ogra_> well at least their bug pre hour throughput stays the same it seems ... but its a constant flow :)
<smartboyhw> ;)
<ogra_> oh
<ogra_> did we change the wallpaper ?
<ogra_> or is my pandaboard screen screwed up ?
<stgraber> that was a while ago I believe
<xnox> cjwatson: i commented in the bug 1056707 on a few options that are available to prevent users from hitting the warning at all, or to make it appear earlier.
<ubot2> Launchpad bug 1056707 in ubiquity ""Unsafe swap space detected" dialog displayed too late if swap is created after an encrypted partition and makes manual partitioner unusable" [High,Triaged] https://launchpad.net/bugs/1056707
<ogra_> ah, k
<ogra_> i didnt do fresh installs in a while for desktop
<xnox> cjwatson: can you check what would you prefer the best.
<stgraber> ogra_: it should looke like: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/ubuntu-wallpapers/quantal/download/head:/wartyfinalubuntu.png-20090702162935-bg4dfvc1nbr5imar-23/warty-final-ubuntu.png
<ogra_> fun, FF doesnt want to open it and offers me eog ... eog says "not a png file"
<ogra_> in any case its a lot more reddish and less violet i see
<ogra_> if it changed than i'm fine, i just didnt follow the theme changes this time
<cjwatson> xnox: followed up
<xnox> cjwatson: ok, thanks =)
<stgraber> ogra_: well, that's because it's actually a jpeg file with a .png extension and eog is apparently not capable of detecting that
<ogra_> stgraber, bug !
<ogra_> :)
<stgraber> ogra_: I vaguely remember us getting in trouble on upgrade when changing the name of our wallpaper, that's why it's still called warty and still is a .png. Though I guess now that we have fancy settings upgrade scripts we probably could transition the setting properly.
<ogra_> yeah. we should
<ogra_> though i actually like the historical naming scheme :)
<knome> skaet, others: what's the sign-off time for acking b2 release?
<skaet> knome 1200 UTC 9/27
<knome> oh shiny!
<knome> i thought it was 21UTC today :)
<knome> will you remind us with the url with an email?
<skaet> knome,   if you could have https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta2 filled out by 2100 today though it would be appreciated.  :)
<knome> skaet, right, yeah, i'll try to get that done when i get home
<skaet> thanks knome  :)
<knome> np
<knome> what's the url for acking/signing off the release?
<skaet> I'll send out an email reminder to the flavor leads now,  so we're all on the same page.
<skaet> knome,  for signing off for beta 2,   just comment in this channel that you're ok (or not) with the images going out.
<Laney> they get marked as 'ready' on the tracker
<knome> ok
<skaet> There's a wiki for the final release.
<knome> thanks skaet :)
<skaet> np
<dobey> doko: hi. i wonder if the armhf test rebuild was going slow and it introduced a weird race condition for that one ubuntuone-client failure. the same version built fine on arm in the normal archive builders. just rebuilding it might fix the problem
<skaet> utlemming,   how are the cloud images looking for beta 2?
<doko> dobey, given back
<dobey> doko: thanks
<ogra_> hggdh, dod you think about stephane ( stgraber) when you updated the description of bug 1056394
<ubot2> Launchpad bug 1056394 in grub-installer "grub-mount /dev/sdb1 /var/lib/os-graber/mount hangs" [Undecided,New] https://launchpad.net/bugs/1056394
<hggdh> ogra_: huh?
<ogra_> stephanes new spare time project for a presomalized ubuntu flavour :)
<ogra_> os-garber
 * cjwatson corrects the title
<ogra_> *graber
<hggdh> dammit
<hggdh> thanks cjwatson
<ogra_> i liked the typo :)
<hggdh> ogra_: probably, Freud explains, I guess
<ogra_> heh
<stgraber> ;)
<hggdh> ogra_: small issue with the new flash-kernel and uBoot/USBBoot: it loads, installs, reboots nicely. I can reboot again on the installed system. BUT if I power-cycle, USB-boot kicks in again
<hggdh> ogra_: sounds like the hidden P1 partition gets too well hidden
<ogra_> hggdh, no, sounds like fallout of bug 1055938
<ubot2> Launchpad bug 1055938 in flash-kernel "uboot and mlo not in boot partition after install" [High,Fix released] https://launchpad.net/bugs/1055938
<knome> skaet, i will take the release manager tasks from astraljava, elfy will take the QA contact tasks
<astraljava> skaet: Even while it's been fun, I will be concentrating on other tasks from now on, so I'm letting you know that contact persons for Studio and Xubuntu will be smartboyhw (Ho Wan Chan) and elfy, respectively.
<astraljava> Muah.
<astraljava> Err... right. Sorry, my bad. knome of course for release tasks.
<ogra_> hggdh, can you check if you are on the very last image ?
<hggdh> ogra_: how could that be the case, if I can reboot?
<ogra_> you can reboot multiple times ?
<skaet> thanks for letting me know astraljava.
<hggdh> ogra_: I downloaded it ~ 60m ago, will check for an update
<ogra_> (the hiding of the partition only applies to udisks, it cant have any impact on anything else)
<hggdh> ogra_: yes, multiple times, while I do not power-cycle
<ogra_> no, there wasnt an update in the last hour
<ogra_> weird
<hggdh> ogra_: let me reinstall, it was *not* the last image
<ogra_> ah
<smartboyhw> skaet, so that means I will now be normally responsible for the -release weekly summary (along with ScottL) right?
<Laney> you and ScottL can work it out between you
<knome> ok, i'm off. i'll take care of my responsibilities later today. see you!
<skaet> smartboyhw,  yes,  please coordinate with ScottL who will be sending it out.     Also could you please add https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta2 information for Ubuntu Studio (new feature summary and worrisome bugs)
<skaet> thanks nome
<skaet> thanks knome
<knome> heh, np. thank *you* for tolerating all our changes ;)
<smartboyhw> OK
<smartboyhw> Thanks skaet
<jbicha> hey, so we have a bit of a problem: gdm 3.6 won't start without gnome-session 3.6, I opened bug 1056936 to track this
<ubot2> Launchpad bug 1056936 in gdm "GDM 3.6.0 won't start without gnome-session 3.6.0" [Critical,New] https://launchpad.net/bugs/1056936
<jbicha> we can workaround this in the remix by just including gnome-session 3.6 manually, but it will still be broken for gdm users who upgrade today & reboot
<jbicha> 1. we could accept gnome-session 3.6.0-0ubuntu1 2. I could upload a newer gdm that depends on the new gnome-session, but that won't help those that have already upgraded
<jbicha> 3. I could do an ugly revert 4. I guess I could try to patch out the gdm change that needs the new gnome-session
<Laney> jbicha: sounds like it would be more correct to do 2 if we do 1 anyway
<jbicha> yes, #2 needs to be done but is not a full fix itself
<ogra_> cjwatson, is there any magic in d-i that detects serial installs beyond it looking at console= from the cmdline ? ppisati is seeing some really weird behavior on a panda server install (booting the image seems to randomly switch between framebuffer and serial on different boots)
 * ogra_ has never seen such behavior and wouldnt think its possible at all
<cjwatson> At what stage?
<ogra_> boot
<ogra_> initial boot
<cjwatson> Yes, see e.g. rootskel/src/sbin/console-type.c
<cjwatson> And rootskel/src/lib/debian-installer/detect-console-linux
<cjwatson> In fact just generally grep around in rootskel :)
<ogra_> hmm
<ogra_> all that code shouldnt switch to fb then
<ogra_> weird
<utlemming> stgraber: can you add http://cloud-images.ubuntu.com/quantal/20120925 to the tracker please?
<hggdh> ogra_: ah, I wonder if the tests I am running automagically have something to do with it
<stgraber> utlemming: sure
<doko> dobey, build succeeded
<Laney> has queuebot gone mad?
<cjwatson> Looks like it - same package disappearing and reappearing
<skaet> wierd....what's going on with the queue?  some of those are seeded, and thought they were going to be after beta 2.
<stgraber> skaet: don't worry, they haven't been accepted. When something disappears from the queue and isn't rejected queuebot assumes it's been accepted
<stgraber> which means that when LP API is glitching and returns a subset of the queue, it marks a bunch of packages as accepted
<Daviey> MAD!
<cjwatson> skaet: If you see the same package version being accepted and then shortly afterwards reappearing, you can safely assume that it hasn't actually been accepted.
<stgraber> ~ubuntu-archive: Can someone review and merge: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/amis-add-argparse/+merge/126494 ?
<cjwatson> doing
<cjwatson> stgraber: well, I know argparse is the new hotness, but perhaps it would make sense to use optparse instead to match the rest of ubuntu-archive-tools?
<cjwatson> dunno.  not hugely fussed, it just jumped out as different
<stgraber> cjwatson: well, I grepped for argparse and saw that control-builders was using it, so just went with it :)
<cjwatson> ah, ok
<cjwatson> seems fine anyway, will merge
<stgraber> also, optparse is deprecated, so I guess we should try to get rid of it as we move to python3
<cjwatson> I don't think it's urgent since 3.2 has it, but yes
<cjwatson> merged
<skaet> thanks stgraber, cjwatson - ok,  anxiety levels decreasing ;)
<stgraber> cjwatson: thanks
<doko> 3.3 still has it
<dobey> doko: great, thanks again.
<kenvandine> skaet, i just uploaded webapps-applications and libunity-webapps that fix bugs i would really like to see in b2
<kenvandine> one will prevent users from getting duplicate launchers for u1ms
<kenvandine> there they are :)
<kenvandine> i need to run out for an appointment now though
 * kenvandine runs
<hggdh> ogra_: yes, the tests destroy mmcblk0. Red herring
<ogra_> ohew, thx
<ogra_> *phew even
<ogra_> cjwatson, hmm, did your python porting of cdimage change anything in the zsync logic by chance ? zsyncing the ac100 tarball tells me there is no former image and then it starts to download the file as tar (vs tar.gz) ... specifiying the existing file with -i makes it work as expected
<xnox> there are now one python-twitter to many in the unapproved queue. Feel free to reject one of them.
 * xnox still didn't get emails about either of them =(
<iulian> Why do we have python-twitter showing up twice in the queue?
<iulian> Same version.
<xnox> iulian: see my comment above.
<xnox> iulian: i syncpackage twice, cause I didn't get an email about the first one, nor the second one, then checked the queue and noticed duplicate.
<iulian> Whoops. Clearly missed that.
<iulian> Okey-dokey. Will reject one of them then.
<xnox> iulian: cheers =)
<ogra_> ###################- 95.4% 0.0 kBps aborted
<ogra_> failed to retrieve from quantal-preinstalled-desktop-armhf+ac100.tar.gz
<ogra_> GRRRR !
<xnox> ogra_: I zsync armhf without a hitch for a while now..... on daily basis along with other images. Didn't hit any problems....
<ogra_> xnox, not the tar.gz for ac100 i assume
<ogra_> thats special :)
 * ogra_ wipes and wgets instead, seems zsync is now stuck at that 95.4% and fails every time
<cjwatson> ogra_: Well, I certainly had to rewrite all that code, but I didn't intend to change its behaviour.  I have a child on my lap at the moment, but I'll look later.
<ogra_> cjwatson, no hurry
<ogra_> i can also look myself later you are loaded enough
<ogra_> i doubt there are many people zsyncing an image for a rare and discontinued device anyway :)
<cjwatson> Maybe not, but I don't like regressions even if they're only currently known to affect something rarely used. :-)
<ogra_> heh, ok
 * ogra_ needs to familiarize with the python port though 
<balloons> btw, ty for keeping the notice board updated on the respins
<skaet> yw
<skaet> hmm... and on that note...  all the respins that comment referenced are done.   cleaning it again.
<skaet> cjwatson, ogra_, infinity - what's the story with netboot now?   we going to ship with what we have?
<cjwatson> my side of it is that my test install was 6h remaining last I looked at it (an hour or two ago), but ogra_ had a flash-kernel upload in the queue correcting that side of it
<cjwatson> I haven't reviewed that yet, but will do within an hour or two
<skaet> thanks cjwatson.
<cjwatson> any other installer insanities you know of that I need to look at tonight?
<cjwatson> we have a bunch of stuff queued in -tracking, but it didn't look critical ...
<skaet> there was a set that jibel was highlighting,   just a sec, and I'll review, and paste any relevant ones here.
<cjwatson> the accessibility indicator translations one looked fairly easy - just awaiting a slot to start up a test vm on my laptop for that
<cjwatson> generally the usual bunch of missing translatability in a few places
<skaet> bug 1055326
<ubot2> Launchpad bug 1055326 in ubiquity "During installation, flashplugin fails to install with: IOError: [Errno socket error] [Errno -2] Name or service not known" [High,Triaged] https://launchpad.net/bugs/1055326
<skaet> bug 1046744
<skaet> oops
<skaet> bug 1056744
<ubot2> Launchpad bug 1056744 in ubiquity "Ubiquity crashes after creating an encrypted partition manually" [Undecided,Confirmed] https://launchpad.net/bugs/1056744
<skaet> Bug 1056707
<ubot2> Launchpad bug 1056707 in ubiquity ""Unsafe swap space detected" dialog displayed too late if swap is created after an encrypted partition and makes manual partitioner unusable" [High,Triaged] https://launchpad.net/bugs/1056707
<skaet> Bug 1056689
<ubot2> Launchpad bug 1056689 in debian-installer ""Incomplete language support" for english after netboot installation" [Medium,New] https://launchpad.net/bugs/1056689
<cjwatson> OK, thanks.  I'll have a look over those.  None of them look respin-worthy to me, really.
<skaet> release noting may be the only option at this point for beta 2 - but they should all be sorted before the release.
 * skaet nods
<cjwatson> I agree that at least the first three need to be fixed for release.
<cjwatson> The fourth is untidy, but it wouldn't be the first time ... Medium's probably correct there.
 * skaet nods
<cjwatson> The first is annoying because I thought we had systematically fixed that entire class of bugs in 12.04 ...
<cjwatson> Oh well.
<cjwatson> And the second and third would appear to be xnox's headache :-), although I'll pitch in if I have time
 * skaet feels xnox will need much beer in UDS.  ;-) 
<skaet> sounds good.   thanks.
<cjwatson> I certainly plan to buy him some.
<skaet> Me too :)
 * skaet removing Kubuntu Alternate from the beta 2 set,  based on earlier discussions with Riddell
<Laney> hey
<skaet> Kubuntu is dropping alternates from the Manifest for 12.10 now.    I've updated the release manifest.
<skaet> Laney,  ??
<Laney> just saying hi :(
<infinity> How dare you?
<infinity> Back in your cage.
<Laney> Shan't make that mistake again
<skaet> sorry Laney.   thought you were concerned about the Kubuntu changes.  ;)
<skaet> Laney,   was looking into the rdepends on that  gnome-session 3.6 http://git.gnome.org/browse/gnome-session/commit/?id=17b0b11 (non translations part),  and am not comfortable judging the risk of it interacting with Ubuntu/Edubuntu existing images.    Did you have a look at that aspect when discussing earlier?
 * skaet marked it as a FFE since its a new upstream version effectively.
<infinity> Hrm?
<infinity> All of GNOME has a standing exception to bring it to the stable versions before release.
<skaet> infinity, any issues being raised you're concerned with at this point for the beta 2 images?
<infinity> Or did you mean specifically for the beta?
<skaet> for the beta
<infinity> Ahh.
<Laney> Well, not an exception, but their release policy aligns with ours (by design) so we don't need to seek them.
<skaet> Laney, Infinity - https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1056936
<ubot2> Launchpad bug 1056936 in gnome-session "[FFE] GDM 3.6.0 won't start without gnome-session 3.6.0" [Critical,Confirmed]
<Laney> yes
<Laney> jbicha tested launching sessions with the new package and lightdm
<skaet> in Ubuntu as well as in his remix?
<Laney> yes
<skaet> If he can document it in the bug that both have been tested,  and you're comfortable documenting that the diff (other than translations) won't lead to regressions,  my concerns will be addressed.
<kenvandine> skaet, i just uploaded the fix for your target of opportunity bug 744812, but definitely wait until after beta2 to let it in
<ubot2> Launchpad bug 744812 in ubuntu-font-family-sources "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [High,Confirmed] https://launchpad.net/bugs/744812
<skaet> kenvandine,  ack.    Did the libreoffice issues get addressed?
<kenvandine> not sure
<kenvandine> i wasn't paying attention to that one
<phillw> cjwatson: do you promise not to kill me if I ask you about a bug? :)
<kenvandine> seb128, ^^
<jbicha> Laney: skaet: yes, I mentioned my testing on comment 6 of the gnome-session/gdm bug
<Laney> I can't promise no problems, but it seems fine to me.
<seb128> kenvandine, skaet: Sweetshark is still working on libreoffice, we are still aiming for an upload just after beta2
<Laney> I'm sure doko will love a qt4-x11 upload :P
<seb128> lol
<skaet> jbicha,  comment #6 doesn't say if you tested it in Ubuntu as well as the Gnome remix,  want to make sure no regression surprises that's the key thing.
<skaet> jbicha
<skaet> nevermind
<skaet> I need to take a break from bugs - you did say,  I just didn't read properly.
<jbicha> I have almost all of ubuntu-desktop installed currently for ubuntu-docs work
<skaet> Laney,  you ok with that diff?
<Laney> skaet: as much as I can be by just reading it
<balloons> everyone note, I finally landed a first pass at  Install (entire disk with lvm and encryption)
<skaet> :)
<balloons> it's only on ubuntu desktop atm, and I of course had lots of results from looping through it
<balloons> anyways, we'll continue to work on isolating the specific testcases in ubiquity to make testing and maintaining the cases as easy as possible.. for now, enjoy
<skaet> jbicha,  its approved
<cjwatson> phillw: Man, do I come across as that touchy?  I've not killed anyone yet. :-)
<cjwatson> phillw: But I'm watching House for the next hour or so.
<highvoltage> cjwatson: eek, be careful, before you know it you'll start to say things like "you're all idiots"
<Daviey> If House affects you, like everyone else.. I'd be expecting well thought through sarcastic, but whity, insults.
<phillw> he he... It does appear your thoughts on the issues are correct. I was alerted to bug 1043518 which took me to https://bugzilla.redhat.com/show_bug.cgi?id=857300 from my very limited skills, it does seem that there is a kernel fix?
<ubot2> Launchpad bug 1043518 in ubiquity "live cd is unusable due to video degradation with the splash boot option enabled" [High,Confirmed] https://launchpad.net/bugs/1043518
<ubot2> phillw: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found (https://bugzilla.redhat.com/xml.cgi?id=857300)
<phillw> most odd, ubot found it on -testing
<Laney> he /is/ a DD, though. You know what they're like.
 * infinity glares at Laney.
<Laney> jbicha: ^ go wild
<jbicha> yay! thank you!
<doko> Laney, well, if there's' an upload, let's build it without -g on arm*
<Laney> doko: go ahead and reupload. We can then reject the old one
<doko> tomorrow ... need to figure out how to build without -g. but you did it recently, didn't you?
<Laney> using filter-out
<doko> that easy? ok. and I would like to see this python2.7 upload building in -proposed while the archive is frozen
<infinity> Do we really need to go all the way to removing -g?  Maybe -gstabs would be enough?
<doko> already checked by Laney in webkit
<Laney> I'll do a PPA upload to be sure
<cjwatson> phillw: Not sure really - I know very little about this area, sorry.  Try #ubuntu-kernel?
<cjwatson> phillw: The linked kernel patch indeed looks pretty straightforward and easy to pull in, if that's in fact what it is.
 * infinity accepts some things into proposed...
<phillw> cjwatson: except that 12.10 is running 3.5.x :'( I did ask. also, what are the chances of having ppc run with nomodeset, that seems to be the best work around we have at present.
<phillw> cjwatson: it is 3.6.x, and will not be available for 12.10
<cjwatson> phillw: No obvious reason why that would stop the kernel team pulling in that one patch.
<cjwatson> I'd rather not force nomodeset for a whole architecture.  This stuff is generally chipset-specific.
<phillw> cjwatson: do you know anyone I could go beg? ( I am good at begging, and it does seem a fix that would remove a lot of issues... or at least give us a level playing field).
<cjwatson> phillw: #ubuntu-kernel, as I said ...
<phillw> My concern, obviously, is any regression issues.
<cjwatson> I don't know which individual on the kernel team would be relevant, and that's not usually the right answer anyway
<cjwatson> Let them judge that.
<phillw> cjwatson: thanks, I'll go ask again - maybe my 1st question was phrased incorrectly.
<cjwatson> phillw: Yes, it was.  You asked about an entire new kernel release, not a singlel patch.
<cjwatson> *single
<cjwatson> For a one-line patch, while this isn't my field, it seems unlikely that an entire new kernel release is necessary.
<cjwatson> Sledgehammers and nuts, etc.
<infinity> Bad mental image.  Curse American slang.
<cjwatson> Sigh.  My n-hour armhf/omap test install failed due to random network glitch.
 * cjwatson reviews ogra_'s patch.
<skaet> infinity,  are the scripts ready for tomorrow for moving the armhf and amd64+mac images to publish in same location now as the amd64, i386 ones for Ubuntu/Ubuntu Server?
<cjwatson> cdimage doesn't care; that would be a matter of a publish-image-set change.
<cjwatson> Probably something like http://paste.ubuntu.com/1229408/, but review the results of that ...
<infinity> skaet: I hadn't changed publish-image-set yet, but I imagine Colin's diff is sane.
 * infinity looks.
<infinity> cjwatson: Looks sane to me, if you want to commit it, I'll dry-run it and see if it does what it looks like it should.
<skaet> thanks.
<cjwatson> What about server armhf+omap?
<infinity> cjwatson: Just omap4's going to releases, AFAIK.
<cjwatson> Actually, let me be a little more subtle, or else this'll affect 10.04.2 too.
<infinity> cjwatson: It would only affect .2 if we built those images.
<cjwatson> Well, I've done the work now :)
<infinity> cjwatson: (We're not building ARM images for .2, not sure about +mac, but if we're building +mac, I'm not sure publishing it to releases for .2 would be awful and wrong anyway)
<cjwatson> r619
<cjwatson> feel free to tweak
<infinity> That works too.
<cjwatson> ogra_,plars: That flash-kernel upload looks good, so I've accepted it into -proposed.  Once it's built and published (~ an hour, maybe a bit more for safety - check 'rmadison -s quantal-proposed -S flash-kernel' against https://launchpad.net/ubuntu/+source/flash-kernel/3.0~rc.4ubuntu26), please could you try a test install with 'apt-setup/proposed=true' added as a boot parameter?
<cjwatson> (I know, -proposed isn't for manual testing, but I wouldn't be copying it to quantal semi-automatically anyway during a freeze.)
<cjwatson> I give up on my own manual test; it's just taking way too long.
<smoser> anyone able to help?
<smoser> i go to http://iso.qa.ubuntu.com/user
<smoser> (to get my api keys)
<smoser> and "Access denied"
<smoser> (I get there by clicking "Hello smoser", so yes, i'm logged in)
<smoser> i log out and log back in. it acknowledges im' me, but /user gives 403
<infinity> Ditto for me.
<infinity> stgraber: ^
#ubuntu-release 2012-09-27
<cjwatson> Meh, every time I'm working this late I get tempted to kill my nightly backups so that I can have some I/O.
<smoser> anyone else able to help with that?
<smoser> the access denied issue?
<smoser> well, i'm out for the night.
<smoser> if anyone else has their api keys and wants to follow bzr+ssh://bazaar.launchpad.net/~smoser/+junk/jenkins2isotracker/ to post results for ec2, they could do that.
<smoser> the values you need are:
<smoser> serial=20120925; release=quantal; mstone='Quantal Beta 2'; url='https://jenkins.qa.ubuntu.com/view/Quantal/view/All%20Quantal/job/quantal-server-ec2/18/'
<highvoltage> skaet: should beta2 tech overview include the notes from beta1?
<highvoltage> stgraber: I added that 2 items we discussed earlier and removed the obvious ones from the packages list (from the conflicts list in edubuntu-live), there's not really a lot but the list should probably be even shorter: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta2#Edubuntu
<ScottK> highvoltage: You want the tech overview to be readable for someone upgrading from Precise, so it should cover everything from that angle.
<stgraber> smoser: http://iso.qa.ubuntu.com/qatracker/api ?
<stgraber> smoser: /user is blocked as it's not relevant when using SSO (that page would usually let you change your password and other details that we get from SSO)
<stgraber> I have a few bug reports to try and make that part a bit better (ideally, without having to patch Drupal's code...)
<skaet> Daviey, we're still missing some of the Ubuntu Server test results on the iso tracker,  can you look into getting them run and the results added to the tracker?
<Daviey> skaet: yep!
<slangasek> seb128: ^^ something for you
<slangasek> seb128: testing it should be as simple as building and installing the package and logging back in
<knome> skaet, i've updated https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta2 - sorry for being late for that.
<knome> skaet, it also looks like there's problems with reporting our post-installation/desktop tests to the tracker, and we don't have any tests for those because of that; but, i'm signing off both images
<cjwatson> ogra_: any luck with testing flash-kernel?
<ogra_> running since a while
<ogra_> even with local mirror it takes ages ...
<ogra_> (i had hoped paul had done it, butu doesnt seem like)
<ogra_> cjwatson, debian-installer-utils uploaded to proposed for bug 1028905
<ubot2> Launchpad bug 1028905 in debian-installer-utils "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
<ogra_> cjwatson, and my netinstall just asks me about UTC clock settings (so it passed flash-kernel-installer)
<ogra_> yup and rebooted just fine
<cjwatson> OK, great.  I'll copy flash-kernel now then.
<cjwatson> Not sure there's much point using -proposed for debian-installer-utils, since it doesn't have arch skew problems and it needs a d-i rebuild anyway.
<cjwatson> But I can review it there anyway ...
 * smartboyhw hopes that scott-work will show up today to say that Ubuntu Studio beta 2 is ready:P
<knome> smartboyhw, since you've been monitoring how it comes up and scott not, how do you think he'd know better than you?
<ogra_> cjwatson, well, i thought i'd rather drive safe and take proposed before anyone shouts that i broke a policy or so :)
 * smartboyhw thinks that he does NOT have sign-off rights:P
<ogra_> we are still frozen after all :)
<knome> smartboyhw, if scott doesn't turn up, then you probably have to make the decision :P
<smartboyhw> knome: Ooh:P
<cjwatson> ogra_: Oh, I spotted a mistake
<cjwatson> ogra_: You need a $ at the end of that regexp
<cjwatson> In practice I don't see any partition types we care about that would be mishandled due to that, but I'd rather be safe
<ogra_> ok
<cjwatson> So I'll reject that for now, please fix and reupload :)
<cjwatson> Looks fine otherwise
<ogra_> should i force overwrite the debcommit or just add the change on top in the branch ?
<cjwatson> Either; just make sure the tag is accurate
<ogra_> k
<ogra_> cjwatson, bah, there isnt a tag for your last upload it seems
<cjwatson> Huh, that's odd
<cjwatson> Is now
<ogra_> thanks
<ogra_> hmm, i cant do a push --overwrite it seems
<cjwatson> unbind first
<ogra_> ogra@anubis:~/Devel/branches/debian-installer-utils$ bzr unbind
<ogra_> bzr: ERROR: Local branch is not bound
<ogra_> *sniff*
 * ogra_ wonders if thats another fallout of two factor auth ... i have nothing but probs with it
<ogra_> though i can push normally ... (complains about diverged branches indeed) just not with --overwrite
<ogra_> ssh_exchange_identification: Connection closed by remote host
 * ogra_ scratches head
<ogra_> oh, wait
<ogra_> hmm, no
<ogra_> ogra@anubis:~/Devel/branches/debian-installer-utils$ bzr push lp:~ogra/ubuntu/quantal/debian-installer-utils/ubuntu
<cjwatson> you could try uncommitting from the remote branch instead
<ogra_> ssh_exchange_identification: Connection closed by remote host
<ogra_> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<ogra_> if i only could
<ogra_> i cant even push to my own account now it seems
<cjwatson> try killing off any stray bzr and ssh processes
<smartboyhw> skaet: Signoff of Beta 2 starting in er like 7 minutes?
<ogra_> none there
<knome> smartboyhw, ending.
<smartboyhw> Ooh
<ogra_> ogra@anubis:~/Devel/branches/debian-installer-utils$ bzr uncommit lp:~ubuntu-core-dev/debian-installer-utils/ubuntu/
<ogra_> ssh_exchange_identification: Connection closed by remote host
<ogra_> uncommitting remotely has the same issue
<ogra_> i have a pending reboot from yesterdays upgrade, lets see if rebooting helps probably
<cjwatson> You'll have to ask #launchpad (public) or #launchpad-ops (internal)
 * smartboyhw finds out that #launchpad-ops has no one there
<cjwatson> internal
<cjwatson> ogra_: Somebody else is reporting a similar problem on -ops, so it may not be just you
<cjwatson> ogra_: Try again no
<cjwatson> *now
<ogra_> cjwatson, heh, ok, at least i did my reboot for the new kernel now :)
<ogra_> yippie, all good :)
<ogra_> and re-uploaded
<smoser> stgraber, sorry for being a dolt. i had clicked on api too. i just saw the "Intrdocution" and assumed it was just doc.
<skaet> Daviey,  plars - any ETA on when those missing server tests will be complete?
<plars> skaet: hggdh ran what he could of the maas tests yesterday, but I don't think he has everything he needs to run all of them. My understanding is that someone from server team normally does this? Same for iscsi
<skaet> Riddell,  the Kubuntu images for powerpc and amd64+mac don't have results -  are they likely to get some in next little bit, or remove them from list for beta 2?
<skaet> Daviey, ^  ??
<jibel> skaet, plars https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalBeta2TestReport
<Riddell> skaet: I'm happy enough for them to be removed
<skaet> Riddell, ok,  doing.
<skaet> thanks jibel
<skaet> vanhoof, infinity, plars - the netboot images look like they still need some testing -  what's the outlook on them?
<skaet> knome,  thanks for the update.  If there are post install issues,  please mentiong them in the TechnicalOverview/Beta2.   Marking your images ready now too.
<ogra_> skaet, a fix for arm netboot is in the archive, but would require a d-i rebuild, not sure what colin plans here
<skaet> cjwatson,   ^  release note,  and make available shortly after?
 * ogra_ wouldnt mind to skip them given the fix will be inthe next build anyway
<cjwatson> No, it does not require a d-i rebuild
<cjwatson> flash-kernel is not in the initrd
<cjwatson> It should be available for netboot installations now
<ogra_> ugh, soryy, i mixed up the two fixes :)
<cjwatson> Thus I don't see a need to release note
<ogra_> yeah
<ogra_> sorry, sorry
<skaet> ok.   thanks cjwatson, ogra_
<popey> skaet, i have a new UIFe for you :S https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1056901
<ubot2> Launchpad bug 1056901 in unity-lens-shopping "[UIFe] Display category emblems on results" [High,In progress]
<popey> (you need to look at the far right end of the orange price strip to see the change (which eluded me initially))
<skaet> Laney,  can you review the new incoming from popey?   my bandwidth right now is focusing on getting beta 2 ready and figuring out what we'll ship or not.
<popey> thanks skaet, sorry to lay more on you..
 * skaet keeps up her pinging  :P
 * smartboyhw is seriously wondering why scott-work hasn't said a word since he came:P
<skaet> Riddell,  one of the missing netboot tests, is installing Kubuntu - has anyone tried that yet?
<ogra_> smartboyhw, if someones client conncts that doesnt necessary mean there is a person attached to it ;)
<smartboyhw> ;)
<ogra_> *necessarily
<Riddell> skaet: fooey didn't notice that, I can give it a go
<skaet> smartboyhw,  scott-work - are there more results about to be posted for ubuntu-studio?
<skaet> thanks Riddell
<smartboyhw> skaet, don't think so......
<smartboyhw> We don't have that much testers:P
<skaet> smartboyhw,  then probably we won't ship this time around.   Manditory tests should be completed.
<smartboyhw> skaet, that is real difficult......
<smartboyhw> Then we won't have any builds to ship, we just don't have enough testers to complete ALL of them
<plars> skaet: for netboot, you are referring to the kubuntu and xubuntu netboot tests?
<skaet> plars,  yes,  Riddell says he'll handle kubuntu,  and if that's ok,  then we'll assume xubuntu likely is.
<smartboyhw> skaet, I will just go and run the tests now
<skaet> smartboyhw,  ok.    I'll hold off on the decision to ship/not from my perspective as long as can.
<skaet> but we won't be holding up the release for it.
<smartboyhw> skaet, OK
<skaet> balloons,  can you fix http://iso.qa.ubuntu.com/qatracker/milestones/238/builds/24227/testcases for quantal?  upgrading from lucid doesn't make sense as a test for quantal.   (Daviey,  sound out if you disagree)
<Laney> popey: is it entirely necessary?
<Laney> the tweaks don't seen to be stopping.
<balloons> skaet, ohh.. I thought we fixed that
<balloons> ohh.. server
<popey> Laney, It certainly improves the user experience. I'd imagine people are going to appreciate pre-filtering amazon results they may click on by these visual cues.
<skaet> yup, server
<balloons> give me a few
<Laney> I should hope that you think all changes improve the user experience :-)
<smartboyhw> skaet, can you give me an approximate time for us to complete the testcases before you call it off?
<Laney> jbicha: tell me what you think about the prospect of another shopping lens uife ;-)
<jbicha> Laney: what do they want this time?
<Laney> to add 'emblems' to the amazon results
<Laney> which indicate the category it came from
<skaet> smartboyhw,  you've got at least an hour,   was expecting the results in by 1200 UTC so we wouldn't be doing this dance.  Beyond that variable.
<smartboyhw> skaet, thanks
<stgraber> skaet: Edubuntu should be all good, we have ISO and upgrade test results, tech overview was done by highvoltage and the bug listed in the release notes is still relevant. We won't have a blog post for beta2, so just link to http://www.edubuntu.org as usual.
<Daviey> skaet: no eta yet
<jbicha> Laney: well we don't have screenshots of the shopping lenses, but it'd be nice if the UI stopped changing for the ubuntu-manual guys & such
<Laney> Yes. And it would be nice if the exceptions stopped coming and sucking up the release, doc and translation team's time
<Laney> jbicha: https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1056901
<ubot2> Launchpad bug 1056901 in unity-lens-shopping "[UIFe] Display category emblems on results" [High,In progress]
 * Laney wonders how far the word 'exception' can be stretched
<skaet> Daviey,  ack.    you're on critical path for release timing now.
 * smartboyhw too
<stgraber> Laney: for unity-lens-shopping it's surely not an exception ;) every single upload of that source were past FF/UIF...
<ScottK> Right.  That's the problem.  For certain teams they operate (for whatever reasons - not always in there control) as if exception was normal.
<ScottK> Laney: You can always say no and see if sabdfl really wants it.
<Laney> there's this one too https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1055684
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
<Daviey> skaet: woot!
<jbicha> I bet we're going to get more of these exceptions next week too
<skaet> thanks stgraber, highvoltage - appreciate Edubuntu being ready to go by 1200 UTC.
<Laney> skaet: I think we should start turning these requests down
<xnox> skaet: Daviey is all dressed up for beta2 =) or is it the London OpenStack meeting.... not sure now
 * xnox live from the office
<ScottK> skaet: I think it's time to start saying no on non-essential U/I changes (I think the online search privacy change and the https change are essential - none of the rest are).
<highvoltage> skaet: :)
<smartboyhw> Studio amd64 ready to go, download i386 ISO ETA 4-8 minutes
<stgraber> I'd argue that bug 1055684 should be fixed as it definitely looks like a bug to the user (http://cloudfront.omgubuntu.co.uk/wp-content/uploads/2012/09/unity-shopping-preview.jpg)
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
<stgraber> however I agree that the rest of the visual tweaks can certainly wait till R
<highvoltage> why can't you just make people who land late features take responsibility for them? like, if you want to introduce a UI change 2 weeks after UI freeze you should be the one taking screensots of it in 63 (or how many it is these days) languages
<highvoltage> (I guess that's maybe somewhat harsh)
<skaet> Laney, ScottK - please add your comments to the bugs in question,  and I'll do my homework enough for an opinion as soon as we get this Beta2 out the door.   I'm agreeing its gotten way too late for tweaks, but don't want to comment further until I actually can focus and read them.
<ScottK> Sure.
<Laney> stgraber: feel free to take it on (in fact, please do)
<tumbleweed> stgraber: or just consider it to be still too buggy for release, and remove it
<popey> thanks for the consideration
<jbicha> tumbleweed: :)
<tumbleweed> no really, I don't know why we aren't considering that as an option. It's a totally real and useful one
<Laney> no it's not a real one
<Laney> it's out of the release team's hands, so to speak
<stgraber> tumbleweed: I'd be happy with that option if it wasn't for the whole getting sabdfl'ed and ending up with more changes than we're talking about at the moment...
<stgraber> considering the changes independently we can at least hope to postpone some of them...
<tumbleweed> yeah, it sounds like it's mostly there (And I don't recall seeing explicit sabdfling, but assumed it was behind the scenes somewhere)
<jbicha> Laney: I believe the Release Team does have that authority
<ScottK> We certainly do.
<Laney> it's already a sabdfled feature
<ScottK> tumbleweed: sabfling only counts if it's explicit and on the record.
<ogra_> so why do you complain
<ogra_> nothing to discuss if it was sabdlfied
 * smartboyhw is now rushing to get the i386 studio testing completed.......
<ScottK> I've seen Mark rip someone's head off for trying "Mark told me it had to go in" on the release team.
<highvoltage> ScottK: right, that was passed by the CC a while ago, but I haven't actually seen any bugs or docs for any sabdflifications
<ogra_> well, but the sabdfl override is a real thing that was defined in ubuntu from day one, if it is used it should simply be noted as that
<ScottK> ogra_: Yes, but he has to actually do it explicitly.
<ogra_> and everyone (including sabdfl) should just move on and accept the policy
<ogra_> else it is pointless to have it
<phillw> skaet: lubuntu won't release beta2 ppc, too many gremlins. Others are okay to throw out in the wild :)
<Laney> regardless of that, all of these later requests are certainly within our jurisdiction
<ScottK> Certainly.  I have my opinion about it, but I don't argue it's the policy and he has the authority.
<ScottK> Laney: Precisely.
<skaet> thanks phillw,   was wondering about those ppc images.
<ScottK> BTW, I put NACK comments on the two bugs.
<Laney> thanks
<ogra_> phillw, oh, btw, do you plan to have a lubuntu slideshow ?
<ScottK> I didn't mark the wontfix (although I could have) because skaet said she wanted to look at them later.
<ogra_> looks a bit odd with all the ubuntu advertising
<jbicha> the sabdfl override isn't really documented in the usual places, like https://wiki.ubuntu.com/FreezeExceptionProcess is it?
<phillw> we#re hoping for a kernel fix which re: bug 1043518
<ubot2> Launchpad bug 1043518 in linux "live cd is unusable due to video degradation with the splash boot option enabled" [High,Fix committed] https://launchpad.net/bugs/1043518
<scott-work> skaet: how soon do the remaining tests for studio need to be done? btw, i saw your email earlier but work is busy, busy these days
<ogra_> (especially since none of the apps is installed)
<smartboyhw> scott-work, I am doing the i386 tests, at most 20 minutes to be completed
 * scott-work picked up more responsibilitys (but no extra pay) when my boss was removed
<smartboyhw> scott-work, LOL
<ogra_> jbicha, no, its somewheer documented wheer the term is also exoplained
<tumbleweed> jbicha: a sabdfl override is usually a comment from him on the FFe bug, acking it (in my experience)
<skaet> scott-work,  we're waiting on Daviey now at this point,  so if you can get them done before then,  you should be good.   smartboyhw is working on them.
<phillw> ogra_: afaik, one is being done. I can go poke the ML as I'm not sure who is doing it.
<ogra_> ah, cool
<ogra_> phillw, apart from that, great work, lubuntu gave me a nice new home for the ac100 :)
<highvoltage> ogra_: sabdfl and the CC did agree that all sabdfl decisions has to be logged somewhere to avoid people randomly claiming that something was an sabdfl request (and other problems)
<ogra_> highvoltage, ah, so it has been handled
<cjwatson> phillw: You understand that that kernel fix only affects nvidia systems, right?
<scott-work> thank you smartboyhw and skaet
<cjwatson> Just in case you'd related it to the Radeon bug cluster somehow.
<skaet> scott-work,  can you take a pass at TechnicalOverview/Beta2 page and make sure any new features/key fixes for Ubuntu Studio have been added.
<skaet> ?
<scott-work> i will do that in about an hour, skaet
<skaet> thanks scott-work
<ScottK> jbicha: Mark can sabdfl anything in the project.  It's not just about freeze exceptions.
<ScottK> stgraber: Re 1055684 - It looks like we collided.  I get your point, but I think we need to draw a line in the sand on non-critical U/I tweaks.
<phillw> cjwatson: yes, for the liveCD only nvidea is affected, so there would be no need to mess with nomodeset etc.
<smartboyhw> skaet scott-work testing finished results passed marked in ISO Tracker ALL READY
<skaet> thanks smartboyhw
<smartboyhw> NP skaet
<cjwatson> phillw: Right, except many of the powerpc bugs were about radeon.  Just want to make sure there's no false hope here.
<skaet> utlemming,  there are 3 cloud images with no results.   Is there an ETA for those?
<phillw> cjwatson: that is possibly another kernel issue, or maybe fixable by x-org. Oncee the B2's are out of the way I'll go see what the consensus is between the two teams :)
<smartboyhw> thanks skaet for marking it ready:P
<cjwatson> phillw: *nod*
<skaet> cjwatson,  thanks for the tweaks to the TechnicalOverview earlier.    Are there any more that need to be added from the foundation team perspective?
<cjwatson> I didn't have anything at this point
<skaet> arosales, smoser - do you have any info on those 3 cloud images without test results - should they ship or not?
<smoser> utlemming, ^
<skaet> ok thanks cjwatson.
<smoser> he's getting them i think
<skaet> smoser, ok - just hadn't heard back from my earlier ping to him, so wasn't sure if he was on it or not.
<chrisccoulson> can someone please reject the firefox upload in quantal-proposed?
<popey> Laney, I have updated the bug, it may not have been clear initially, the emblems are already in Ubuntu, this bug fixes an inconsistency between the music/video lenses and the dash.
<Laney> popey: ScottK took it over.
<Laney> chrisccoulson: yeah
<chrisccoulson> thanks
<popey> ok, ScottK ^^ :)
<Laney> kaboom, it falls down
<balloons> skaet, so the server upgrades are "fixed".. they are pointing at the desktop upgrade case though. .it seems we don't have a different server upgrade case
<balloons> I'm sure Daviey and I can come up with any minor tweaks and create one
<ScottK> popey: skaet is going to review the FFe's in question after Beta 2 is out and make a final decision.  To me it seems non-critical and I think it's too late for non-critical.
<popey> noted ScottK, thanks
<skaet> balloons,  can you work with Daviey then after this release is out to get an appropriate test case in there.   (Since he's a member of release team, and has a vested interest in Ubuntu Server)
<balloons> skaet, yes of course.. it's status quo. the legacy cases also pointed at the desktop upgrade case
<skaet> s/release/beta2 release/
<smartboyhw> It seems like there is goign to be a ninth member of testcase admins team then:P (aka Daviey)
<balloons> smartboyhw, Daviey is a member of the release team.. He has super cow powers
<smartboyhw> Super cow:)
<cjwatson> smartboyhw: apt-get moo
<skaet> release team members and flavor leads,   could I ask you all to take a read through the current test cases on the iso tracker and make sure they make sense from your perspective.   Goal here is to make sure the set of manditory test cases is truly manditory,  and we're not including manual testing that doesn't add value.  Similarily,   if there are areas where we should be adding test coverage,  please add the test
<skaet>  cases (I'm thinking of earlier comments from knome).
<utlemming> skaet, arosales: Beta2 Cloud images are all tested -- results look good.
<smartboyhw> Why is everybody apt-get moo at me?
<utlemming> skaet, arosales: the cloud images can be marked ready
<skaet> thanks utlemming
<cjwatson> skaet: Let me know when you think we can start flushing the upload queue due to being past the point of no return
<cjwatson> I'd like to do that under supervision so that I can make sure the timeout-avoidance code works
<skaet> cjwatson, will do.   Just waiting for Daviey to let us know about the missing tests from Ubuntu Server.
 * cjwatson accepts some unseeded things in the meantime
<cjwatson> (xorg-server wasn't me)
<cjwatson> Oh, it also apparently wasn't actually accepted.  OK
<Laney> heh
 * stgraber really needs to figure out what's going on with queuebot when queues are too long...
<skaet> +1
<xnox> queuebot has became a practical joker like that AI super computer in I, Robot.
 * smartboyhw wonders what happened to the Ubuntu Desktop upgrade amd64 not marked ready
<skaet> smartboyhw,  oversite.  fixing
<stgraber> patched queuebot to actually check for the record status instead of assuming that !rejected == accepted and have it discard the data it receives from LP if the package status don't make sense
<stgraber> hopefully that should fix the problems or at least let me figure out what's going on
<cjwatson> great, thanks
<smartboyhw> skaet, please explain what is oversite to me;P
<ogra_> missed
<cjwatson> typo for oversight
<cjwatson> (which may help non-native speakers)
<smartboyhw> Ah:P
<plars> skaet: not sure if someone is already on it, but I'm trying to work out the iscsi tests
<skaet> plars,  thanks.  Daviey,  if someone else is already doing the ISCSI tests,  please let plars know.
<skaet> sorry smartboyhw,  my bad.
<smartboyhw> :)
<plars> Daviey: even if not, it would still be helpful to have someone else looking at it too, as I've just now installed iscsitarget on a local machine to try to muck through it
<infinity> Good morning.
<smartboyhw> Hello infinity
<skaet> hello infinity,   do we ship powerpc server image or not?
<skaet> it doesn't have all its tests done,  but its common code with the rest that seems fairly well tested.
<skaet> http://iso.qa.ubuntu.com/qatracker/milestones/238/builds/24193/testcases
<infinity> skaet: All its tests aren't really necessary for an unsupported port, IMO, as long as someone's tested that the ISO works at all.
<infinity> skaet: And it looks like someone's tested that it boots and installs, and those passed, so that's enough for me.
<skaet> infinity,  ok,  can you work with balloons after beta2 is out to get the set of manditory test cases adjusted to what is truly manditory.
<skaet> for the final release,  all manditory will need to be run,  as well as all run once.
<phillw> skaet: the issues we're seeing with ppc seem to be 'X' related (even though kernel driven), as server is CLI it should be immune from them?
<skaet> phillw,  yes,  so I assume, and why its likely ok to ship.
<infinity> phillw: Your X issues are video card specific too, are they not?  It's not "all PPC hardware".
<phillw> infinity: provided you do not have radeon or nvidea cards, you are okay... Which I thinks covers all the apple PPC's ;(
<infinity> phillw: Oh, I thought it was only one or the other that was broken.
<phillw> the nvidea issue is now fix commited (it also affects other distros and archs).
<infinity> phillw: Also, radeon on my PPC machine is fine in quantal (assuming I don't use radeonfb, but what was a known bug)
<phillw> infinity: no such look for us!
<infinity> s/what/that/
<phillw> as the dust settles I'll ask some one who knows about kernels to take a look at the proposed kernel fix before I go and ask the kernel team. It would be useful if I actually understood what I was asking for :D
<rtg> skaet, should the netboot images have been rebuilt since Sept 22 ? http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/current/images/netboot/
<skaet> rtg,  no api change was the word when it was asked earlier this week.
 * ogra_ doesnt think there was a d-i upload since the 22nd
<cjwatson> Indeed.  We'll do one after beta
<rtg> ok, but the kernel in d-i still has the linker problem that we sorted out with doko
<ScottK> phillw: Understanding leads to questions.  Often it's better just not to know.
<cjwatson> rtg: Hm, I didn't see any visible effects from it ... wasn't that a total boot failure?
<rtg> cjwatson, not always, often it was just an annoyance about graphics mode selction
<phillw> ScottK: he he, then someone who understands what is a written proposed solution would need to look at it to see the feasability of it (I think that there are two ways forward that have been suggested).
<rtg> cjwatson, ogasawara: I'm bumping the kernel ABI so that we're sure to rebuild d-i after the beta release.
<ScottK> phillw: Yes, but "I don't really understand enough about this to have an informed opinion, would you please look at it and tell me what you think?" can be a nice work shifting device.
<ScottK> Let's not get into how I know that.
<phillw> thanks for the tip :)
<cjwatson> rtg: I thought we got that fix.  It stopped bugging me on boot.
<infinity> rtg: I rebuilt for that fix.
<infinity> rtg: Anyhow, no need for artificial ABI bumps, there will be d-i uploads right after beta.
<rtg> infinity, I'm checking for when that fix went in. I just updated my cobbler installation and experienced the grpahics selection bug, which is why I checked the last date on the ISO
<ScottK> I approved the privacy change FFe.
<infinity> rtg: Well, the fix was fixed a few different ways/times.  Maybe I didn't rebuild for the last one where you fixed the struct.
<infinity> rtg: Let me see.
<rtg> Ubuntu-3.5.0-14.18
<rtg> so, the netboot ISO should have that fix.
<infinity> rtg: Indeed it should.
<rtg> hmm, wtf
<infinity> rtg: Maybe you have an outdated ISO?
<infinity> rtg: Or maybe the bug just hates you. :/
<rtg> infinity, its possible both reasons are afflicting me. gimme a bit to figure it out
<infinity> rtg: Alternately, no one accidentally reverted 14.18 in a later release, did they?
<infinity> rtg: (We've long since rebuilt to pick up -15.*-)
<rtg> infinity, nope, I just checked. The 'used' attribute is still present in the source code.
<infinity> Hrm.
<infinity> Kay, well the kernel used for d-i right now would be 15.22, so all it's missing is the i915 backlight reverts.
<infinity> Which is likely irksome to some, but shouldn't be cause your bug to come back. :/
<rtg> infinity, I'll know as soon as the machine I'm installing is done. then I can check what kernel its using.
<infinity> rtg: Checking after installation might be less helpful than hitting a terminal right now and looking. :P
<infinity> rtg: Since it's the kernel baked into the installer that you're curious about, not what it plans to install, no?
<rtg> infinity, the colors are so messed up that I can't read it on another console.
<infinity> Oh.  Lolz.
<infinity> I'd suggest serial, but x86 kit with serial is the computing unicorn these days.
<rtg> just so happens this machine is old enough that it still has serial, but thats kind of a last resort
<skaet> infinity,  all the test results are in now,  and they look basically ready to start the pre-publishing off.
<infinity> Basically ready is such a comforting noun phrase.
<cjwatson> Whoa, we forgot to do early pre-publishing again
<cjwatson> Damnit
<cjwatson> I meant to check on that
<skaet> cjwatson,  ack.
<plars> Daviey: I can't seem to get the iscsi tests to work, but it's highly likely it's something in my setup as I don't have a known-working environment for this, is there someone from your team that could take a look?
<balloons> plars, I don't know if there's anything different in this one: http://packages.qa.dev.stgraber.org/qatracker/milestones/225/builds/16299/testcases/1337/results
<balloons> it's been verified to work however
<ogra_> 1337 ?
<ogra_> heh
<jibel> plars, jamespage can help you with iscsi
<plars> hmm, I may have just found the problem... I have something on my network that is causing a problem I think
<plars> let me start this over and try again
<infinity> Pre-publishing is syncing to mirrors.
<jamespage> jibel, I'm trying but my laptop keeps overheating
<Daviey> plars: jamespage is doing the iscsi stuff right now
<plars> Daviey: ok, I may keep going with it at least on the unauthenticated mode to see if I can get it working - thanks!
<skaet> infinity,  ack. thanks.
<Daviey> plars: cool!
<jamespage> Daviey, jibel, plars: seeing an issue with iscsi root
<jamespage> grub appears, but initramfs fails to find the iscsi device so no /dev/by-uuid
<jamespage> that was for authenticated
<jamespage> I'll try unauthed as well now
<plars> ogra_: have you tried netboot install since the flash-kernel update?
<ogra_> plars, i commented on the bug (and closed it too)
<plars> ogra_: oh, I didn't see the message I guess... I'll go look, but I just finished an attempt, and confirmed I have the new f-k and I'm getting "/dev/mmcblk0p1 is not a block device" still
<ogra_> hmm
<ogra_> on real iron ?
<ogra_> i tested in a vm
<plars> ogra_: yes, on my iron-panda
<plars> :)
<plars> ogra_: I don't need a newer netboot image or anything right? it's pulling it from the archive not from the image
<cjwatson> plars: that's right
<ogra_> yep
<cjwatson> it's possible there's a similar symptom a little further down
 * cjwatson will let ogra_ analyse it though :)
<ogra_> yeah, i'll try an omap4 install now
<plars> and if I go to a shell, I still see only /dev/mmcblk0 (no p1)
<ogra_> might be that there is a difference vs omap3
<ogra_> plars, erm, which image did you use ?
<ogra_> smells like you just used the fat partition
<plars> boot.img-fat-serial
<plars> I did
<ogra_> heh
<plars> because I needed serial
<plars> yeah, I was just thinking... I'm not sure that one includes partitioning
<ogra_> right, you want the .gz image still
<plars> meh
<ogra_> -fat is actually only the content of the first partition
<plars> ogra_: so this image won't work then, need to just modify the other one instead?
<ogra_> now dont ask me why we publish that
<ogra_> NCommander created that
<plars> but that was my next question!
<plars> poo
<plars> ok
<ogra_> i'll happily remove it
<plars> well, that's a relief actually
<infinity> We should probably stop publishing the partition images.  Or include a nice README.
<ogra_> (i ran into the same issue before btw)
<cjwatson> http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/MANIFEST has a one-line description of each image, but fails to mention the -fat ones ...
<cjwatson> ev: You can't use the same version in both quantal and precise-proposed.
<cjwatson> ev: Perhaps you want -0ubuntu3.1 in precise-proposed (in which case remember to tweak the Breaks/Replaces).
<ev> argh, okay
<ev> yeah, I had that before but it seemed messy
<ev> will do
 * cjwatson rejects
<plars> ogra_: what might be even nicer is to just have a preEnv.txt for both normal, and serial install boot on the boot partition
<plars> ogra_: perhaps with a README saying to just swap it out for the serial one if you need/want to do serial installs
<ogra_> plars, we do ...
<plars> ogra_: oh?
<ogra_> oh, perhaps not in the netinst image
<skaet> infinity,  which of the pre-publishing steps in Release minus a couple of hours in https://wiki.ubuntu.com/BetaProcess are done now?
<plars> ogra_: ah, right, I think I saw that on server, but it's not on netinst
<infinity> The netboot images are actually different (different modules, etc)
<ogra_> all others have preEnv.txt and preEnv.txt-serial
<infinity> It's not just a config thing.
<ogra_> plars, though generally i was thinking about dropping -serial ... it is so easy to edit the file now
<infinity> skaet: None, since "minus a couple of hours" refers to publishing, not pre-publishing.
<ogra_> so people wanting serial can easily add console=ttyF00
<plars> ogra_: but it's also easy to leave it, and probably saves you from the occasional "what do I add to make it work with serial installs" question
<plars> :)
<ogra_> true
<infinity> Yeah, I see no reason to drop the serial netboot image.
<ogra_> infinity, not the serial image
<skaet> infinity minus a couple of hours of publishing,  is pre-publishing to me.  :P
<ogra_> i was talking about preEnv.txt-serial
<infinity> ogra_: Oh, yeah.  Well, that's a nice hint.
<plars> +1 for dropping the serial image, +1 for adding preEnv.txt-serial
<skaet> infinity,  please let me know which of the steps are done,  or which are still needed.
<ogra_> plars, ok: i'll do tht over the next days
<infinity> skaet: I only just pre-published, I'll jump on the "minus a couple of hours" stuff now.
 * ogra_ puts on hos TODO
<ogra_> *his
<skaet> infinity,  ack.   please post as they get done, so we can stay in sync.
<infinity> ogra_: -1 to dropping the serial image and consolodating with fb.  It makes my life harder. :P
<ogra_> infinity, in what way ?
<infinity> ogra_: Because I'd now need to edit an image to boot serial?
<ogra_> hmm, k
<infinity> Seems like a step backward when it's no maintenance headache to provide both for netboot.
<plars> infinity: just like you do for -server? :)
<ogra_> so we'll keep serial and fb images but drop fat
<skaet> infinity,  #7 is done.
<infinity> plars: For server, it makes sense, cause shipping two enormous images is silly.
<plars> right, it should be the full image if you're really serious about keeping it
<Daviey> skaet: There is an iscsi issue, where booting isn't working as expected.  jamespage has confidently seen it, and seems plars is also experiencing woe.
<Daviey> release notes will be updated
<Daviey> it is not a beta release blocker
<skaet> Daviey,  understood.
<Daviey> I need to go afk.. We should be good to go. :)
 * ogra_ never got that iscsi hype ... nbd is so much easier :P
<plars> jamespage: doesn't seem to be working for me under unauthenticated either
<plars> error: no such device: (uuid)
<jamespage> plars, yeah - same problem then
<jamespage> plars, iscsistart: No target ... as well?
<jamespage> plars, bug 1057635
<ubot2> Launchpad bug 1057635 in ubuntu "initramfs does not use iscsiroot device presented by ipxe" [Undecided,New] https://launchpad.net/bugs/1057635
<plars> jamespage: no, I don't see that, but I did see something odd after making a stupid mistake
<plars> jamespage: I assumed I would need to install grub to a local drive
<plars> jamespage: so I erased my local drive and created a single empty partition on it at install time just to make sure it was initialized (but I didn't use the partition for anything)
<plars> jamespage: when it got to the stage of asking where to stick the bootloader, the default was sdb (my iscsi target), and I pressed enter instead of changing it
<plars> so... it didn't boot
<plars> but I went into rescue, and tried to rewrite grub but it seemed sda was still empty, uninitialized, no partition...
 * Daviey goes afk
<plars> I init'd it manually, and wrote grub to it after mounting root on /dev/sdb1
<plars> and it didn't complain, but it didn't boot
<plars> only error was the "error: no such device" one
<plars> jamespage: ^
<jamespage> plars, I use this branch for scirpted testing using ipxe
<jamespage> https://code.launchpad.net/~james-page/+junk/iscsi-testing
<jamespage> have to go afk now
<plars> thanks, I'll take a look
<infinity> Oh lovely, we haven't spit out a source CD since the 6th.  Why isn't that cronned? :/
<skaet> infinity,  feel free to add it so we don't see the issue next time.
<infinity> Sure, once I sort out how to coax cdimage into producing a source CD set.
<infinity> La la la, making source CDs.  Do dee dooo...
<knome> will http://cdimage.ubuntu.com/xubuntu/daily-live/current/ have the beta images too?
<infinity> knome: They'll show up in http://cdimage.ubuntu.com/xubuntu/releases/quantal/ when I'm done.
<knome> infinity, ok, so there's no single url where you can *always* get the latest iso?
<infinity> knome: Well, for what definition of "latest"?
<infinity> knome: The URL you gave is always the latest built.
<knome> so, the beta images will show up in that url too?
<infinity> knome: The URL I gave points to milestones.
<knome> but not the one i posted?
<infinity> knome: daily = daily, releases = releases.  Seems fairly straightforward. ;)
<knome> yeah, just checking.
<skaet> knome,   http://cdimage.ubuntu.com/xubuntu/releases/12.10/beta-2/  will have the Xubuntu beta 2 images
<knome> skaet, yeah, i was just wondering if the beta images show up in the daily directory.
<skaet> the current images in daily right now,  will become the beta-2 images and persist,  while we go back to adding fresh updates to dailies from now until final freeze.
<cjwatson> I've never cronned it because it seems like a lot to spit out all the time, and we want it to be done basically after we've finished with all the respins we're going to do
<cjwatson> Which is either difficult to automate or very expensive, depending on which approach you take :-)
<infinity> cjwatson: Yeah, I think commented out in cron as a gentle reminder would be enough. :P
<infinity> cjwatson: Especially if/when I move to automating a buch of that, and I need to remember WTF we're building. ;)
<cjwatson> Yeah, might not be a bad plan, as long as it's marked so people don't uncomment it in bulk
<skaet> +1
<slangasek> infinity: hey, so in the end I've side-stepped systemd-logind; so I no longer have an FFe justification for kmod, should I reject it?
<slangasek> (so it doesn't appear in the auto-flush)
<infinity> slangasek: It wouldn't ayway, since it's in NEW.
<slangasek> ah right
<slangasek> well should I reject it anyway? :)
<infinity> slangasek: But if you want to hold off until R, reject away.  I can fish it out of the queue and re-upload it in a few weeks. :P
<slangasek> infinity: also, pam-xdg-support has a pending FFe request for bug #894391 and is in NEW
<ubot2> Launchpad bug 894391 in ubuntu "[FFe] support $XDG_RUNTIME_DIR" [Medium,In progress] https://launchpad.net/bugs/894391
<skaet> infinity,  where are we with publishing right now?
<infinity> slangasek: DEAR GOD MAN, CAN'T YOU SEE I'M TRYING TO DO A BETA RELEASE.
<infinity> slangasek: I mean "cool, I'll check it in a little bit".
 * infinity coughs.
<slangasek> infinity: yes, I figure that's the best time to ask you whether my FFe is ok
<slangasek> QUICK, ANSWER NOW
<infinity> There needs to be a unicode glyph for flipping the bird.
<skaet> slangasek,  you taking lessons from PS?
<slangasek> heh
<infinity> skaet: Just produced and published some source ISOs, going through the manual verification bits.  Hold please.
<skaet> k
 * infinity sheds a tear for the kmod reject.
<skaet> ahh.... there's gilir
<skaet> gilir,  do you have any updates for:   https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Beta2,   if not, could you remove the "TODO" with your name on it.
<gilir> skaet, done, sorry for the delay
<skaet> thanks gilir
<infinity> skaet: Alright, cdimage mangling is all done, we should be ready to sync.
<infinity> skaet: (So, 2 and 3 are done and verified)
<skaet> infinity,  ok,  I'm working on 4 then now.
<infinity> skaet: Alright, I'll push to the mirrors nowish, then.
<skaet> yeah,  I'll start checking the links as soon as you tell me should be good.
<infinity> Hrm, wait.
<infinity> -./quantal/MD5SUMS-metalink
<infinity> -./quantal/MD5SUMS-metalink.gpg
<infinity> cjwatson: ^-- Did your rewriting make metalinks asplode?
<infinity> cjwatson: I has no quantal metalinks at all (either individual ones, or the md5sums)
<infinity> Hrm, looks like someone other than me already ran sync-mirrors anyway. :P
<skaet> ??
<infinity> Either that, or one took so long to get around to responding to the pre-publish push that it picked up beta-2 along the way.  Seems less likely.
<infinity> But releases.u.c has beta-2.
 * skaet goes to start checking the links
<infinity> Should probably wait on checking until all the mirrors have stopped suckling on nusakan's port 873.
<TheDrums> Why is it that lubuntu-12.10-beta2-preinstalled-desktop-armhf+ac100.tar.gz.zsync downloads lubuntu-12.10-beta2-preinstalled-desktop-armhf+ac100.tar (not gz, and is MUCH larger) ?
<infinity> TheDrums: Bug, someone noted it yesterday, I think.
<infinity> ogra_: Didn't you have a fix for that? ---^
<TheDrums> Happened for beta1 as well, figured I should ask this round.
<ogra_> infinity, no, cjwatson wanted to look at it
<infinity> ogra_: Ahh, I only caught half the conversation.
<ogra_> infinity, i only had the same prob but wanted to finish beta testing so didnt care any further and used wget
<skaet> infinity,   64-bit Mac (AMD64) server install CD should be on cdimages,   not supported image per Daviey.
<infinity> skaet: Oh.  That's irksome.  It's only supported for desktop?
<ogra_> TheDrums, use wget for now (dunno, probably rsync would work too)
<skaet> only for server
<skaet> desktop is supported
<infinity> skaet: Yes, that's what I just said. :P
<ogra_> TheDrums, thanks a lot for reporting (and reminding me)
<skaet> rather server not supported,   desktop supported.
<skaet> yeah
<skaet> read it wrong.
<infinity> skaet: I'm all for ignoring that for beta-2, and publishing differently for release.  Manuall mangling it is annoying.
<infinity> Manually, too.
<skaet> ok.  Can we clean up the Desktop CD reference on the page to say Desktop Images?
<infinity> Well, it's still an ISO, which is what we call a "CD" in the publishing scripts.
<skaet> yeah but its misleading to refer to it as an ISO.
<skaet> sorry
<skaet> rather a CD
<infinity> And is still more non-tech friendly, I suspect, for people burning to optical media (despite it not fitting on a CD).
<infinity> Cause no one knows what an "ISO" is.
<infinity> But maybe it's time to just drop the "CD" thing entirely, even for the images that do fit.
 * skaet nods
<TheDrums> ogra_: Sure thing.
<skaet> Riddell,  ScottK - we'll need to do the same thing for Kubuntu as well I think,  still referencing CD there too.
<skaet> infinity,  links work.   Can you confirm the torrents are operational?
<skaet> (and if not,  go prod #is...)
<infinity> Well, some of the torrents work...
<skaet> and OMGUbuntu's pulled the usual pre-announce the release stunt.... :P
<infinity> Yeah, big shock there.
<infinity> S'ok, it means the torrents will be well-seeded by the time your announce goes out. ;)
<skaet> :)
<phillw> infinity: is torrentflux a decent system to install as a seeder server, or do you have a better suggestion?
<infinity> phillw: I'm pretty torrent ignorant, not the best person to ask.
<phillw> any hints?
 * infinity taps his foot while magellanic finishes syncing.
<infinity> phillw: Not so much, no.
<phillw> skaet: do you know who looks after the torrent server for ubuntu?
<infinity> phillw: #canonical-sysadmin, but you may find they're a bit busy to answer any questions right now.
<phillw> infinity: fine, I'll catch up with them tomorrow, I know just after a milestone release is a busy time!
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Beta 2 released! | Archive: Frozen for pre-release | http://pad.ubuntu.com/ubuntu-release | Quantal Quetzal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis
<skaet> infinity,  release steps 1,2,3 done.  moving on to the rest.    Plan is to leave the archive frozen.    Don't flush the unapproved queue though until cjwatson is back online.   He wants to keep an eye on things.
<infinity> skaet: Yeah, I've talked to him about it.
<infinity> skaet: I'm still wrangling torrent messes.
<skaet> infinity,  oh,  thought it was good from your message earlier, or would have held off on announce.  :(
<infinity> skaet: Probably not world-ending to push the announce while we sort this.
<skaet> infinity,  it was mailed already, since you said some of the torrents work.   raise a flag if theres a snag please.
<infinity> skaet: I figured "some" implied "not all". ;)
<infinity> skaet: Anyhow, there are only a few that are sad, and we're working through it. It's not like the torrents "work" very well right when we say they do anyway, since they have no peers. :P
<skaet> k
<highvoltage> " * Changes from the Ubuntu defaults for certain packages."
<highvoltage> who butchered the edubuntu release notes :-/
<highvoltage> (ah perhaps they didn't)
<stgraber> highvoltage: yeah, the release announcement doesn't contain eveything from the tech overview
<highvoltage> stgraber: indeed, I just realised that.
<infinity> cjwatson: Is publish-release on your rewrite hitlist?
<infinity> cjwatson: If so, it has a bug you won't want to replicate (multi-pass publishing cleans the torrent directory of the previous pass)
<infinity> cjwatson: If not, we should fix that bug in the shell version. :P
<infinity> skaet: Torrents should all be happy now.
<skaet> Thanks infinity.  :0
<skaet> :)
 * infinity decides it's time for a proper lunch before undoing all the beta bits on cdimage and turning dailies back on, etc.
 * skaet thinks its time for her lunch too....
<slangasek> infinity, skaet: congrats on the beta :)
<cjwatson> infinity: that torrent business has annoyed me for ages, yes.  I noticed it for 12.04 I think but it was really painful to fix in shell
<cjwatson> infinity: everything is on my hitlist, but particularly publish-release
<cjwatson> infinity: did you figure out the metalink business?  I certainly hadn't intended to break that
<cjwatson> skaet: am I good to flush the queue at leisure?
<phillw> cjwatson: whilst infinity and skaet return from lunch, could you answer me a question about including  * b43-fwcutter on an ISO? Lubuntu seem to have it on LiveCD, but not installation iso's....
<cjwatson> That's controlled by your seeds
<phillw> cjwatson: the question, I think, is are we 'allowed' to include it?
<cjwatson> Up to you
<phillw> no copyright issues?
<cjwatson> Not AFAIK
<skaet> cjwatson,  you're good to process them through now.    Keeping the archive frozen though.
<cjwatson> Why?
<cjwatson> We normally flush and unfreeze at about the same time.
<cjwatson> Or do you mean permanently until release?
<skaet> Until release
<phillw> thanks, it really threw a guy out as his WiFi was working perfectly on LiveCD and he did an install and it went POOOF!!!
<skaet> There's a bit too much churn going on, and don't want to break the dailies between here and final freeze.
<cjwatson> skaet: Damn, that means I actually have to review everything then.
<cjwatson> Can you announce that, if you haven't already?
<skaet> cjwatson.  Will do.   In ubuntu-release email ok?   or ubuntu-devel better?
<cjwatson> -devel-announce, I think.  It's a pretty major change!
<iulian> Are we keeping the archive frozen until release, i.e. final release?
<skaet> cjwatson,  is it?   we kept it frozen after beta 2 in oneiric,  and it was frozen from 3 weeks out in precise as well.
<cjwatson> ev: I'm afraid your activity-log-manager upload to quantal clashed with a different one already in the queue.  I accepted Didier's since it was there first; please rebase your change on top
<skaet> iulian,   yes,  we're keeping it frozen until release.
 * skaet will go compose the email for devel-announce
<cjwatson> skaet: 3 weeks out in precise wasn't beta 2, though ...
<cjwatson> At any rate it seems worth telling people.
 * iulian nods.
<iulian> I thought we're going to unfreeze now.
<skaet> agreed.   I put it in the channel headers when I announced beta 2 was out for #ubuntu-release and #ubuntu-devel,  but better to overcommunicate than under.
<skaet> iulian,  fixes can be let in now,  but not without some review.
<cjwatson> I'll review the queue then.  Will take some time.
<skaet> see comment above from cjwatson on clashing. :/
<cjwatson> Can I accept my own if I know they're bug-fix-only?
<skaet> yes
<slangasek> Do the gnome 3.6 ones need anything beyond a pro-forma review?  I could help with some of those
<stgraber> I'm also around for reviews if you want to split
<skaet> slangasek,  not unless Laney has something he's worried about.
<skaet> thanks stgraber.
 * slangasek starts at 'gedit' for the moment
<cjwatson> I guess I probably ought not to review my own for the sake of form.
<cjwatson> Resolving duplicates first.
<infinity> All of the stuff with version numbers that look suspiciously like 3.6.0* probably only need lightweight review, at best.
<infinity> And that's where I had planned to start.
<slangasek> there look to be enough of them to go around
<infinity> Oh, and I can unreject gtkhtml4.0 now, and get its rdeps rebuilt.
<infinity> Oh, sweet mother of... I left all the torrents downloading while I was at lunch, cause I forgot to delete them all after testing.
<infinity> I now have, uhm, a lot of beta2.
<cjwatson> (Oh, and please particularly today tell me about any queue timeouts rather than just trying again.)
<infinity> cjwatson: Oh, wait, are we reviewing but not accepting, so you can do a mass accept run?
<cjwatson> Doesn't matter.
<infinity> (ignore the dpkg and gtkhtml I just accepted, if so)
<cjwatson> queue does one request per accept anyway.
<infinity> cjwatson: Kay, I just know you wanted to clear the queue.
<infinity> And somehow lost focus on that with the talk of reviewing. :P
<cjwatson> I just wanted to be around.
 * iulian is going to do a few reviews and then bed.
<iulian> cjwatson: Shall I start from the bottom and work my way up?
<cjwatson> As you wish
 * infinity is really tempted to just batch accept 3.6.0*...
<cjwatson> The odd collision won't kill us
<stgraber> ouch, why did I open the grub2 diff again? :)
<infinity> Which is what I would have done if the uploads had been a day earlier.
<iulian> cjwatson: OK, great.
<doko> do I need somebody to formally review binutils and gcc-4.7 updates, or can I copy these with the pre-built binaries from the ubuntu-toolchain-r PPA?
<cjwatson> You can copy them and they'll land in the queue, since we're still frozen
<doko> ok
<cjwatson> Whoever accepted language-selector might want to accept the other one so that its bugs get closed.
<cjwatson> (0.88)
<infinity> Not that copies with binaries are remotely reviewable.
<infinity> Without tracing back through history.
<cjwatson> I'm reviewing nova and quantum, but need to go rescue a crying baby.
<infinity> I'm just working bottom-up on gnome 3.6
<infinity> cjwatson: As for the publish-release torrent bug, isn't it already a solved problem with publish-release's publishing of images to simple/ and full/?  Surely, the same logic could apply, instead of just wiping the directory clean.
<infinity> cjwatson: (But if it's being rewritten soon, I'd rather just make a mental note of the bug for release day and otherwise not waste time on it)
<cjwatson> infinity: I think it was a bit more complicated than that, but I forget the detais
<cjwatson> *details
<infinity> cjwatson: Fair enough.  And now that I'm aware of it, I don't much care either.
<cjwatson> wrap-and-sort: for when you want to annoy reviewers
<infinity> cjwatson: Hunting it down was a bit surprising, s'all. :)
<infinity> cjwatson: wrap-and-sort is great after the first application, mind you. :/
<infinity> cjwatson: The diffs sure get more readable in subsequent uploads.
<cjwatson> No doubt.  Just do it when I don't have to read the result. :-P
<infinity> *grin*
<iulian> :)
 * infinity goes to clean out -proposed, since he already reviewed most of those once.
<cjwatson> zul: Not grounds for rejection or anything, but this change in nova 2012.2-0ubuntu1:
<cjwatson> +  * debian/control: Dont conflict with novnc. (LP: #1055505)
<cjwatson> zul: ... doesn't actually appear to be present in the diff.
<slangasek> what, no scathing feedback on the mountall upload?  I'm disappointed
<xnox> slangasek: the tim of the upload in debian and sync was peculiar.
<infinity> Can we give TheMuso a gold star for actually documenting changes in his uploads instead of the usual "New upstream release" that every other desktop uploader uses?
<xnox> s/tim/time/
<slangasek> xnox: was it?
<xnox> doko: git ^^^^^ accepted above =/
<ScottK> Note for the post-release release team feedback session at UDS: Finding out that the design for a new feature that's been requested to land post beta 2 has significantly changed via jono's blog post isn't really the best communication flow.
<stgraber> bdmurray: ping
<xnox> slangasek: well it was morning here. So it must have not been a reasonable hour to fiddle with mountall.
<slangasek> xnox: dude, those are the ONLY hours I fiddle with mountall
<slangasek> ;)
<infinity> Why is this starting to sound dirty?
<stgraber> bdmurray: looks like your ubuntu-release-upgrader wasn't generated properly, it contains a lot of file removal: http://launchpadlibrarian.net/117539252/ubuntu-release-upgrader_1%3A0.180_1%3A0.181.diff.gz
<stgraber> bdmurray: I'll reject it to avoid getting another broken upgrader in the archive. If the diff is actually correct, let me know and I'll get it out of rejected.
<cjwatson> bdmurray,stgraber: use bzr bd -S not debuild -S
<stgraber> right, otherwise the pre-build script doesn't run
<cjwatson> stgraber: in fact how about I reupload on his behalf that way :)
<stgraber> cjwatson: feel free :)
 * infinity goes crosseyed at empathy's 2.6MB diff and goes to find a coffee.
 * xnox ponders if I should drink coffee at 11 pm..... I like coffee but also like sleep.
<iulian> Ah, had ceph in front of my eyes.
<stgraber> me too :)
 * xnox was just suggested to add an empty file in the initramfs to satisfy mdadm check for running inside initramfs..... because of systemd *sigh*
<cjwatson> tjaalton: what happened to debian/patches/nouveau-nva3-noaccel-info.patch in xserver-xorg-video-nouveau 1:1.0.2-0ubuntu2?
<slangasek> xnox: ... for Ubuntu?
<xnox> slangasek: linux-raid mailing list.... that patch is not in mdadm yet, but just got proposed. http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface   /etc/initrd-release is the equivalent of /etc/os-release
 * slangasek snorts
<xnox> slangasek: to detect if systemd is running in the initrd or real machine, which also allows othere processes to check for that file and do special stuff..... or something.....
<slangasek> I propose that we make /etc/initrd-release a symlink to /dev/zero
<slangasek> in our initramfs
<slangasek> in order to detect software which is misbehaving by using this file in Ubuntu
<cjwatson> stgraber: ^- that should be a tidied-up version of bdmurray's ubuntu-release-upgrader upload
<stgraber> cjwatson: looking
<cjwatson> Rejecting duplicate gnome-desktop3
<cjwatson> stgraber: also: come on, grub2 isn't that hard ;-)
<iulian> zul: Do you have an FFe for python-novaclient? It seems that not everything is a bug fix. commit 3dd0393fbb looks like a new feature.
<doko> klibc and libffado are ftbfs fixes
<cjwatson> accepted libffado
<cjwatson> klibc is my own so somebody else should do it
 * iulian looks.
<stgraber> accepted grub2, bug 901600 could have been considered a feature but it's a really nice improvement that'll save us from a lot of other problems we had in the past, so if someone asks, I granted a FFe to that bit.
<ubot2> Launchpad bug 901600 in grub2 "Allow /etc/default/grub overriding via /etc/default/grub.d/" [High,Fix released] https://launchpad.net/bugs/901600
<cjwatson> You could look at it either way; I considered it a bug :-)
<iulian> klibc accepted.
<doko> Laney, there is a qt4-x11 upload in unapproved without the -g/-gstabs change. maybe reject this one, and add one with it?
<cjwatson> I think I already accepted that qt4-x11.
<iulian> Yup - Unapproved: accepted qt4-x11 [source] (quantal-proposed) [4:4.8.3+dfsg-0ubuntu2]
 * cjwatson lands the final branch for bug 745799, since there seem to be no timeouts
<ubot2> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,In progress] https://launchpad.net/bugs/745799
 * iulian is off to bed.
<iulian> Nighty night.
<cjwatson> And plenty of successful async bug closures
 * skaet sent email out
<skaet> infinity,  I' ve re-enabled the daily crontab, and updated the iso tracker for Daily images.
<skaet> when you get a chance,  can you or cjwatson, please turn on the auto discard again?
 * skaet notes that kubuntu alternates need to be removed from the crontab source for 12.10.
<infinity> skaet: I'll do that, and unset OFFICIAL.
<skaet> Thanks.
<stgraber> infinity: FYI I reverted etc/default-arches to get Edubuntu building on armhf again
<infinity> stgraber: Just now?  Kay.
<cjwatson> I accidentally released unity-2d/oneiric a few days early (I didn't notice that it was less aged than unity-2d/precise).  Hopefully that won't cause any problems ...
<infinity> cjwatson: unity needs to go with it, hard library dependency.
<infinity> cjwatson: Quick, before the publisher runs. :P
<cjwatson> Seriously?  FFS.
<infinity> SRSLY.
<highvoltage> heh, foundations people are funny.
<cjwatson> Thanks for the heads-up
<cjwatson> It's just a library rename so going early probably isn't a huge deal anyway.
<infinity> cjwatson: Yeah, both were ready and verified, I was going to let them fester until Mondy on the off chance someone found a regression, but it seems unlikely.
<cjwatson> (Well, unity is a bit more I think)
<cjwatson> unity/oneiric released now too.
<infinity> unity was basically just the rename too.
<infinity> It just looks bigger because a patch moved from debian/ to upstream.
<xnox> It's like me and slangasek. xnox: "I merged mumble, I hope it will not sabotage the team call." slangasek: "Dude, have you seen the pending debian tech committee dispute on mumble?! It's brakes the world."
<cjwatson> BTW I think I've reviewed everything in the queue I have the stomach for at the moment.
<infinity> cjwatson: All good.  I'm going to do a few/bunch more before I have to shower and head out of the night.
<infinity> s/of/for/
<infinity> Also, I think I'm going to just leave OFFICIAL set to Beta until we move on to Release in a couple weeks.
<cjwatson> Above grub2 is the amd64 binary requiring UEFI approval, in case anyone's confused by queuebot.
<infinity> apw: Oh look, need a new lowlatency --^
<infinity> apw: (You should sort out how to give me commit to that branch, and I'll do some of the bumps)
<skaet> infinity,  I was wondering about OFFICIAL a bit earlier,  and yeah,  not fussed at leaving it at Beta until we move to release, unless someone has a good reason why it shouldn't.
<cjwatson> Right.  ubiquity upload, then bed.
<ogasawara> when someone has a moment, could I get that new kernel (and meta package) approved in the queue?
<slangasek> fwiw I've looked at the glibmm2.4 in the queue and think I see a problem with it
<slangasek> leaving it in the queue for now, taking to #ubuntu-devel for discussion with robert_ancell
<stgraber> I'll take ubiquity
<cjwatson> Lots of uninstallability right now due to atk1.0 arch skew
<cjwatson> I'll do a bit of rescoring for that
<infinity> ogasawara: I'm on the kernel.
<cjwatson> amd64 and armhf should clear themselves up shortly now that i386 has built
<infinity> slangasek: Want to poke jdstrand for a security audit of your pam module in NEW?
<infinity> Or, I suppose I can.
<infinity> jdstrand: Care to audit slangasek's pam module in quantal/new?
<infinity> jdstrand: I've given it an FFe exception pending review.
<infinity> cjwatson: Hrm, the UEFI blob doesn't actually show in the queue, that's annoying.
<cjwatson>          | * grub2_2.00-7ubuntu1_amd64.tar.gz Format: uefi
<infinity> cjwatson: (Sorry, in the web UI)
<cjwatson> Ah, that broken POS
<infinity> Heh.
<cjwatson> You can't really review the blob anyway - the assurance is that the source diff isn't evil
<cjwatson> Anyway, it is in the web UI, just not labelled as uefi
<infinity> Also, were we going to land an i386 solution too, or are we assuming that all UEFI systems we care about will be amd64?
<cjwatson> grub2_2.00-7ubuntu1_amd64.tar.gz (250.1 KiB)
<cjwatson> My levels of caring about i386 UEFI are very low
<cjwatson> At some point somebody will probably make me care for Atom or something
<cjwatson> But at the moment ... meh
<infinity> cjwatson: oh, indeed, I misread that as the orig.  I think it's been one of those days.
<cjwatson> I won't claim the naming is intuitive.
<infinity> cjwatson: Well, having uefi in the name, like translations.tar.gz, might be helpful.
<cjwatson> Yeah.  I think that would need LP code changes.
<cjwatson> Maybe.
#ubuntu-release 2012-09-28
<infinity> Pretty sure it would, yeah.
<cjwatson>     The filename must be of the form:
<cjwatson>         <TYPE>_<VERSION>_<ARCH>.tar.gz
<infinity> LP already special-cases translations.tar.gz, IIRC.
<cjwatson> And changing <TYPE> would land in the published directory name
<cjwatson> So not sure it's worth the effort at the moment TBH :)
<infinity> Nope.
<cjwatson> I don't think it special-cases _translations.tar.gz so much as cares much less about its name.
<infinity> Or that. :P
<infinity> Well, _translations also doesn't get caught in NEW.
<cjwatson> The raw-translations section is the bit that matters.
<infinity> But yeah, probably because of the upload type.
<cjwatson> UNAPPROVED in this case.  That's a special case for UEFI.
<cjwatson> By request of the security team.
<infinity> Oh, derp.  Right, to avoid random people jamming them in.
<infinity> We've HAD THIS CONVERSATION.
<infinity> I'm getting old.
<cjwatson> 'zackly.  Compromise between locking down the set of UEFIable source packages and letting any single-PPU developer get stuff signed with our key.
<infinity> I think I'll review GTK and then go get ready for a night of drunken debauchery.
 * skaet thinks a glass of wine sounds about right,  at any rate   --> EOD
<stgraber> cjwatson: accepting nouveau. The patch that's dropped in the diff wasn't applied in the previous uploads so it looks indeed safe to remove.
<stgraber> tjaalton: ^
<zul> iulian: no my understanding openstack projects has a standing FFE which includes python-novaclient
<infinity> zul: A standing FFe *forever*, or until a certain pre-release date (and didn't this come up last release cycle too?)
<infinity> zul: There has to be a cutoff point where we can't just jam in new features and hope they work.
<zul> infinity: there hasnt been a a certain pre-relaase date, besides the new novaclient will be the last for quantal
<infinity> Oh, vomit.  Looks like a CompSci Java student attacked the code.
<infinity> -                if nic_info['net-id']:
<infinity> +                if nic_info.get('net-id'):
<infinity> Etc.
<xnox> infinity: first one can give the KeyError, while the later returns None, casted to bool => False. So actually looks like a bug fix.
<xnox> .... unless net-id is always set to something...... in that case vomit.
<infinity> xnox: Yeah, I suppose it could be unset (and I wasn't actually paying attention to the part that it was an if, just the []->.get() change)
<infinity> xnox: I retract the vomit, based on it being in a test, though that's potentially sketchy in other ways. :P
 * xnox feeds vomit back to infinity
<infinity> Ew.
<infinity> That's my cue to put on pants and leave the house.
<xnox> infinity: in a parallel universe it's actually cherries and strawberries =)
<tjaalton> stgraber, cjwatson: yeah, the patch was cruft from my local tree.. probably should use git-bp in the future ;)
<micahg> if someone with live image knowledge could please review this and make sure I got it right ^^^
<henrix> i have a few kernel packages that landed in the wrong component in the -proposed pocket. can someone take a look at that, please?
<cjwatson> stgraber: nouveau> ah, thanks
<Laney> oh, we're staying frozen?
<cjwatson> apparently so
<cjwatson> henrix: I'll fix it up in a few minutes
<cjwatson> still on child duty
<henrix> cjwatson: great, thanks
<ev> cjwatson: will do
<cjwatson> You know
<cjwatson> I think I might just bite the bullet and finish porting this old "fix up all the kernel overrides post-publication" script
<cjwatson> henrix: will take a little longer as a result
<henrix> cjwatson: ok, no worries
<micahg> cjwatson: can you review my livecd-rootfs upload in the queue for quantal, it adds some missing tasks for Ubuntu Studio (I'm 99% sure it's fine)
<apw> infinity, as requested
<apw> infinity, and yes we do
<cjwatson> micahg: yes, in my queue
<cjwatson> henrix: oh, hah, I thought you meant they'd been *published* with the wrong components
<cjwatson> but they're in NEW
<cjwatson> oh well, the effort won't ultimately go to waste
<cjwatson> we already have a tool to mangle the queue :)
<henrix> cjwatson: ups, sorry :-/
<henrix> cjwatson: i should have provided you with a bug number
<henrix> cjwatson: bug #1056036 btw
<ubot2> Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036
<cjwatson> micahg: oh, yeah, that's fine
<cjwatson> henrix: Oh.  You mean precise.
<cjwatson> Please tell me the series! :-)
<cjwatson> Otherwise I'm going to assume current development
<henrix> cjwatson: ok, noted and will do that next time.
<cjwatson> all right, I can try out this script after all
<Laney> diff from 3.5.12-0ubuntu3 to 3.5.13-0ubuntu1 (14.7 MiB)
<tumbleweed> :)
 * Laney sides with infinity about "* New upstream release" changelogs
<Laney> did someone leave gtkmm3.0 in the queue on purpose?
 * Laney abuses barry for not uploading merges with -v
<xnox> slangasek> fwiw I've looked at the glibmm2.4 in the queue and think I see a problem with it
<xnox> bah. not gtkmm
<xnox> related?
 * cjwatson sends the LP branch to remove the queue script off to EC2
<cjwatson> At last
 * Laney misparsed that at first and thought we were to become more cloudy
<cjwatson> no
<cjwatson> :)
<Daviey> bah
<ogra_> hmm, am i assuming right that we wont have a release meeting tonight (given there was a release yesterday)
<ogra_> ?
<Laney> please to score up https://launchpad.net/ubuntu/+source/libsoup2.4/2.40.0-0ubuntu1/+build/3860291
<Laney> makes webkit uninstallable, which makes things sad
<cjwatson> doing
<cjwatson> done
<Laney> ta
<cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is looking pretty good, but just needs a bit more of a push; could somebody on your team prepare MIRs as appropriate for ipmitool, javascript-common, python-babel, and wwwconfig-common?
<Daviey> cjwatson: ipmitool will be dropped on next upload, and python-babel was pulled in by accident with pydist.
<Daviey> But yes, keeping an eye on it.
<Daviey> ipmitool MIR was marked Invalid, so not showing on report.
<cjwatson> OK ...
 * cjwatson gets rid of svn2cl
<cjwatson> Not that it'd have been a big deal since it was a split-out, but
<Laney> bah, the libsoup rabbit hole gos deeper
<henrix> cjwatson: sorry to nag you again, but have you took a look at precise packages (bug
<Laney> .
<henrix> cjwatson: bug #1056036
<ubot2> Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036
<cjwatson> henrix: Just getting back to it now
<henrix> cjwatson: ah, cool.  thanks
<cjwatson> Just a bit baffled by why my script isn't doing the right thing
<cjwatson> Oh, I bet SPPH.getPublishedBinaries is annoying
<cjwatson> ... no, my own stupid fault
<cjwatson> henrix: done now (I gave up on the script for the moment)
<henrix> cjwatson: ack, thanks a lot
<doko> Laney, libsoup failed again. I assume we have to wait ...
<Laney> yes
<doko> Daviey, cjwatson: the python-babel issue will be resolved if the nova ftbfs is fixed
<Daviey> doko: right, thanks
<Laney> doko: do you know why webkit would fail on armel with the argument list too long error, but not on armhf?
<Laney> https://launchpad.net/~laney/+archive/webkit/+packages
<doko> Daviey, so what about yui3?
<doko> Laney, sorry, no
<Daviey> doko: I'll press on that today.
<Laney> ogra_: ^ you have any idea?
<doko> Daviey, we had another package with this, downgraded to suggests, but if it pops up again, maybe it's better to include these two in main
<ogra_> Laney, not really, no
<doko> Laney, ahh, this is *with* you patched make?
<Daviey> doko: Which two?
<Laney> yes
<ogra_> Laney, hmm, that seems to be a virtual PPA
<ogra_> Kernel version: 2.6.24-32-xen #1 SMP Thu Jul 12 14:30:40 UTC 2012 x86_64
<ogra_> i would incline to blame qemu
<Laney> ok, i'll try it on my panda then
<ogra_> Laney, how about you try it again in the canonical-arm-dev PPA
<ogra_> that should be a physical builder
<Laney> I'd have to copy the patched make-dfsg in there
<Laney> might not be the best idea
<ogra_> ah, yeah, no
<doko> Daviey, ahh, it was yui, but the downgrade wasn't done for the -debug package ... fixing
<Daviey> doko: ah, ok
<cjwatson> infinity: ahahahaha bonk
<cjwatson> infinity: http://paste.ubuntu.com/1247367/
<Laney> bah, too many uninstallables
<cjwatson> ogra_,infinity: so, zsync of ARM *.gz files
<cjwatson> ogra_,infinity: do you want them always to come out locally as *.gz, or is it appropriate e.g. for zsync to decompress *.img.gz on the fly?
<ogra_> cjwatson, the former, else you suddenly end up with a 4G file if you downloaded a 400M img.gz
<cjwatson> OK
<cjwatson> I'm pretty sure this was just a mistake in publish-release
<ogra_> ah, good
<cjwatson> And actually it dates back forever
<ogra_> funny, i have scripts using zsync here
<cjwatson> ./ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz.zsync:Filename: ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img
<cjwatson> But are those scripts pointed at dailies?
<ogra_> and that definitely worked before the switch to lubuntu for ac100
<ogra_> yes
<cjwatson> publish-daily doesn't have the same bug
<ogra_> ah
<cjwatson> Oh, but apparently it does now
<cjwatson> Blast
<cjwatson> OK, so we have two bugs here
<cjwatson> Oh, I se
<cjwatson> e
<cjwatson> fixed - I'll regenerate *.zsync now
<cjwatson> ogra_: Lubuntu daily should work now
<ogra_> yay, great
<ogra_> will test, one sec
<ogra_> http://paste.ubuntu.com/1247426/
<ogra_> looks good
<ogra_> (nothing to fetch indeed :) )
<cjwatson> awesome, thanks.  I'm going to go round and fix up all the old release directories
<cjwatson> ogra_: all fixed now, including a handful on old-releases
<micahg> cjwatson: thanks
 * ogra_ hugs cjwatson 
<cjwatson> Laney: yeesh, I see what you mean about the libsoup rabbit-hole
<Laney> cjwatson: I have some tabs open to keep an eye on things, but couldn't be bothered to annoy for many rescores
<Laney> gsettings-desktop-schemas armel/ppc would be a good start
<cjwatson> that's where I'd just got to
<Laney> of course it could go further than that
<cjwatson> those at least have satisfiable build-deps
<cjwatson> so rescored
<Laney> oho, a pre-release backport
<cjwatson> ^- needed (along with a debian-installer upload later) to let me check appropriate lowmem levels for bug 1050595
<ubot2> Launchpad bug 1050595 in lowmem "Ubuntu Server installation with 128M ram hangs" [High,In progress] https://launchpad.net/bugs/1050595
<cjwatson> so I'd quite like that in quickly if somebody has time to review
 * ogra_ sees popey's release team report and laughs
<ogra_> " Lots of love in lenses" ....
<popey> :)
<popey> phew!
<ogra_> so we ship a partnetr search lens ? or is it p0rn ?
<ogra_> :)
<stgraber> cjwatson: looking at lowmem
<stgraber> well, once LP is done generating the diff...
<stgraber> slangasek: we are still requiring FFe for multi-arching packages right? (was looking at libgnomecanvas in the queue)
<cjwatson> ta
<popey> could a kind release team member please cast an eye over https://bugs.launchpad.net/unity-lens-music/+bug/1054720 ?
<ubot2> Launchpad bug 1054720 in unity-lens-music "[UIFE] Previews: Unable to preview banshee songs in the dash" [Medium,Fix committed]
<stgraber> I asked Till to confirm that the brother-lpr-drivers-common upload is sane as it's not linked to a bug and it's not clear whether the change has been tested or the impact on the resulting binaries
<hallyn> hi - any objections to FFE for bug 1049908 ?  it's a pretty nice improvement in upstart control over auto-start lxc instances
<ubot2> Launchpad bug 1049908 in lxc "[FFE] Upstart control of lxc container instances" [Medium,Confirmed] https://launchpad.net/bugs/1049908
 * smartboyhw discovers there will be no release weekly update email from Studio oh no:P
<stgraber> hallyn: reviewing
<stgraber> hallyn: btw, you should subscribe ~ubuntu-release to the FFe
<hallyn> i did
<hallyn> oh.  well i did, but lp timed out.  9tab os still open)
<stgraber> hallyn: change looks reasonable. Did you try it with a lucid container to check that the two minutes timeout works properly and the container gets killed "properly"?
<stgraber> (lucid or anything that doens't have a SIGPWR handler)
<hallyn> stgraber: no, i'll set up a trst for that, thx
<hallyn> (we'll want to knwo that whether the ffe is granted or not :)
<stgraber> yeah, and I'm not going to grant the FFe if it regresses containers that aren't running >= precise :)
<stgraber> (especially as I'm running a fair number of those myself :))
<barry> Laney: gah.  i keep expecting bzr to dtrt :(
<hallyn> stgraber: lucid container stops just fine
<ogra_> skaet, meeting or not today ?
<hallyn> stgraber: and do so immediately, so i assume it's actually listening to sigpwr and shutting down
<stgraber> hallyn: hmm, it shouldn't, unless you backported the shutdown job in the lxc package?
<stgraber> hallyn: you may want to try removing the shutdown.conf job then and check what happens, without it, the container should take 2min doing nothing then be killed
<hallyn> http://paste.ubuntu.com/1247608/
<hallyn> stgraber: yeah maybe you're right.
<hallyn> re-testing
<hallyn> stgraber: after 120 second timeout the container gets killed
<hallyn> so seems to DTRT to me
<ScottK> popey: The banshee thing doesn't look particularly critical to me (adding functionality that's merely missing, not broken, with a non-default application).
<popey> thanks for the feedback ScottK
<ScottK> popey: I was about to comment in the bug that it should wait.  Do you disagree?
<popey> actually I don't. please comment away./
<stgraber> hallyn: good
<hallyn> stgraber: actually, i'm not sure lxc-instance beahves the same on reboot
<hallyn> 'stop lxc-instance NAME=l1' waits for the timeout,
<hallyn> but i have a feeling that reboot immediately kills it.
<ScottK> popey: Thanks.
<skaet> ogra_, yup meeting.
<ogra_> ok
<hallyn> feh, bad test
<smartboyhw> Yay meeting
<ogra_> skaet, thanks (i have a really sick cat around and need to schdule a vet appt. so i needed to know :) )
<smartboyhw> skaet, scott-work will be too busy to send the release emails today:(
<ogra_> smartboyhw, he could have delegated to you :)
<smartboyhw> ogra_, well he didn't:P
<skaet> ogra_,  sorry about your cat.  :(   likely short one, since not that many reports made it in,  but its important to sync up.
<ogra_> skaet, yeah, i guess he will be fine (has a red swollen nose looking like a clown atm)
<ogra_> likely some catfight leftover :) teenagers, y'know :)
<skaet> poor fellow.  sounds like an abscess, and yeah you want that looked at as soon as possible.  :/
<ogra_> yup
<hallyn> stgraber: all right, found a bug.  at this point ig uess it waits until r :)
<stgraber> hallyn: what's the bug?
<hallyn> stgraber: if instance is running and you reboot, the lxc-instance job times out but then reboot is cancelled
<hallyn> it may be easy to fix but is subtle enough not to play with this late.
 * hallyn biab
<stgraber> ok
<stgraber> ScottK: we seem to be good at coliding on FFes ;)
<ogra_> smartboyhw, you shoudl tell him your are available for the next time ;)
<smartboyhw> ogra_, I did tell him that I am available:P
<ScottK> stgraber: Did we agree?
<cjwatson> Laney: What's the libaacs sync for?  It looks fine; the changes just all appeared to be for other operating systems :-)
<stgraber> ScottK: initially, no, but after hallyn did some more tests, yes :)
<ScottK> All good then.
<Laney> cjwatson: There's a leak fix that ricotz forgot to mention in the changelog
<cjwatson> Ah, I noticed that and wondered if it was relevant.  Fine then.
<Laney> (it's a sponsored upload for him)
<cjwatson> OK
<cjwatson> Laney: I think I left gtkmm3.0 in the queue because the diff was giant and I was tired
<cjwatson> Laney: I'll have a look over it now
<Laney> I think xnox attempted to say something about it earlier but gave up before he got there ;-)
<xnox> Laney: meh... i was wrong anyway
<cjwatson> I guess the half-million line new file docs/reference/gtkmm-3.0.tag which I really don't care about helps
<cjwatson> giant docs are giant
<smartboyhw> skaet: I will change the work item link for Ubuntu Studio in https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-09-28?action=show&redirect=ReleaseTeam%2FMeeting%2FAgenda, it got an extra hyphen:P
<skaet> thanks smartboyhw :)  appreciate it.
<smartboyhw> OK link changed
<smartboyhw> Eee 38% completed...Not good:(
<cjwatson> Right.  It's gigantic, but it's basically all docs, trivial changes such as whitespace, and bits of new API exposed from GTK+ that's appropriately annotated.  Accepted.
<cjwatson> xnox: So, this partman-auto upload looks right to me; nice work.  However, doesn't automatically_partition/replace/choices need essentially the same changes?
<cjwatson> xnox: I'll accept it for now as I think this is a clear improvement
<infinity> cjwatson: Hahaha, re: metalink oops.
<xnox> cjwatson: it probably does =) but need to check if I affects desktop installer. It does offer wipe & install currently. Unless replaces is something different....
<infinity> cjwatson: Also, that d-i upload there seems a bit premature with a new linux-ti-omap4 sitting in the queue...
<ogra_> which actually fixes a d-i issue :)
<xnox> cjwatson: ok. thanks for accepting that. Also there is ubiquity commit to go with it: handling "quantal (development branch)" -> "12.10" upgrades.
<cjwatson> infinity: Which I saw after the upload :-(
<cjwatson> xnox: I forget what replace is
<cjwatson> infinity: But I'd kind of like a new d-i before my EOD so that I can do some lowmem testing
<xnox> cjwatson: also the reuse is not very multi-disk / multi-install aware.....
<cjwatson> It was really more for that than the new kernel
<infinity> cjwatson: Oh.  I'll unreject the reject I just did. :P
<cjwatson> Heh.  Thanks
<cjwatson> xnox: Yeah
<cjwatson> Various bits of partman-auto aren't desperately so
<infinity> cjwatson: And I'll do another bump tonight when ti-omap is done, no big deal.
<xnox> cjwatson: if it's pre-existing it's not very RC then =)
<cjwatson> Indeed
<cjwatson> And the last thing in the queue is libgnomecanvas, which stgraber was questioning whether it needed an FFe
<cjwatson> stgraber: If you think it would be bad for somebody else to accept it without having noticed the conversation, then reject and let stokachu know that it's a hold rather than a hard reject
<doko> cjwatson, pinged stokachu. maybe wait until Monday?
<cjwatson> doko: I'm in no rush to accept it; I just want to make sure somebody doesn't accept it without seeing this conversation
 * infinity would be inclined to grant it the FFe without the paperwork, personally.
 * cjwatson has no opinion on that
<cjwatson> The actual work looks fine to me, though I haven't line-by-lined it against Multiarch/Implementation
<infinity> Oh, hey, maybe those -16 kernels should be in the release pocket first.
 * infinity does that.
<cjwatson> Oops, did I miss that?  Sorry
<infinity> All better.
<infinity> I'll retry all the builds after the archive's sorter.
<cjwatson> It'll be an hour before d-i can build, then :-/
<infinity> And sorted, too.
 * cjwatson slowly climbs back up the stack to armel/powerpc builds working again
<cjwatson> copied gtk+3.0 from -proposed
<cjwatson> and I see -lowlatency's done too
<infinity> I copied it too.
<infinity> I may have also beaten you to gtk+3.0
<cjwatson> Meh, PCJs won't care much
<infinity> Sadly, sru-release doesn't appear to actually check pending publishing records.
<infinity> Or maybe it's copyPackage itself that doesn't.
<smartboyhw> Yay now I got scott's permission to send the mails:P
<cjwatson> sru-release doesn't; the check is done in the async job
<cjwatson> Or indeed Archive.copyPackage doesn't
<cjwatson> Wait, did I understand you right?
<infinity> Dunno.
<infinity> Clearly, the checks happen a bit late in the tools, given that one ends up with two ACCEPTs, and two messages to -changes, and then the OOPS later. :P
<cjwatson> Hah
<cjwatson> The OOPS is a bug no matter what
<cjwatson> I thought I'd fixed that, actually
<stgraber> cjwatson: is there a way to check who's the uploader for something in the queue?
<cjwatson> Maybe not well enough
<infinity> You may have fixed the OOPS.  Check your mail, since it's your ACCEPT that should have oopsed.
<slangasek> stgraber: yes, multiarching is not a no-risk change and ought to go through FFe
<infinity> But -changes definitely shows us both accepting gtk+3.0, so that part's broken for sure. :)
<cjwatson> stgraber: Look at the .changes
<ogra_> slangasek, i'm poked about a MIR for the xdg pam stuff ... coudl you file one ? security team is informed
<slangasek> if a separate bug is wanted for the MIR, sure
<ogra_> apparently :/
<infinity> cjwatson: The .changes in the queue unhelpfully has the signature stripped.
<mdeslaur> ogra_, slangasek: nah, that's fine
<mdeslaur> ogra_, slangasek: I'm about to comment in the ffe bug
<stgraber> infinity: was just about to point that out :)
<smartboyhw> skaet, I will help to send the release meeting emails, I got permission from scott-work :)
<slangasek> mdeslaur: ok cool
<ogra_> mdeslaur, oh, great, the people in -meeting disagreed so heavily :)
<Laney> and syncs have no .changes :-)
<slangasek> mdeslaur: how many beers is your comment costing me? :-)
<ogra_> slangasek, one
<mdeslaur> slangasek: none since you actually know how to write good code apparently :)
<ogra_> i dealt with that already ;)
<slangasek> heh
<infinity> Laney: Syncs in the queue actually have an uploader associated with them anyway, quite prominently, so that's not hard to track down. :P
<ogra_> oh, i made the deal with jdstrand ... so he might claim the beverage at UDS :)
<cjwatson> stgraber: I think failing that there's an API feature somewhere ...
<doko> slangasek, I don't care if it's a separate issue, just get the information filed and assign it to security
<Laney> infinity: not sponsoree though. So it's kind of the opposite to what you get from .changes
<cjwatson> (firefox hangs for a bit every time I look at +apidoc, so give me a minute)
<infinity> Laney: Uploader is the more interesting person to me, most of the time, in that I hold them responsible for whatever broke. :P
<cjwatson> huh, the uploader isn't exposed
<infinity> Laney: (If they want to hunt down the person they broke things on behalf of, that's their issue)
<cjwatson> It wouldn't be desperately hard to export PackageUpload.signing_key, if somebody wants a mini-project
<stgraber> cjwatson: getting a .uploader for queue entries giving us a person object would be neat, then I could finally have queuebot show the IRC nickname of the uploader :)
<cjwatson> Although it might be better to export an API method with a reference to the person
<cjwatson> So that you don't have to do URL hacking on signing_key.self_link to get it
<cjwatson> Somebody should file a bug for it at least :)
<cjwatson> It could just be a renamed version of findPersonToNotify
<cjwatson> Though worth checking that it behaves properly for syncs
<cjwatson> I suspect you could refactor _giveKarma a little bit in terms of it, too
<mdeslaur> skaet: ACK from the security team on pam-xdg-support (LP: #894391)
<ogra_> \o/
<cjwatson> processing linux-ac100
<slangasek> whoo, snowed the security team again
<infinity> mdeslaur: Many thanks.
<slangasek> fwiw before we seed it there's a license compatibility niggle to sort out
<stgraber> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1058186
<ubot2> Launchpad bug 1058186 in launchpad "Make it possible to retrieve the uploader (signer) of a package upload" [Undecided,New]
<cjwatson> Ta
<cjwatson> Any web UI change there would have to be careful to bulk-load the person objects or else it'll be timeout city
<cjwatson> I think there might be a query limit test on the queue page already - if not there should be :)
<cjwatson> Oh great, did somebody NBS-remove ac100 before processing NEW?
<cjwatson> Whoever that was triggered a bug in kernel-overrides. :-)
<infinity> cjwatson: linux-ac100 is pure universe anyway, if that helps.
<stgraber> ^ stokachu is now doing a few more rebuilds. I'll pull it from rejected once the paperwork is in order.
<cjwatson> infinity: Yeah, I worked that out
<skaet> thanks mdeslaur   :)
<cjwatson> I think the NBS bit may have been a red herring, as it let me remove those.  Probably a bug somewhere else in kernel-overrides.
<infinity> cjwatson: I can't say that I use kernel-overrides for >= precise anyway, since we don't actually have any kernel packages that publish to multiple components anymore.
<infinity> cjwatson: But I guess it helps that I also do kernels enough to know which ones live where.
<popey> skaet, when you have a moment, could you please review https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684 now b2 is out there
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
<infinity> cjwatson: (Well, that's even true of SRU kernels at this point, where I know exactly which bits live where, but that's more a sad statement about repetition...)
<cjwatson> Anyone have an opinion on the UIFe in bug 1043379?
<ubot2> Launchpad bug 1043379 in indicator-sync "[UIFe] sync indicator should use ubuntuone-client-* icons + new paused icon needed" [Low,Confirmed] https://launchpad.net/bugs/1043379
<cjwatson> Corresponds to an upload in the queue.
<stgraber> cjwatson: oh, I just rejected the upload because nobody had reviewed the UIFe yet :)
<cjwatson> Hah
<infinity> cjwatson: It doesn't sound like the sort of thing that would affect doc team screenshots and such, but they should probably still sign off.
<infinity> (The feature itself sounds like something we'd want though, IMO)
<cjwatson> Yeah
<infinity> jbicha: Opinions?
<Laney> didn't we (skaet) NACK indicator-sync by default anyway?
<Laney> so, not a UIFe requiring upload.
<infinity> Laney: ?
<infinity> Laney: Context?
<stgraber> stgraber@castiana:~$ seeded-in-ubuntu indicator-sync
<stgraber> gir1.2-syncmenu-0.1 (from indicator-sync) is seeded in:
<stgraber>   edubuntu: dvd
<stgraber>   ubuntu: daily-live
<stgraber> Laney: ^
<stgraber> and it's in main
<stgraber> ignore me, it's just an unrealted binary built from the same source :)
<stgraber> *unrelated
<Laney> I'm pretty sure it got denied.
<infinity> Yeah.
<infinity> I'm curious why that unrelated binary ends up in live, actually.
<jbicha> if indicator-sync isn't included by default, it doesn't need UIFE
<Laney> Which means not default which means not a UIF matter
<infinity> Right.
<infinity> Unrejecting. :P
 * cjwatson gives back a bunch more stuff
<stgraber> infinity: they don't, only thing in daily-live is gir1.2-syncmenu-0.1 (that or seeded-in-ubuntu is lying)
<infinity> stgraber: Yes, I was wondering about that binary specifically. :P
<stgraber> infinity: my guess is that ubuntuone is pulling it somehow so it can integrate if the indicator is installed
<Laney> yeah, stuff uses the APIs
<Laney> it's just not exposed in UI
<cjwatson> OK, FTBFS due to install failures trimmed a bit
 * infinity tidies up the gtkhtml rebuilds.
<infinity> Or, rather, will do so once this publisher run finishes.
<cjwatson> I thought I'd done that
<cjwatson> https://launchpad.net/ubuntu/+source/gtkhtml4.0/4.6.0-0ubuntu1 seems to be all built - did I miss something?
<infinity> cjwatson: I just forced it to build on armel and powerpc, but then evoltuion and a couple others need to build, I'm on it.
<infinity> cjwatson: It has slightly wonky shlibs.
<cjwatson> OK
<Daviey> stgraber, ScottK, skaet: Just looked at bug 1055684.. seems wedged on us.
<ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
<Laney> Daviey: The last comment says what's going to happen.
<ScottK> skaet: ^^^ is for your review.
<Daviey> Laney: Yes, blocked on us.
<Laney> Things are often blocked on us. It's designed that way
<Daviey> Laney: I'm really rather aware of that, but thanks for the patronising clarification,
<Daviey> I'm merely pinging it as a, 'lets look at this'.
<Laney> :/
<skaet> Daviey, ScottK, Laney - have added my thoughts to it,  and done some targetting.
<skaet> stgraber, ^
<Laney> cheers
<ScottK> Thanks.
<Laney> wasn't there another one we were re-reviewing too?
<Laney> emblems or something
<skaet> Laney,  mark commented on it.   priority is fixing critical bugs.
 * skaet goes to look it up,  checked on it last night and saw it was ok
<slangasek> doko: pre-promoting pam-xdg-support before it's seeded?  that's usually a good way to get it dropped out of main again when someone reconciles component-mismatches :)
<Laney> yep. I like it.
<Laney> ScottK: ^ perhaps you'd care to take -shopping?
<ScottK> What bug?
<Laney> bug #1055649
<ubot2> Launchpad bug 1055649 in unity-lens-shopping "[FFE] Change from http to https and verify cert" [Critical,Confirmed] https://launchpad.net/bugs/1055649
<ScottK> Approved.
<Laney> ScottK: It's in the queue too
 * Laney hopes that's ASAP enough
<cjwatson> slangasek: I thought it was usually a good way to get doko to object too ;-)
<ScottK> Excellent.
<Laney> can't approve it myself as it's my upload
<ScottK> Ah.
 * ScottK looks
<stgraber> hmm, looks like it's unbdling the preview code as well?
<Laney> hmm
<stgraber> which was rejected
<stgraber> http://launchpadlibrarian.net/117674538/unity-lens-shopping_6.0.0-0ubuntu1.1_6.0.0-0ubuntu2.diff.gz
<stgraber> a bit long just for a http => https change :)
<Laney> well, it's not 'just' that, but you might be right
<Laney> sec
<ScottK> Is queuediff broken for everyone or just me?  It lies about if there's a diff for ^^^ Laney's upload.
<Laney> oh, I get it, trunk got merged into the brnahc without me noticing
<Laney> rejecting, reuploading
<stgraber> seb128: can I ask you to detail the other fixes in light-themes? It's easy for me to spot what's related to the spinners and I agree that it's a bug but I have no idea what the other changes are and can't be sure they wouldn't need a UIFe
<stgraber> I'm fine with you simply explaining them on IRC, no need to re-upload
<seb128>   Fix hover check in rows
<seb128>   Fixes for the scale progressbar
<seb128> Fixes #1055376
<seb128> bug #1055376
<ubot2> Launchpad bug 1055376 in light-themes "gnome-panel not rendered correctly" [Undecided,Fix committed] https://launchpad.net/bugs/1055376
<seb128> fixes to scale in backdrop toolbar
<seb128>  
<seb128> stgraber, those are the commits
<stgraber> ok, that matches the diff. accepted
<stgraber> seb128: thanks
<seb128> stgraber, thanks
<Laney> stgraber: ^ take two
<Laney> looks like there's a little refactor in there that's not quite related to the SSL enabling
<Laney> but it doesn't seem bad to me
<stgraber> Laney: looking
<stgraber> well, once LP is kind enough to give me a diff ;)
 * Laney feeds LP some more hamsters
<Laney> really need to go, once this is OK
<popey> thanks for getting this sorted promptly guys & gals. really appreciated.
<Laney> â¥
 * Laney 's mind is now firmly on the tasty piece o'pork that's waiting to be cooked by me
<popey> ooh
<popey> i like the sound of that
<popey> i prefer the sound of someone else cooking food and bringing it to my door though
<Laney> might be a bit cold by then :(
<popey> well yes, Nottingham to Farnborough isn't likely to result in a hot meal in my lap :(
<popey> although I wasn't specifically requesting you do the making and delivering. i hear there are companies that will do that for me :)
<Laney> hot pork direct to your door
<Laney> ahem.
<popey> :)
<Laney> stgraber: a diff has arrived just for you
<stgraber> Laney: accepted
<Laney> yaaaaaaaay
<Laney> thanks
<stgraber> np
<popey> win
<Laney> branch pushed. I'm SO OUTTA HERE
<Laney> tara
<stgraber> I guess someone other than slangasek and myself should look at nfs-utils
<infinity> stgraber: I'll poke it with a stick.
<stgraber> thanks infinity
<doko> slangasek, I had it already promoted
<slangasek> doko: I think that's my point?
<slangasek> it's promoted before it's seeded
<slangasek> which means it now shows up on component-mismatches
<infinity> slangasek: How well-tested are these nfs-utils changes of yours?
<slangasek> infinity: I've tested them on my own network, which uses krb5 on both nfsv3 and nfsv4; I've also done some in-VM testing with extra sleeps sprinkled through to try to ferret out any race conditions
<infinity> slangasek: I note you use "mounting TYPE=nfs*" in your new upstart jobs, but (at least) nfs-common.statd-mounting.upstart still uses "mounting TYPE=nfs" (others may as well, that one just happened to show in the diff)
<infinity> slangasek: Intentional, or incomplete change to the wildcard?
<slangasek> infinity: intentional, with slightly inaccurate changelog description
<slangasek> infinity: the statd service is only relevant to nfs v3
<slangasek> so will never have TYPE=nfs4
<infinity> Oh, fair point.
<infinity> I was just thinking from the other direction (treat all nfs* the same), but yeah, nothing >> 3 will need statd, and there's no nfs3 type.
<slangasek> that was mostly about making things be TYPE=nfs* where they were TYPE=nfs4 before, because using 'nfs4' is deprecated (ask smb for details)
<infinity> Right, well, other than that, it looks sane, and it's not the sort of thing that's auditable without actual testing, so I'll trust that you and your VMs have had some quality time. :P
<micahg> are the dailies not on yet?
<infinity> micahg: They're on, but mostly broken due to the flood of stuff that built/skewed post-beta.
<micahg> infinity: ah, I didn't even see a log on people.c.c, so that prompted the question
<slangasek> should we perhaps have been rejecting more of those skew-inducing packages from the queue and requiring reuploads to -proposed?
<infinity> slangasek: Probably, yes.  I long for the day when uploads to $series just get rewritten as $series-proposed on accept.
<phillw> hiya good people, the kernel team have released 3.5.0-16.24 will it quietly arrive in the next iso daily build?
<skaet> infinity,  you going to spin the d-i to with that kernel?
<phillw> thank you queuebot :)
<phillw> the kernel fixes the nVidia issue, along with quite a list! https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1043518/comments/45
<ubot2> Launchpad bug 1043518 in linux "live cd is unusable due to video degradation with the splash boot option enabled" [High,Fix released]
<infinity> skaet: d-i was already rebuilt for the latest kernel, but there will be another one for omap4 as well soon.
<infinity> skaet: Oh, right, new kernel again.  Yes, there will be a new d-i to match. :P
<phillw> infinity: will it arrive in tomorrows' cron build? (I ask so I can let the testers affected by it know).
<infinity> phillw: If tomorrow's image builds work, the new kernel will be in them, yes.
<phillw> thanks :)
<skaet> thanks infinity
<stgraber> why do I have the feeling that we'll see those again soon?
<Daviey> stgraber: any moment... I rejected.
<kenvandine> stgraber, they are coming again!
<Daviey> queuebot: mute queue new
<Daviey> mute ubuntu-release new quantal-releas
<Daviey> mute ubuntu-release new quantal-release
<Daviey> (i'm causing just as much noise, trying to remmeber the synatx))
<stgraber> yeah and the muting wasn't quite working last time someone tried it
<stgraber> mute queue New
<Daviey> i suck.
<kenvandine> Daviey, you seem to have muted it
<Daviey> kenvandine: stgraber did
<kenvandine> oh
<kenvandine> hehe
<kenvandine> stgraber, you can unmute now
<stgraber> [2012/09/28 20:01:20] DEBUG: New => returning 20 items
<kenvandine> they are in
<Daviey> wait
<Daviey> noise of acceptance, and noise of binaries, and noise of binary acceptance
<kenvandine> Daviey, i hope you aren't going to make poor alex change something else :)
<kenvandine> ah
<kenvandine> whew
<stgraber> you shold have pushed an extra 5 webapps, then the flood protection of the bot would have kicked in :)
<stgraber> *should
<Daviey> hah
<Daviey> kenvandine: first binary accepted :)
<Daviey> unmute queue New
<Daviey> kenvandine: all done
<kenvandine> Daviey, thanks!
<xnox> Why did I stop getting emails about syncs?
<xnox> I used to always get email about it e.g. now in unapproved queue as a sponsor.
<xnox> syncpackage: Request succeeded; you should get an e-mail once it is processed.
<xnox> namazu2 ^^^^
 * xnox is annoyed.
<stgraber> e-mails coming from the DC have been quite delayed for me lately, some coming in 2-3 hours after upload (or any other change really)
<stgraber> haven't requested syncs in a while though so I'm not sure if those are completely broken
<Laney> I haven't gotten Waiting for Approval mails for syncs
<Laney> did get accepted though
<xnox> Laney: ever or lately?
<Laney> xnox: I can't see that I ever had one
<xnox> bug 1058364
<ubot2> Launchpad bug 1058364 in ubuntu-dev-tools "not getting 'waiting for approval' email when sponsoring syncs when the archive is frozen" [Low,New] https://launchpad.net/bugs/1058364
<xnox> it also affects launchpad
<Laney> it /only/ affect launchpad
<Laney> not much udt can do about that
<xnox> Laney: not tell me to wait for an email?! =)
<Laney> you also never get FTBFS emails from API syncs
<xnox> Laney: loop and query the queue same as queubot does
<xnox> Laney: well =) i don't want those
 * xnox runs away
<ogasawara> ^^ When someone has a moment, could I get the linux-3.5.0-16.25 kernel approved in the queue
<infinity> ogasawara: Yep.
<ogasawara> infinity: thanks!
<infinity> ogasawara: You keep pre-empting my d-i uploads. :P
<xnox> infinity: you should spinlock ogasawara
<xnox> =)))))
<infinity> That sounds dirty.
<ogasawara> heh
 * ScottK says "No, it can wait for 'R' again" ...
#ubuntu-release 2012-09-29
<phillw> ogasawara: do you have time for a quick(ish) chat?
 * infinity grumbles at his own sloppiness and uploads dpkg.
<infinity> Hrm, maybe I should make that match in style with the other maintainer scripts.
<ogasawara> phillw: sorry, am busy at the moment.  ping/email me any question(s) you have and I'll try to get to it later.
<infinity> stgraber: When you wander past your screen, care to review that dpkg in the queue?  (I tested it locally to make sure it'd no longer braindead)
<infinity> s/it'd/it's/
<ScottK> If someone will accept lsb when it appears, that'll mean I can remove Qt3.
<infinity> ScottK: The changelog doesn't even remotely match the diff. :P
 * ScottK looks
<infinity> I'm assuming s/suggests/depends/ and s/README/NEWS/, mind you.
<ScottK> I'll fix it.
<ScottK> Beyond those corrections, OK?
<infinity> Assuming debhelper DTRT with the package.NEWS file, I've never used that facility.
<infinity> And dh_installchangelogs(1) seems to agree that it will.
<infinity> So, yeah.  All good except for the changelog being full of thinkos.
<ScottK> OK.
<ScottK> New one on the way.
<ScottK> infinity: Thanks.
 * ScottK goes to put a kid to bed.
<ScottK> infinity: Thanks.  Qt3 is gone too.
<stgraber> infinity: looking
<stgraber> infinity: there you go
<infinity> cjwatson: Since you seem to be around, quick brainless d-i review for you ^^
<infinity> (And thanks for promoting the kernels, so I didn't have to wait an hour)
<cjwatson> np
<cjwatson> done
<kees> anyone around to accept the youtube-dl sync request?
<kees> this is for LP: #1058721 and LP: #1057535
<tumbleweed> kees: there was already one in the queue :)
<kees> tumbleweed: yeah, there wasn't a sync bug open for it, so I missed it. :P
<tumbleweed> anyway, accepted
<kees> tumbleweed: I noticed the other bug only after. :) thanks!
#ubuntu-release 2012-09-30
<doko_> please could somebody accept the final python 3.3.0?
<Laney> what happens if I copy including binaries from one archive to another which builds for more arches? breakage or correctly created missing build records?
<cjwatson> doko_: Err, I accepted the final python 3.3.0 yesterday.
<stgraber>  language-pack-kde-engb : Depends: language-pack-engb but it is not installable
<stgraber>  language-pack-kde-zhcn : Depends: language-pack-zhcn but it is not installable
<stgraber>  language-pack-kde-zhtw : Depends: language-pack-zhtw but it is not installable
<stgraber> looks like these 3 -kde langpacks should be removed from the archive as their matching language-pack package no longer exists
<cjwatson> stgraber: it's not that they no longer exist, it's that they never existed
<cjwatson> en_GB has always been in -en; zh_CN is in -zh-hans; and zh_TW is in -zh-hant
<cjwatson> stgraber: so maybe it'd be more correct to fix those packages?  ask the Kubuntu folks
<stgraber> hmm, ok, so the langpack generator broke in quantal... I spotted this when preparing a new weblive server which installs "^language-pack-kde-.*". The pattern works for precise and fails on quantal.
<stgraber> ScottK: ^ is that anything you have control over or should I poke dpm?
<cjwatson> I'm actually slightly surprised we still have language-pack-kde-*, since I thought the Kubuntu developers wanted to ditch them
<cjwatson> But it may be too late for that
#ubuntu-release 2013-09-23
<maclin> Is anyone nearby can help to confirm the problem of qatracker rebuilding? I request a rebuild of UbuntuKylin on qatracker yesterday, But it has keep rebuilding status for 14+ hours  and I can't cancel the rebuild now.
<ScottK> debfx: It's technically open, but if it's in Debian, I don't mind doing a sync, just file an FFe bug for the record.
<infinity> slangasek: New fakeroot in sid has a patch from you.  Did you want to sync that?
<slangasek> infinity: that patch is nothing urgent.  setpriority() no longer causes problems for upstart builds.
<ScottK> infinity: If you have a spare tuit, would you please take a gander at https://bugs.launchpad.net/ubuntu/+source/lesstif2/+bug/1222747/comments/29  - My brain is far to fuzzy to trust ATM.
<maclin> infinity, hi
<infinity> ScottK: Looked at and commented.
<ScottK> infinity: Thanks.
<cjwatson> maclin: The i386 livefs builder has been down all weekend and requires physical attention to bring it back up.  It's not specific to UbuntuKylin.
<cjwatson> (Replying in two places since you asked in two places.  Best not to do that really.)
<JackYu> cjwatson, :).
<maclin> cjwatson, thanks
<JackYu> cjwatson, hi, would you help to review the FFe request at bug #1227197?
<cjwatson> I have a lot to do this morning, sorry
<JackYu> ok:(
<attente> hello, is there anyone i can talk to about this FFe? https://bugs.launchpad.net/unity-greeter/+bug/1228207
<Laney> I'll look at the list of FFes later on
<cjwatson> Laney: Wanna set up a migration block for final beta?
<Laney> cjwatson: oh, yes, OK
<Laney> give me a sec and I'll pastebin the list the script gives for you to review
<smartboyhw> Laney, um, we have uploads for Studio here waiting to be uploaded for Final Beta and nobody is sponsoring
<Laney> Things can be unblocked
<smartboyhw> Laney, sure, telling you that:)
<Laney> cjwatson: http://paste.ubuntu.com/6144679
<cjwatson> Didn't moin used to have a copy-page action?
<Laney> does here
<cjwatson> Where is it? :)
<cjwatson> Laney: TBH I'm not sure I can realistically review this.  What flavours did you select?
<Laney> More actions: combo
<Laney> ?action=CopyPage
<cjwatson> Laney: Don't see it on help.ubuntu.com/community
<Laney> oh, help, was on wiki
<cjwatson> "Unknown action CopyPage"
<cjwatson> so not supported there I guess
<Laney> I don't think I have meaningful access to that one
<cjwatson> Never mind, will just do it the crude way
<Laney> ['ubuntu-gnome', 'xubuntu', 'lubuntu', 'ubuntukylin', 'kubuntu', 'edubuntu', 'ubuntustudio', 'ubuntu', 'ubuntu-server']
<cjwatson> Laney: Seems to be roughly plausible for that, I'd say go ahead
<Laney> Roger. I just wanted a sanity check that I didn't completely break it in ways that I wasn't seeing.
<Laney> done
 * Laney mails -devel
<cjwatson> stgraber: Could you prepare a final beta milestone on the ISO tracker?
<cjwatson> stgraber: Hm, never mind, I think I can
<Laney> Yeah, any RT member can do
<cjwatson> The "based on manifest" column seems fairly random - I went for "yes"
<cjwatson> And hopefully it's still correct to edit ~cdimage/.isotracker.conf
<Laney> No
<cjwatson> ?
<Laney> If you tick the "automtically publish" thing then it copies from daily to the milestone
<cjwatson> Oh right
<Laney> I think based on that manifest toggle
<cjwatson> I'll edit *Process to say that then
<Laney> good idea
<cjwatson> Laney: did you mail -devel-announce?
* cjwatson changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: beta freeze | Saucy Salamander 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
<Laney> cjwatson: No, just devel
<Laney> Can bounce if you want
<cjwatson> please
<Laney> Also, one more thing that I remember
<Laney> The manifest http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/37/manifest needs to be current for publishing to the milestone to work
<Laney> bounced
<cjwatson> OK, so we should re-enable netboot, Ubuntu desktop {amd64,amd64+mac,armhf+omap4,i386}, core, and Ubuntu server?
<cjwatson> I've done that, shout if wrong
<cjwatson> debian-cd/CONF.sh tweaked
<cjwatson> infinity: I've done most of the technical actions necessary up to this point, I think.  I haven't done anything like contacting marketing for release notes, checking with QA/certification, etc.
<cjwatson> seeing as I'm not actually signed up for beta ;-)
<forestpiskie> sorry to bother you busy chaps - do I need to deal with this http://iso.qa.ubuntu.com/admin/config/services/qatracker/builds to get beta2 to show up on the tracker for us?
 * forestpiskie is new to this :)
<Laney> forestpiskie: The next build should show up automatically if you are in http://iso.qa.ubuntu.com/qatracker/series/37/manifest
<forestpiskie> yep - we are - just wanted to check, thanks
<Laney> Assuming another one happens (don't know if a full respin will take place) - otherwise the current daily can be copied over
<elfy> Laney: I'll just let it chunter away and check later then - thanks
<Laney> mmk
<Laney> did my bounce to u-d-a work?
<cjwatson> yes, just approved now
<Laney> ah, k, didn't get a moderation mail
<cjwatson> FYI: Tomorrow morning we hope to be moving some archive jobs to a new machine.  Vulnerable services: saucy-proposed -> saucy migration, any content under http://people.canonical.com/~ubuntu-archive/
<cjwatson> Uploads, builds, publication to saucy-proposed and stable releases, and downloads from the archive will be unaffected
<Laney> yay!
<cjwatson> Laney: Do you know why unity-scope-click showed up in your block?
<cjwatson> I don't see it in images
<Laney> let me see
<cjwatson> I only see it in ubuntu-touch, which you didn't list
<cjwatson> didrocks: ^-
<didrocks> yeah, it's only used and installed on touch
<Laney> probably a bug, sec
<asac> ubuntu-touch-session is the same
<Laney> haha, I forgot to put back the code to consider the flavours
<cjwatson> Whoops
<Laney> that block is probably everything seeded on all images
<didrocks> Laney: how long do you think it will take you? I can help unblocking to get a touch image for now if needed (listing ubuntu-touch-session and unity-scope-click)
<asac> ok ... could you unblock unity-click-scope and camera-app
<Laney> two seconds
<asac> and ubuntu-touch-session?
<Laney> there's no need to unblock things
<asac> thanks
<asac> ah ok
<didrocks> ok, great that the code is still around
<didrocks> thanks Laney
<asac> so this will just move after fixing the bug?
<cjwatson> Yeah
<asac> awesome
<Laney> somehow gsettings-ubuntu-touch-schemas got onto edubuntu
<Laney> block should be better now, modulo that and anything else in the same situation
<Laney> like ubuntu-system-settings
<Laney> hmm
<cjwatson> well, I've done the block/unblock delegation for touch as mentioned on ubuntu-release@, so if it's just the odd edge case then they can unblock for themselves
<Laney> I doubt edubuntu actually want ubuntu-system-settings though
<Laney> now why did that happen
<Laney> oh, because of default_milestone
<smartboyhw> Please unblock ubuntustudio-lightdm-theme and ubuntustudio-default-settings from saucy-proposed.
<cjwatson> Laney: damn, did I not set it back?
<Laney> cjwatson: no, but I fixed it
<Laney> hopefully ...
<ogra_> Laney, is slomos comment on the gst-bad bug enough for you or do i need to hunt him down again to actually leave a bug comment ?
<Laney> ogra_: Don't know, not read it
<Laney> Let me see
<ogra_> :)
<ogra_> i just added it, he didnt comment on the bug itself but left a line on IRc
<Laney> haha
<Laney> I'm trying to get at whether we'll have fun with the packaging in future
<ogra_> i think the long term plan is to give the package its own source too (if thats possible witout forking the whole thing)
<ogra_> though thats not 13.10 material
<Laney> is it?
<ogra_> dunno
<Laney> Not sure upstream would go for that
<ogra_> if it can be merged fully upstream then the current approach is fine
<Laney> nobody has told me they don't think it can be
<ogra_> but i think upstream it would have to be a completely new plugin in the end ... i assume whoever wrote the android codec plugin this comes from didnt want to use hybris
<Laney> see jim's comments there
<Laney> anyway. Let's do it.
<ogra_> ah, right
 * ogra_ hugs Laney 
<cjwatson> Laney: thanks, sorry about that
<Laney> cjwatson: no problem
<smartboyhw> Laney, saw my unblocking request? :)
<Laney> yes, so did other RT members; doing other stuff currently
<smartboyhw> Release Team: BTW, it looks like i386 images are simply not been built (it does build fail according to e-mail sent to our -devel mailing list, but I get no LiveFS build log at people.canonical.com/~ubuntu-archive)
<smartboyhw> It started since 20130920
<smartboyhw> I'm wondering if it is related to the previous downtime of London Canonical datacentre.
<smartboyhw> Shouldn't be the reason though
<smartboyhw> It happens to at least us, Kylin. Xubuntu, Lubuntu
<smartboyhw> Even Ubuntu desktop
<Laney> The machine went down
<smartboyhw> uh:(
<Laney> Being worked on
<smartboyhw> Laney, thanks
<ScottK> smartboyhw: Also, already mentioned in this channel about 3 1/2 hours ago.
<smartboyhw> ScottK, oh, I didn't notice the backlogs about that
<Riddell> smartboyhw: I agree, no i386 logs in sight
<ScottK> Riddell: the builder is down.
<Riddell> ScottK: ah hah
<cjwatson> smartboyhw: Sysadmins have iLO access now, so it's waiting for a prod via that
<smartboyhw> cjwatson, what's iLO?
<smartboyhw> -.-
<cjwatson> remote console
<smartboyhw> cjwatson, ah great:)
<cjwatson> The i386 livefs builder is back; I'll do a bunch of builds shortly unless somebody wants to beat me to it
<knome> infinity, ping me when you've set Beta 2 release notes up for tweaking :)
<knome> infinity, or ping me and tell me we should do that ourself. :)
<smartboyhw> s/ourself/ourselves/ :)
<jhodapp> ScottK, ping
<Riddell> jhodapp: if it's about kubuntu I can help
<jhodapp> Riddell, it's about qtmultimedia
<Riddell> that bundle of joy
<jhodapp> :)
<Riddell> jhodapp: what's the question?
<ogra_> heh
<jhodapp> Riddell, we need an approver for this FFe once it hits the NEW queue: https://bugs.launchpad.net/ubuntu/+bug/1227987
<ogra_> jhodapp, no, you need an approver for the FFe before you upload
<jhodapp> ok :)
<smartboyhw> Anyhow, he's asking the correct person:P
<ogra_> jhodapp, when it hits the archive you need an approver from the ubuntu-archive team to get it through NEW
<jhodapp> Riddell, what orga_ said :)
<jhodapp> ogra_, thanks for the clarification
<ogra_> so first of all ubuntu-release approval, then the rest :)
<jhodapp> ogra_, cool, this part is all new to me
<ogra_> yeah, thats all these distro processes .... :) you cant know them yet
<Riddell> jhodapp: commented I can do New
<jhodapp> Riddell, awesome...you're able to do that today by chance?
<Riddell> jhodapp: yeah should be able to but it still needs a FFe
 * ogra_ hugs Riddell 
<Riddell> jhodapp: presumably you're in contact with upstream to get it merged?
<Riddell> jhodapp: are you wanting this in beta 2?
<jhodapp> Riddell, I'm not in contact yet, but will be heading that way soon...rsalveti might have been talking with someone from upstream though
<Riddell> jhodapp: who else uses qtmultimedia 5 and might be affected?
<ogra_> Riddell, thats all for ubuntu-touch
<jhodapp> Riddell, yeah, this is a diverted package only for touch
<ogra_> Riddell, we dont do beta ... (we do every single image like a milestone for touch)
<jhodapp> Riddell, sergiusens put the package together if you have questions specific to that
<Riddell> jhodapp: what does qtmultimedia 5 use now instead of gstreamer?
<jhodapp> Riddell, still uses gstreamer, just ported to 1.x
<Riddell> jhodapp: this is quite a major feature to port to 1.0 isn't it? wouldn't you want to be in contact with upstream to ensure you're not duplicating anything?
<jhodapp> Riddell, but the reason we had to make a diverted package is because it doesn't port the mediacapture nor the camerabin support, which would break things on the desktop if we simply replaced the qtmultimedia package
<jhodapp> Riddell, the person who started the port was in contact with them and said there wasn't anything available yet for porting to 1.x
<Riddell> jhodapp: presumably there's no sensible reason to install this except being an ubuntu edge user on a phone/tablet? so it shouldn't get in the way of desktop users
<ogra_> Riddell, yeah
<jhodapp> Riddell, exactly
<ogra_> it wont go into desktop
<jhodapp> correct
<sergiusens> not for desktop at all
<jhodapp> Riddell, any other questions we can answer?
<Riddell> jhodapp: nope, approved!
<jhodapp> Riddell, excellent, thanks much
<Riddell> poke me when you need a review, although I'm doing install testing so may not be around for some periods
<jhodapp> Riddell, ok
<cjwatson> crontab disabled, kicking off a full round of builds now
<jhodapp> ogra_, can you push the packages for us now that we have approval? :)
<ogra_> yeah, where are the source packages ?
<jhodapp> sergiusens, ^
<jhodapp> ogra_, so when we have bug fixes to these packages, we don't have to go through the same approval process, correct?
<sergiusens> https://code.launchpad.net/~phablet-team/phablet-extras/qtmultimedia-touch
<sergiusens> ogra_, jhodapp &^^
<ogra_> jhodapp, right, its just for getting it in
<jhodapp> ogra_, ok excellent
<tkamppeter> Hi, I have synced pyppd and hplip from Debian to get a security fix into Saucy. The fix is in HPLIP, thepyppd update merely only bumbs the version number, fulfilling a dependency of HPLIP and does not have real changes otherwise.
<tkamppeter> They two, pyppd and hplip need to be moved into the release now.
<kgunn> didrocks: ok, i filed an FFe for libmirclient
<kgunn> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1229212
<didrocks> kgunn: don't assign, please subscribe the release team to it
<kgunn> didrocks: gah...sorry
<didrocks> Riddell: Laney: hey, do you have some time to have a look at that one? ^
<didrocks> that would be helpful so that we can proceed and get latest Mir for touch
<didrocks> (it has no real impact for desktop, apart from the rebuilds)
<kgunn> didrocks: thinking...does mirserver also need one ? for since u-s-c is there....altho its in universe
<ogra_> sergiusens, hmm, thats just the debian dir
<didrocks> kgunn: it doesn't impact desktop image as u-s-c isn't installed by default on desktop, the ABI breakage is for Touch, so I would say this will fall in the Touch FFe
<sergiusens> ogra_, bzr bd -S
<kgunn> didrocks: ack, agree...but wanted to make sure
<ogra_> sergiusens, what source tarball does it use ? i dont think we can upload the same upstream source tarball twice
<cjwatson> You can upload it twice as long as the contents are identical or the name is changed
<sergiusens> ogra_, it's a different source package
<ogra_> cjwatson, ah, thanks
<sergiusens> ogra_, do I need to change anything then?
<sergiusens> ogra_, source package gets a name like qtmultimedia-opensource-src-touch_5.1.1+git20130920+5b12abb862.orig.tar.gz
<ogra_> sergiusens, let me test build ...
<ogra_> i guess its alll fine
<sergiusens> ogra_, takes it's time ;-)
<ogra_> yeah
<sergiusens> ogra_, the latest build is also on ppa:sergiusens/phablet
<ogra_> my chromebook is chuggin away :)
<ogra_> grrr
<ogra_> build-deps
<Riddell> kgunn: bug is now unassigned?
<kgunn> Riddell: sorry, shall i reassign it?
<Riddell> kgunn: doesn't really matter just wondered what it ment
<kgunn> Riddell: me screwing up :)
<Riddell> oh you following the "subscribe (do not assign to) the 'ubuntu-release' team. " instruction :)
<Riddell> kgunn: what are the rdepends?
<kgunn> Riddell: right...so, shall  i just update the bug with "apt-rdepends libmirclient" ?
<kgunn> making sure i get the right rdepends
<Riddell> kgunn: yeah, and note which flavours it affects
<jhodapp> ogra_, are you working on qtmultimedia right now or in a bit? We also need our gst-plugins-bad-hybris package pushed as well
<ogra_> jhodapp, do you know if ricardo comes back today or tomorrow ?
<jhodapp> ogra_, I thought tomorrow
<ogra_> i wanted to leave the plugin part to him
<ogra_> hmm
<ogra_> then i should probably upload that too, ok
<kgunn> Riddell: ok updated
<ogra_> i'll try to get both done before end of my day
<jhodapp> ogra_, ok excellent...can you let me know when you've pushed them and I can help verify that everything is good once they land
<Riddell> kgunn: that's dependencies not rdepends no?
<ogra_> jhodapp, indeed
<jhodapp> ogra_, thanks
<JackYu> Laney, hi. May I know when will you review the FFe at bug #1227197? It's middle night here:)
<sergiusens> ogra_, tomorrow
<kgunn> Riddell: bah...sorry...now its right
<Riddell> kgunn: which flavours does this affect?
<kgunn> Riddell: when you say flavours...do you mean desktops ? unity, xubuntu etc ?
<Riddell> kgunn: yes flavours are ubuntu (unity), edubuntu, ubuntu studio,mythbuntu etc
<Riddell> those ones might all be affected I don't konw
<doko> Laney, "Not touching package due to block request by laney" -> libnetfilter-conntrack
<Laney> see ubuntu-devel-announce
<kgunn> Riddell: i think the answer is, any flavour using 13.10
<cjwatson> Flavours don't *use* 13.10 as such
<kgunn> cjwatson: i think my conjecture is still accurate right ?
<cjwatson> And I didn't think all flavours were using Mir?
<cjwatson> (If nothing else, server is clearly unaffected, but I thought others had opted out of Xmir too)
<kgunn> cjwatson: there's no dependency on mir per se....in xmir mir sits under x unbeknownst to anyone, but yes...people can choose to fallback to no xmir
<cjwatson> Is libmirclient2 even on any images right now (other than touch)?  seeded-in-ubuntu suggests now
<cjwatson> *not
<cjwatson> kgunn: I thought you at least had to have the xserver-xorg-xmir package installed to use it
<kgunn> cjohnston: libmirclient2 is part of main archive, yes...you do have to have xmir installed( also part of main archive)...but the real trigger is the install of unity-system-compositor
<cjwatson> Which is not even in Ubuntu desktop images never mind anything else
<kgunn> cjohnston: unity-system-compositor is in universe
<cjwatson> I'm cjwatson not cjohnston
<cjwatson> So therefore this doesn't affect any flavours (other than touch) in their default configurations right now
<kgunn> cjwatson: woops...sorry cjohnston
<kgunn> cjwatson: that is technically correct
<cjwatson> I would recommend you take that interpretation as it makes it easier for you to land your change :-)
<kgunn> cjwatson: awesome...thank you for the navigation of logic there :)
<cjwatson> Also FYI xserver-xorg-xmir is in universe, not main
<kgunn> cjwatson: reallly...so u-s-c install must pull it in ?
<Riddell> u-s-c?
<Riddell> software centre?
<cjwatson> kgunn: Yes
<kgunn> cjwatson: wow..your right...hadn;t looked....
<cjwatson> Riddell: unity-system-compositor
<Riddell> aah
<kgunn> Riddell: sorry...u-s-c, unity-system-compositor
<kgunn> cjwatson: i was under the belief that we had everything but unity-system-compositor in main...thanks for pointing that out
<cjwatson> It doesn't matter that much; xserver-xorg-xmir is a binary package produced by a source package in main, so it can be moved to main without paperwork once it becomes necessary for something else
<Riddell> kgunn: where are these touch images that it goes onto?
<ogra_>  dpkg-source -b gst-plugins-bad1.0-1.1.4
<ogra_> dpkg-source: info: using source format `3.0 (quilt)'
<ogra_> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<ogra_> GRRR
<ogra_> so how do i work around that ?
<kgunn> Riddell: http://cdimage.ubuntu.com/ubuntu-touch/
<ogra_> (an ubuntu maintainer committed with a canonical address)
<Riddell> kgunn: cleverly hidden under ubuntu-touch-preview/ :)
<kgunn> we're tricky like that
<Riddell> ogra_: fix the maintainer line?
<didrocks> ogra_: DEBEMAIL=foo
<didrocks> ogra_: if you -k for signing
<JackYu> cjwatson, can we unblock some packages for UbuntuKylin flavor?
<ogra_> Riddell, i dont want to change the changelog :) i just want to sign it :)
<Riddell> kgunn: so aye if it's in touch only and the touch people are happy with it that's all good
<cjwatson> ogra_: you don't need to
<Riddell> ogra_: it's not changelog it's debian/control
<Riddell> paste in Maintainer: Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
<Riddell> XSBC-Original-
<cjwatson> ogra_: just set DEBEMAIL to something that doesn't contain ubuntu when you run debuild
<Riddell> adapted to your preferred team
<cjwatson> ogra_: that downgrades the error to a warning
<ogra_> oh
<ogra_> !
<kgunn> Riddell: yeah...they want us to land real bad...hence my showing up here :)
<kgunn> didrocks: ^
<cjwatson> JackYu: sure
<ogra_> thats news to me thanks !!!!
<didrocks> kgunn: saw it, please ping me once all the bumps we talked about are done
<cjwatson> and Riddell is right, this isn't about what you commit as, it's about the Maintainer field
<didrocks> kgunn: I'm changing the config
<didrocks> kgunn: and please merge my branch as well :)
<didrocks> kgunn: also please, ensure the changelog reference that bug number (as you are doing a merge to bump the version anyway)
<JackYu> cjwatson, great, please unlock youker-assistant and ubuntukylin-default-settings.
<cjwatson> Versions?
<cjwatson> JackYu: ^-
<cjwatson> BTW, please move away from the model where you have a single preferred contact point - I'm not always around
<JackYu> cjwatson, ubuntukylin-default-settings 1.0.7 and youker-assistant 0.2.1. The youker-assistant is still waiting for FFe review:)
<JackYu> cjwatson, got it.
<cjwatson> I'm not going to unblock something not in the archive yet, sorry
<cjwatson> Looking at ubuntukylin-default-settings
<JackYu> ok
<cjwatson> "* add some package dependencies and delete some packages" - your uploaders really need to be less vague!
<jhodapp> Riddell, both gst-plugins-bad and qtmultimedia are in the NEW queue and waiting for your approval
<Riddell> jhodapp: queuebot disagrees :)
<jhodapp> ogra_, ^
<ogra_> jhodapp, he was to fast for you
<ogra_> :)
<ogra_> Riddell, coudl we get gst-plugins-bad too ?
 * ogra_ digs for the FFe
<JackYu> cjwatson, happyaron is here:)
<Riddell> ogra_: waiting for it to appear in new, where's the FFe?
<ogra_> bug 1224665
<cjwatson> JackYu: The uploader in this case is ShuiLu Pi, who I don't think is happyaron
 * ogra_ tickles ubotu
<cjwatson> JackYu: Also, disabling apport and whoopsie entirely?  *Really*?
<cjwatson> You intentionally want to make sure that UbuntuKylin is left out of any error analysis, so we won't notice if a change regresses something for Chinese speakers?
<ogra_> Riddell, thanks for the hint btw, i fixed the maintainer address in the end :)
<cjwatson> JackYu: And there's a misspelling, "UbuntyKylin"
<JackYu> cjwaston, yes, I will tell Pi.
<cjwatson> JackYu: Do you know if it's intentional that depends.txt was entirely removed?
<JackYu> cjwatson, yes
<cjwatson> JackYu: And putting random stuff in /etc/environment is not really the best plan - that will be hard to upgrade later
<cjwatson> JackYu: I'm sorry, I'm not at all happy with this upload and don't really want to unblock it while I have the choice.  The random Upstart overrides with no explanation are the worst (I see it also disables avahi-daemon and modemmanager), but really, all of the stuff I just mentioned should be addressed
<cjwatson> JackYu: Could you pass this on?
<cjwatson> JackYu: depends.txt> So you don't want e.g. unity-china-music-scope any more?
<JackYu> cjwatson, OK, let me check your comments and hope we can fix it soon.
<Riddell> ogra_: I'm away in 10 minutes, upload soon if you want me to New review it
<ogra_> Riddell, i uploaded quite a while ago
<ogra_> Riddell, didnt get a reciept either yet
<JackYu> cjwatson, we use recommends.txt instead of depends.txt, since if using depends.txt, removing one package will lead to the fail of default-settings.
<Riddell> ogra_: something may have gone wrong then
<cjwatson> JackYu: Ah, right.  Mentioning that the removed dependencies were duplicated as Recommends is the sort of thing that should have been mentioned in the changelog.
<ogra_> Riddell, oh, indeed, iwont get a reciept mail since rsalveti owns the changelog
<cjwatson> JackYu: I notice that gnome-tweak-tool and chromium-browser are not in recommends.txt, though.
<cjwatson> ogra_: Normally the signer is notified too.
<ogra_> https://launchpad.net/ubuntu/saucy/+source/gst-plugins-bad1.0/1.1.4-2ubuntu2
<ogra_> well, its already building
<JackYu> cjwatson, yes. we don't want to include these two packages.
<ogra_> Riddell, we only need you for binary NEW for this one actually
<cjwatson> JackYu: OK.  Again, changelog :-)
<cjwatson> JackYu: It's not just for me, it's for your users too
<ogra_> Riddell, i'll try to find someone else for that then
<ogra_> cjwatson, well, i didnt ... i get other ubuntu mail so my mail server seems to be fine
<JackYu> cjwatson, yes, we should add more changelog for our decision:)
<ogra_> could some archive admin let the gst/plugins/bad and qtmultimedia-opensource-src-touch builds out of binary NEW ?
<jhodapp> Riddell, ^
<ogra_> jhodapp, he said he would be out
<jhodapp> Riddell, ah missed that message
<ogra_> cjwatson, could you perhaps ?
<slangasek> ogra_: so we have a parallel upload of qtmultimedia-opensource now for touch?
<ogra_> slangasek, atm yeah
<ogra_> 5.1.1 vs 5.0.x i thinnk
<slangasek> ah
<slangasek> did someone already work out how we're going to transition back to the main packages once they bump to 5.1 in t?
<ogra_> heh, not sure
<ogra_> sergiusens, ^^ ?
<slangasek> the package names all look ok, as far as that goes
<ogra_> we had a few reviews from different people
<ogra_> and endless tests across the team
<slangasek> which of those were archive admins?
<sergiusens> slangasek, ogra_ do we need a test scenario?
<ogra_> slangasek, Riddell ... who let it through source NEW as well
<sergiusens> I can stage one in a PPA and see how it goes
<ogra_> sergiusens, nah, i dont think we do
<ogra_> we can test from the archive
<ogra_> nothing is seeded yet
<ogra_> we just need them through NEW
<ogra_> so you can pull from the archive actually :)
<slangasek> ogra_: ack
<infinity> Gah, alarm clock fail.
<ogra_> slangasek, the gst-plugins-bad one too ?
<ogra_> there should be a new binary as well
<ogra_> -hybris iirc
<mdeslaur> Laney: could you unblock pyopenssl in saucy-proposed, please?
<slangasek> ogra_: hadn't gotten to it yet, doing it now
 * ogra_ hugs slangasek 
<ogra_> jhodapp, ^^^
<jhodapp> awesome, thanks slangasek
<slangasek> ogra_: and gstreamer1.0-hybris is added on i386 in addition to armhf for the goldfish case?
<ogra_> slangasek, right, just not amd64
<ogra_> (and ppc)
<infinity> slangasek / cjwatson: Either of you want to catch me up with reality, since I seem to have entirely missed out on what should have been Monday morning?
<slangasek> infinity: I think reality has mostly been waiting for you.  but we have an i386 livefs builder again, so that's good news
<slangasek> and the beta freeze is on
<infinity> s/freeze/block/
<infinity> Laney: Thanks for putting the block in.  No thanks for it being right before glibc would have migrated. ;)
<slangasek> I assume we want glibc up to date for beta, however
<slangasek> have you forced it in yet?
<infinity> slangasek: I haven't unblocked it, it's not particularly critical.  Just a security fix, a testsuite fix (which has already made jenkins happy, so meh), and a compiler swap for arm64.
<slangasek> yes, but if you want it for release it should go in for beta
<infinity> slangasek: But if other things are being unblocked and the world's still spinning, there's no harm in taking it either.
 * infinity unblocks.
<Laney> mdeslaur: N
<slangasek> okie
<Laney> Not here, ask someone else
<Laney> I want to set up a role account for milestone blocks so that I don't get all the pings. :P
<mdeslaur> Laney: ok, thanks
<mdeslaur> infinity: could you please unblock the pyopenssl packages in saucy-proposed?
<infinity> mdeslaur: I can indeed.
<mdeslaur> infinity: thanks
<infinity> Laney: I can steal your block so I get the pings instead, if you prefer.  But yeah, a role account would do nicely.
<infinity> slangasek: Per our previous discussion on the topic, I'm going to drop the +omap4 images from the beta.  Not sure if I'll get to the archive surgery to actually remove all the bits too, since there's some fallout from dropping the kernel (ie: d-i needs it torn out, etc), but no point in testing an image we intend to drop in a week.
<slangasek> infinity: right. this should probably be announced on ubuntu-release at least, before making the change?
<infinity> slangasek: Announced before sounds like an invitation for discussion, but I agree that it should be announced period, sure.
 * infinity drafts.
<cjwatson> Laney: role account> good idea, Debian uses "freeze" IIRC
<infinity> slangasek: http://paste.ubuntu.com/6146813/
<infinity> slangasek: Taking your lack of response as consent and sending it.  *cough*
<slangasek> infinity: yeah, lgtm.  Did you confirm that kubuntu no longer wants it?
<slangasek> IIRC that was one of the outstanding points
<infinity> slangasek: I had a bit of a chat with Riddell, where the conclusion seemed to be "that's unfortunate, but if Canonical no longer wants to maintain the glue needed to make that go..."
<infinity> slangasek: It's *possible* Kubuntu could do an omap4 desktop based on the -generic kernel and omapfb, since they don't *need* 3D acceleration like Unity does, but the performance would be awful.
<infinity> slangasek: Nearly everyone I know, Canonical and Community, that uses Pandas, however, uses them to test builds, not to test GUI software, so a full desktop probably isn't that useful to 99% of 'em.  I do wish we had *some* default desktop target, but I suspect that's just not likely for 13.10.
<infinity> slangasek: For 14.04, we could perhaps do it on Beaglebone Blacks or something.
<slangasek> by 14.04, Intel tells me the minnowboard will make ARM obsolete
<slangasek> ;)
<infinity> *smirk*
<slangasek> of course, they also then proceeded to misspeak and refer to the minnowboard as the beagleboard in their own presentation, so there ya go
<infinity> All I want is one dev board with a proper open source driver that doesn't suck.  Is that too much to ask?
<apw> heh with the latest unity even some of the existing released h/w now sucks
<apw> (or mesa or something)
<tkamppeter> I have synced HPLIP from Debian this weekend (hplip 3.13.9-1) to pull in a security fix, and it is still hanging in -proposed. Can someone move it into the release?
<infinity> tkamppeter: Looks safe, I'll unblock it.
<tkamppeter> infinity, thanks.
<knome> is Janeks991____ seeking support in #u or so?
<knome> oh, sorry, wrong channel
<infinity> slangasek: Any issues with me unblocking the 1-char fix in https://launchpad.net/ubuntu/+source/finish-install/2.43ubuntu2 ?
<cjwatson> infinity: LGTM.  May be others ...
<infinity> cjwatson: That's enough of a +1 for me.
<cjwatson> Don't see anything else obvious on a brief look.  I guess we'll find out.
<infinity> cjwatson: It's a short-lived hack anyway, robher just pushed a kernel fix to LKML that will let us back this out for 14.04.
<cjwatson> k, cool
<infinity> cjwatson: As for other things to unblock, not seeing anything obvious.
<cjwatson> No, I meant other code to fix
<infinity> (Also, I think Laney's block script doesn't get d-i anyway)
<cjwatson> But don't see any
<cjwatson> I guess armhf/generic is fairly new so not too entrenched
<infinity> Yeah.  Also, I love that Debian picked a different name for that flavour. :/
<cjwatson> Joy
<infinity> I need to sit down and make the Debian armmp and Ubuntu generic things look as similar as I can manage in d-i.
<infinity> Sort of hoping for a future where we can tear out 99% of the subarch craziness from ARM.
<plars> beta is not looking too good at the moment
<plars> xnox: seeing lots of install related issues
<plars> xnox: seen anything recently with ubiquity where it just fails to come up at all?
<plars> "error opening config file '/root/.config/pango/pangorc': Permission denied
<plars> hmm
<Riddell> infinity, slangasek: yeah we seem to have come to the conclusion it's ok to end the omap4 images
<infinity> Riddell: I will try to put some time into making sure the omap4 d-i and server images still work for people who want to use Pandas as headless build test systems.
<infinity> Riddell: (with the -generic kernel, that is)
<Riddell> infinity: I just installed the daily last week and it works fine as far as I can tell
<Riddell> of server
<infinity> Riddell: Does that already use the -generic kernel, or is that ti-omap4?
<infinity> (I would have expected it to be omap4, but will be pleasantly surprised if someone already switched that over when I wasn't looking)
<Riddell> ...logging in...
<Riddell> jr@airm:~$ uname -a
<Riddell> Linux airm 3.5.0-232-omap4 #48-Ubuntu SMP PREEMPT Wed Aug 28 18:37:01 UTC 2013 armv7l armv7l armv7l GNU/Linux
<Riddell> linux-omap4                                     install
<infinity> Riddell: Right.  So, what I meant when I said "make sure server and d-i images work" was "make sure they work with the generic kernel, cause I'm dropping that omap4 kernel on the floor and kicking it in the teeth".
<Riddell> cruel but kind
<infinity> Does anyone have any other things they've spotted that need to be unblocked for beta?  If not, I'm going to do a full respin to pick up the bits we've trickled in over the day.
<slangasek> nothing from me
#ubuntu-release 2013-09-24
<jdstrand> infinity: could someone review the FFe in bug #1229449? it isn't needed for beta (it is only on touch), but I'd like to get the FFe handled so I can go through the landings process
<jdstrand> infinity: oh, I don't mean that someone to be you specifically
 * jdstrand forgot to backspace
<infinity> jdstrand: That someone can be me. :P
<jdstrand> if anyone wants to look at that ^, that would work for me
<infinity> Can I deny it due to poor grammar?
<infinity> "This bug is to fixes a deficiency..."
<infinity> jdstrand: If this only touches click-apparmor, I'd consider that covered by the general touch FFe anyway.
<infinity> jdstrand: But what is this friggin' madness with mucking around in /var/lib/dpkg/info?
<jdstrand> infinity: I'm not mucking around in it-- I am copying from it :)
<infinity> Tomayto, tomahto.
<infinity> The dpkg database should be treated as an opaque thing, not something you accidentally understand the internals of.
<JackYu> infinity: could you review the FFe request at bug #1227197? we hope it could be upgraded to the final beta:)
<jdstrand> infinity: basically, aa-clickhook -f adds more than a second to boot
<jdstrand> infinity: so we don't want to run it unless we have to
<jdstrand> infinity: so I wanted it to run only when it needed to. that is when system policy changes, whick I can detect if those files change
<infinity> jdstrand: Why not just drop a /var/lib/apparmor/click.upgraded semaphore, and check and delete that?
<jdstrand> infinity: that doesn't work because on a read-only image, that file would be created on the server
<jdstrand> infinity: but that directory is rw on the ro image
<infinity> Oh.  Right.  System image updates.
<jdstrand> its a fun problem with a creative solution :)
<infinity> jdstrand: Well, FFe granted for the feature, reservations registered about the vomitous implementation. :P
<infinity> (And I reserve the right to change the dpkg database format out from under you)
<jdstrand> infinity: I agree it is not ideal, but there were some interesting constraints
<infinity> jdstrand: I can't help thinking there must be a better way, but I'm also not in a mood to come up with one.  So, meh. :)
<jdstrand> I too will be thinking about it
<infinity> jdstrand: Wait, if this is only on system image updates, where isn't there some system image post-update.d that things can drop snippets into?
<infinity> jdstrand: Seems this might be a general problem looking for a general solution.
<infinity> jdstrand: (Much like Android rebuilds its bytecompile cache after major upgrades)
<infinity> jdstrand: Maybe this needs a talk with other interested parties like stgraber to sort out a general "we just updated" hook system.
<infinity> jdstrand: Dropped the above in the bug as well for posterity.
<infinity> Typos and all...
<jdstrand> infinity: right, there is a bug for that actually. but that requires a possibly larger FFe and he seems to be busy atm (I asked about it yesterday)
<jdstrand> infinity: rather, earlier today
<infinity> jdstrand: He's not at work today, AFAIK.
<jdstrand> (that's fine, but its been open for awhile-- I'm not criticizing, I'm just saying I need this in place). depending on what he does, I plan to hook into it in some manner, even if I keep this job (that would allow me to get rid of the dpkg stuff)
<infinity> jdstrand: Sure, the awful hack works for now, so long as you make note of its awful hackiness and help push something saner through later.
<infinity> (The latter bit being important, cause I do hate revisiting 3-year-old "temporary hacks")
<infinity> *cough*ddebs*cough*
<jdstrand> sure, I'm well aware of the hackiness. I plan to revisit policy load in generall after release
<jdstrand> (for apparmor as well as click-apparmor)
<jdstrand> infinity: in fact, I intentionally did not close the lxc-android-confing task for click-apparmor so I could revisit this going forward
 * infinity nods.
<jdstrand> infinity: thank you for the review btw :) have a nice evening
<infinity> jdstrand: I'll give it my best.  You too.
<jdstrand> heh
<JackYu> infinity, hi, are you free to review our FFe request:)?
<infinity> JackYu: Has anyone from kylin built this, and tested it locally to be sane and working?
<infinity> JackYu: Looks like a pretty major update, but it also only affects your image, so if you guys are happy with it, I'm alright letting it slide in.
<JackYu> infinity, yes, we tested it:)
<infinity> JackYu: Alright.  Well, upload away, and if it's in the archive in time for another respin, let's let it into your final beta images, otherwise it'll make it into final.
<infinity> JackYu: And close the FFe bug in the upload changelog, please.
<JackYu> infinity, thanks. happyaron will upload it. a
<infinity> happyaron: ^ see above.
<happyaron> infinity: ok
<JackYu> infinity, would you please unlock this package?
<JackYu> infinity, sorry, unblock:)
<infinity> JackYu: When it's uploaded and built, I'll unblock it for the next build of your image.
<JackYu> infinity, sure, thanks.
<happyaron> infinity: do I need to bump the release version, or reuse the version number that is already in -proposed?
<infinity> There isn't one in proposed...
<infinity> https://launchpad.net/ubuntu/+source/youker-assistant
<infinity> ^-- Only 0.1.6-0ubuntu1  there.
<happyaron> ah, I meant for ubuntukylin-default-settings, got online just now and was dealing that with JackYu last night...
<happyaron> yesterday I was told the package needs to be reworked and uploaded again.
<infinity> Oh, I know nothing of what's happening with ubuntukylin-default-settings...
<happyaron> so my question could be simplified to that, if a version in -proposed is not accepted by release team and I was asked to uploaded a new one, which version number should I use?
<infinity> happyaron: You'd need to bump the version, yes.  Once a package is accepted, the version is used up.
<happyaron> reused the old one already in -proposed, or increase it?
<infinity> happyaron: Only things we reject from a queue can be reused.
<happyaron> I see, thanks.
<happyaron> I was once heard from debian-devel list that a package will only be accepted when it build successfully on at least one arch in -propose, get a bit confused.
<infinity> Sounds like you were misled. :)
<happyaron> :)
<infinity> Even in Debian, that's not really true, except for the part where they do binary uploads, so one arch has always succeeded by the time they upload.
<happyaron> you mean arch:source?
<happyaron> for ubuntu
 * happyaron is still confused..
<infinity> happyaron: I meant for Debian.  For Ubuntu, all uploads are source-only, yes.
<infinity> happyaron: (You mentioned debian-devel...)
<happyaron> ok
<infinity> happyaron: Anyhow, there could also be confusion about "accepted" versus "propomoted".  Things can't make it from proposed to release without passing certain criteria.
<infinity> happyaron: But once it's ACCEPTED into the archive (and proposed counts), it's accepted, the version is used, can't be used again.
<happyaron> I see.
<happyaron> thanks for the explaination, :)
<cjwatson> FYI: all archive jobs on lillypilly disabled, switch to snakefruit in progress
<cjwatson> (rsyncing, don't actually try to use snakefruit yet)
<JackYu> cjwatson, we have just adjusted the ubuntukylin-default-settings according your comments. happyaron will upload it soon. Hope you will be happy with this version:)
<cjwatson> Hope so, thanks :)
<infinity> Oh, I wish I'd read that before I respun kylin for the other change I pushed through for them.
<infinity> Oh well.  Can spin again. :P
<infinity> I need to sleep first.
<happyaron> infinity: can you unblock youker-assistant first, if you are still on line...
<infinity> happyaron: It's already in saucy, that's what I'm rebuilding for.
<happyaron> ok
<happyaron> thanks
<infinity> https://launchpad.net/ubuntu/+source/youker-assistant/0.2.1-0ubuntu1/+publishinghistory
<JackYu> infinity, thanks. I think you should go to sleep:).
<ogra_> could some archive admin please let gst-plugins-bad1.0 1.1.4-2ubuntu2 out of binary NEW ? (we urgently need the -hybris package to move forward with phone multimedia)
<ogra_> seb is back \o/
<xnox> plars: are installer bugs linked on the iso tracker? can start looking through those for obvious things. Let me sync up images and reinstall my spare laptop.
<cjwatson> Archive jobs should be mostly back up and running now.
<JackYu> cjwatson, we uploaded the new version of ubuntukylin-default-settings, would you review and unblock it?
<lool> pushed my first unblock hint; hopefully I dont break anything
<ogra_> lool, if you didnt, could you try gstreamer1.0-hybris ?
<ogra_> (too)
<Laney> that isn't blocked
<lool> gtg
<cjwatson> lool: looks fine
<lool> will look at that when I'm back
<lool> Cool
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gst-plugins-bad1.0
<Laney> ogra_:
<lool> bbiab
<ogra_> Laney, well, its still in proposed, slangasek told me he would let it through NEW
<Laney> "still in proposed" isn't the same as "package is blocked"
<Laney> always check excuses
<ogra_> Valid Candidate ?
<cjwatson> why is upstart-app-launch blocked, anyway?
<ogra_> why does it say that if it isnt valid
<cjwatson> I don't think it's on images
<cjwatson> ogra_: that's only the first pass.  RTFM
<cjwatson> the M is linked from the top of the page
<ogra_> k
<Laney> Anyway, you're not supposed to have that Depends
<Laney> please to remove it
<ogra_> hmm, i thought ricardo did
<cjwatson> and indeed there's nothing gstreamer-related in NEW
<cjwatson> so this isn't archive admins getting in your way, it's wrong packaging
<ogra_> fixed then ...
<ogra_> sorry for the noise
<psivaa> cjwatson: infinity: (not so urgent for me but just in case it hasn't been noticed) we dont have i386 images for precise since the 20th in cdimage
<Laney> upstart-app-launch is because http://qa.ubuntuwire.org/ubuntu-seeded-packages/seeded.json.gz says it is on edubuntu
<cjwatson> psivaa: maybe I shouldn't have commented those out pending saucy beta
<Laney> although seeded-in-ubuntu doesn't don't know why that is
<cjwatson> psivaa: uncommented, they'll trickle back in as cron jobs fires
<cjwatson> *fire
<cjwatson> psivaa: (they also got bitten by the i386 livefs buildd being down, but that's fixed now)
<psivaa> cjwatson: ack, thanks
<Laney> tumbleweed: ^ seeded-in-ubuntu bug?
<Laney> I should have put some punctuation after "doesn't"
<tumbleweed> Laney: hrm, let's have a look
<lool> re
<tumbleweed> Laney: it's in the manifest
<tumbleweed> hrm, I never added ubuntu-touch
<Laney> tumbleweed: it is
<Laney> but s-i-u doesn't show it as on edubuntu
<Laney> Probably you need to strip off the :arch
<tumbleweed> sounds likely
<cjwatson> ogra_: You need to fix gstreamer1.0-plugins-bad-dbg too
<ogra_> bah crap ... blind me
<Laney> my beautiful gstreamer package
<smartboyhw> Please unblock ubuntustudio-lightdm-theme from saucy-proposed, Riddell didn't unblock it for us while he did the -default-settings unblock:(
<Laney> ok
<Laney> smartboyhw: done
<Laney> wait, Riddell did do it
<Laney> Unblock request by jriddell ignored due to version mismatch: 0.49
 * Laney fixes that instead
<Laney> smartboyhw: worth checking http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html always
<JackYu> cjwatson, do you have time to review the ubuntukylin-default-settings 1.0.8? we need someone unblock it and rebuild our beta 2 iso.
<smartboyhw> Laney, OK
<smartboyhw> Thanks:)
<smartboyhw> JackYu, <cjwatson> BTW, please move away from the model where you have a single preferred contact point - I'm not always around :P
<JackYu> smartboyhw, yes. But cjwatson gave some comments on this package, so I ask him to review for respecting him:)
<smartboyhw> JackYu, :)
<JackYu> Laney, Could you please unblock ubuntukylin-default-settings as well?
<psivaa> stgraber: ubuntu upgrade tests have not been added to the iso tracker yet for saucy beta. any idea if/when they will be added
<psivaa> ?
<tjaalton> join #ubuntu-hardened
<tjaalton> uh
<mdeslaur> yes, everyone should join! :)
<attente> hi, can i request an unblock of indicator-keyboard? this bug was recently fixed: https://bugs.launchpad.net/indicator-keyboard/+bug/1228489
<plars> xnox: yes, they are linked on the tracker
<doko> cjwatson, do you know why both emacs23 and emacs24 are seeded? can we drop emacs23?
<cjwatson> no idea, <-- vim user :-)
<Laney> doko: bzr blame shows you who added 24
<xnox> doko: i don't think we made 24 the default yet & havent rebuild/ported all the r-deps. So I don't think we can switch to 24 now. Something for t-cycle.
<plars> xnox: any ideas on some of those installer bugs?
<apw> should we have a saucy-updates milestone already?  it seems we are in the realm that we might want to be pushing things out to after released but i cannot as yet see the milestone
<stgraber> sounds reasonable, yes, let me create that one and cleanup the others a bit
<cjwatson> apw: added
<cjwatson> stgraber: beat you ;-)
<cjwatson> stgraber: (only to the addition, feel free to do cleanup ...)
<stgraber> cjwatson: haha, just got an error back from LP telling me someone beat me to it :)
<Laney> OOPS-TOO-SLOW-OLD-MAN
<apw> cjwatson, thanks
 * infinity notes that LP lied to him about who could create them.
<stgraber> alright, all old milestones are now marked as inactive (only keeping 13.09, 13.10 and saucy-updates), I'll also move the bugs of all old milestones to 13.09
<cjwatson> thanks
<infinity> Or I'm a moron and can't find how?
<infinity> "Milestones belong to a series and can be created from the series page by a project owner or series release manager."
<infinity> Pretty sure the latter half is a lie.
<stgraber> infinity: launchpad.net/ubuntu/saucy lists them and has an add milestone link there
<Laney> I can't see it
<infinity> stgraber: Yeah, only for TB.  Point made.
<stgraber> and all bugs have been moved
<lool> hinted telepathy-mission-control-5/1:5.14.1-1ubuntu6 for a bug fix that Jamie tested
<cyphermox> Laney: do I need to do anything special to block NM for now, given the beta freeze?
<Laney> it should be blocked already
<infinity> cyphermox: It should be blocked automagically.
<cyphermox> ack
<cyphermox> just making sure
<Laney> :wq
<Laney> NO
<infinity> lool: Can we avoid people outside ~ubuntu-release hinting things that affect all images while we're in the middle of a beta?
<cyphermox> you guys used a block-all hint, basically
<infinity> cyphermox: Much uglier than block-all. :P
<cyphermox> infinity: :)
<infinity> cyphermox: But anything seeded on any images should be blocked.
<Laney> Speaking of blocks, someone please check my last britney2 commit makes sense
<Laney> Setting up the role account
<lool> infinity: Sorry
<lool> I tried to revert the hint, but too late
<cjwatson> lool: seeded-in-ubuntu is your friend
<cjwatson> please use it
<infinity> Laney: Seems reasonable.
<Laney> infinity: k. pushing the hint now.
<lool> cjwatson: noted
<cjwatson> Laney: yep, looks right
<infinity> cjwatson: Speaking of reviews, I note you made no comment on my britney1 commit the other week.  Was it so hideous that you developed temporary amnesia, or were you just siding with me on the pragmatism > elegance front?
<cjwatson> the latter
<cjwatson> we can nuke it from orbit later
<chilicuil> buenos dias o/
<plars> infinity: do you know if anyone is looking into the ubiquity issues on desktop beta?
<plars> infinity: xnox mentioned them this morning, but haven't heard any news since
<infinity> plars: I know less than xnox on that front.  Bug number(s)?
<plars> infinity: there are lots, they are linked on http://iso.qa.ubuntu.com/qatracker/milestones/303/builds - note the abundance of black cockroaches under desktop
<infinity> plars: Lovely.  I thought we had people testing these things on some sort of cadence. :P
<infinity> plars: Okay, so some of these are probably eratta we can ship a beta with (though none of them look like something we'd want to ship final with).
<infinity> plars: But chasing down the ugly panels and maybe the partitioning issue would be nice.
<tkamppeter> jdstrand, the fixed CUPS package is in -proposed now.
<jdstrand> tkamppeter: nice, thanks! :)
<JackYu> hi, release team, please unblock the  ubuntukylin-default-setting package. We are waiting it to re-spin our iso:(.
<infinity> JackYu: Did this upload address all of cjwatson's concerns from yesterday?
<infinity> Certainly looks saner...
<cjwatson> Oh, that arrived while I was napping earlier.
<cjwatson> Yes, that definitely makes me less unhappy.  I'm not sure I ever got an answer to my question of whether you really intended to drop gnome-tweak-tool and chromium-browser, but I guess that's your problem.
#ubuntu-release 2013-09-25
<JackYu> infinity, yes:)
<JackYu> cjwatson, yes, we intend to drop these two packages:)
<cjwatson> JackYu: Unblocked ubuntukylin-default-settings/1.0.8.  Sorry for the delay.
<JackYu> thanks for your unblock:)
<infinity> I already unblocked it...
<infinity> I should have mentioned that with the "looks saner" comment.
<infinity> Well, now it's REALLY unblocked.
<cjwatson> Ah well
<JackYu> LOL, I'am going to rebuild now.
<cjwatson> I thought I'd grepped, but I didn't think to look at the top of your block of output.
<cjwatson> JackYu: Er
<cjwatson> Ah, never mind, the unblock has actually been processed
<cjwatson> (But be aware that they aren't instant)
<JackYu> I see, cjwatson. How long will it take effect?:)
<cjwatson> JackYu: 01:08 <cjwatson> Ah, never mind, the unblock has actually been processed
<cjwatson> JackYu: that is, yes, it's safe to rebuild.  Just for the future, you can't necessarily rebuild the moment somebody tells you it's unblocked - you need to wait for "rmadison <package name>" to show it in saucy rather than saucy-proposed
<cjwatson> But "rmadison ubuntukylin-default-settings" shows 1.0.8 in saucy, so that's fine
<JackYu> oh, got it. Good night, cjwatson and infinity:).
<sil2100> Hi everyone!
<sil2100> Anyone from the SRU team have a free cycle to take a look at https://bugs.launchpad.net/unity/+bug/1043627 ?
<xnox> infinity: plars: RE:panels -> so they got ported to the "new indicators" yet only network manager loads and none of the others (a11y, input methods, system indicator) and the panel gets the same height as the largest indicator menu. I did ask larsu to look into it, but I don't think he is.
<xnox> (he ported ubiquity to new indicators)
<xnox> one option is to not load the panel, but that in turn will regress (can't add/switch keyboards, and/or enable a11y, nor shut-down from within the installer)
<Laney> try re-prodding lars
<doko> xnox, had libvigraimpex already done last night
<xnox> doko: oh, ok. thanks.
<seb128> Laney, do you know why is ubuntu-system-settings blocked by freeze?
<Laney> seb128: it's on edubuntu
<Laney> Well, they were trying to fix that actually
<seb128> shrug, why
<Laney> let me see if it happened
<Laney> accident / bug
<seb128> ok, so can we override the block?
<Laney> looks like it did get fixed
<Laney> let me refresh the block
<ogra_> yeah, irt did
<ogra_> seb128, is it approved on the spreadsheet for landing ?
<seb128> ogra_, I've no idea
<seb128> ogra_, asac make it so it go uploaded to saucy-proposed yesterday, is that enough of an approval? or does it need a second one to do saucy-proposed->saucy?
<ogra_> seb128, well, all uploads and megres have to go there now and be pre-approved
<Laney> refreshed, block should drop off now
<ogra_> seb128, nah, we can drive proposed ourselves for touch ...
<ogra_> (it will go stuck there indeed due to the general freeze)
<Laney> not any more
<ogra_> ?
<seb128> ogra_, I'm just back from holidays and don't have  good grasp yet on that crazy new workflow
<ogra_> beta is out ?
<Laney> I just refreshed the block so u-s-s is not frozen
<ogra_> seb128, haha, expect surprises
<ogra_> Laney, ah, i thought the beta freeze was suddenly lifted :)
<seb128> Laney, thanks
<xnox> I'd like to request a beta block unfreeze for python3-pam binary packages (they are borked at the moment and the update fixes them), the python-pam binary packages however are seeded on all live images at the moment =/
<xnox> follow up will be pam integration in ubiquity merge proposal which depends on the above fixed python3-pam (still testing at the moment
<xnox> )
<Laney> Do I need FFe to add an installed tests package (and autopkgtest) to glib-networking?
<mdeslaur> is libvirt on any of the beta images? can it get released?
<cjwatson> mdeslaur: It's on server
<cjwatson> says seeded-in-ubuntu
<mdeslaur> oh! I didn't think server was having a beta, sorry
<cjwatson> I hope it's having final beta - desktop is
<mdeslaur> ah, thanks...I didn't know that
<cjwatson> grr, that last britney2 merge has britney segfaulting.  investigating ...
<Laney> ScottK: ^^^ maybe you could review glib-networking in Debian binary NEW so that I can sync
<cjwatson> britney fixed
<Laney> laney@iota> copy-package -d debian -s sid --to-ppa=ubuntu-desktop --to-ppa-name=gstreamer-1.1 gstreamer1.0                                 ~
<Laney> Copy candidates: gstreamer1.0 1.2.0-1 in sid
<Laney> Candidate copy target: https://api.launchpad.net/devel/~ubuntu-desktop/+archive/gstreamer-1.1
<Laney> Copy [y|N]? y
<Laney> No such distribution series: 'sid'.
<Laney> is that PEBCAK or something else?
<Laney> oh yes
<Laney> I need to specify the target series
<Laney> much better
<xnox> release-team: please review/unblock python-pam and ubiquity uploads. Both are needed to fix a few high installer bugs marked on the iso tracker.
<cjwatson> Laney: FYI Build-Depends: python:any is safe to upstream to Debian now (glib2.0)
<doko> would somebody open for a FFe for a new upstream graphviz version, building using lua5.2 and ruby1.9. then lua5.1 could be demoted, but there is too much to do to demote ruby1.8
 * xnox is confused about ADT ubiquity 2.15.20 failure on amd64 only.
<cjwatson> xnox: dependency install failed - my guess is that was transient since it's around the time glib2.0 was uploaded
<cjwatson> xnox: I've mashed retry
<Laney> cjwatson: oh really, that's good
<xnox> cjwatson: thanks, back to green now. And britney will notice updated test-result? =)
<cjwatson> xnox: hope so - I'll poke it if it doesn't
<cjwatson> OK, I've taught proposed-migration about upload ages
<cjwatson> So the oldest ones will now be sorted to the bottom of update_excuses.html
<cjwatson> (They're only sorted on day granularity - alphabetical within that)
<cjwatson> Should make it easier to deal with things that have been stuck without having to wade through things that are out-of-date because they were only just uploads
<smartboyhw> xnox, what will be the respin coverage of the new ubiquity?
<xnox> smartboyhw: i don't decide what to respin.
<Riddell> if we're respinning there's a few things I'd like in kubuntu, still testing one of them
<Riddell> smartboyhw: presumably anything that uses ubiquity
<smartboyhw> If I was to respin I will only respin for the ubiquity wallpaper...
<smartboyhw> * Ubuntu Studio wallpaper
<xnox> Laney: Riddell: ScottK: stgraber: please review & unblock python-pam, ubiquity for a respin to fix bugs as per ubiquity changelog.
<xnox> ADT passed, and the freeze block is the last thing blocking transition to release =)
 * Riddell unblocks kubuntu-meta and casper
 * Riddell unblocks python-pam and ubiquity
 * infinity looks sideways at queuebot.
<infinity> Did someone respin the world while Riddell was unblocking things?
<infinity> Or maybe queuebot's just being silly.
<smartboyhw> infinity, no, that's the EC2 images
<infinity> Riddell: Let me know when all the bits you care about have slipped in.
<infinity> smartboyhw: Ahh, fair enough.  So hard to divine what "25 changes" means if you weren't around to see the previous state (just woke up here).
<Riddell> infinity: will do, testing waway
<infinity> Riddell: Ahh, and you already unblocked ubiquity, thanks.
 * Riddell unblocks the fix he wanted unblock kde-workspace/4:4.11.1-0ubuntu4
<infinity> So, barring some incredible showstopper of doom, this'll probably be the last mass respin before beta.  If anyone has something they really thing needs fixing, now's the time to speak up.
<stgraber> Edubuntu appears to have some unity issues, highvoltage is looking into it, basically the dash never returns anything. But I'm not yet sure what will need fixing for that
<infinity> stgraber: Weird.  It should be the same on edubuntu and ubuntu, shouldn't it?
<stgraber> yep, it should be...
<stgraber> and I'm pretty sure that if that was happening to the Ubuntu images too, we'd have heard about it by now :)
<stgraber> hmm, so who's our unity point of contact these days?
<stgraber> the only unity process I see running besides compiz is unity-panel-service, I don't see any of the lenses/scopes/services running on that box, which explains why nothing's showing up in the dash but since I've no idea how those are supposed to get spawned, debugging isn't terribly easy
<xnox> hud should be running
<stgraber> xnox: yeah, the hud is running
<xnox> i have unity-scope-home, unity-files-daemon, unity-music-daemon running
<Laney> hmm, can't remember who the dash search guy is
<Laney> You're probably likely to get better support in #ubuntu-unity though
<xnox> stgraber: and /usr/bin/unity-scope-loader loads the rest.
<xnox> /usr/bin/unity-scope-loader applications/applications.scope applications/scopes.scope commands.scope applications/runningapps.scope
<stgraber> xnox: right, that's what I'm saying, I have those on my laptop but they're not running on Edubuntu and I have no clue why since they're installed
<infinity> stgraber: Is panel-service eating 100% CPU and preventing the world from happiness?
<stgraber> infinity: nope, the highest CPU user is compiz with 5% of the CPU (which is surprisingly low considering it's running using LLVMpipe in a VM)
<xnox> stgraber: i see gschemas for unity-scope-loader which control what's loading, but I don't see what launches unity-scope-loader on the desktop.
<stgraber> infinity: tracked it down to edubuntu-live conflicting with unity-scope-home (for some reason) and so breaking the dash
<infinity> stgraber: Oh, fun.
<stgraber> infinity: so I need to check why exactly we were doing that (my guess is that's realted to the old shopping lens), the good news is that's going to be an edubuntu-specific fix
<stgraber> highvoltage: ^
<infinity> stgraber: Oh, it's a hard conflict?  I was about to do debugging to find out what was kicking it out.
<infinity> stgraber: Ah-ha.  You conflict with unity-lens-shopping, but unity-scope-home now provides it.
<stgraber> infinity: right
<infinity> So, simple enough fix, assuming the current state of unity-scope-home doesn't upset you.
<stgraber> infinity: so I'll drop the conflict and set the gsettings key to turn on the privacy mode by default (disabling remote scopes)
<stgraber> that should be the functional equivalent of what we had in 13.04 with that conflict (but in a cleaner way)
<infinity> Kay.  I'll respin !edubuntu when I'm sure everything else is in, and leave your image to you to manually do whenever.
<stgraber> sounds good to me
<infinity> Actually, maybe I'll shower while I wait for the archive to settle, and then do the respins.
<doko> could somebody have a look at 1219889? Ijust promoted it, only seeing the MIR
<plars> infinity: is it just desktop getting respins, or are you expecting to respin server also?
<infinity> plars: Server too, some underlying packages changed that affected the world.
<stgraber> oh, actually looks like highvoltage already disabled all remote scopes in edubuntu-artwork a while back, so I just need to drop the conflict and we'll be good to go
<plars> infinity: ack, thanks for the heads up
<slangasek> doko: I don't understand what that FFe is asking for.  Is it just making it a dependency of the SDK?
<stgraber> infinity: if you haven't started the mass respin yet, you may want to wait a couple more minutes and include Edubuntu, edubuntu-live just got copied to the release pocket so it'll be there once the publisher is done
<infinity> stgraber: Ahh, cool.  I can wait, then.  Just de-showered.
<infinity> Riddell: Did all the things you wanted get in?
<Riddell> infinity: https://launchpad.net/ubuntu/+source/kde-workspace/4:4.11.1-0ubuntu4  still ongoing
<infinity> Ahh, still building.  Check.
<infinity> doko: Why did you promote ubuntu-html5-theme?  It's not seeded and nothing in main depends on it.
<infinity> smoser: You still haven't seeded (or depended on) ubuntu-cloudimage-keyring to keep it in main.  Were you planning to get to that?
<smoser> maas will have a dependency on it.
<infinity> When? :P
<smoser> rsn(tm)
<smoser> infinity, you want me to seed it in the interim?
<infinity> smoser: Nah, I just want the dependency uploaded so I can stop asking. ;)
<slangasek> right :)
<infinity> Dear queuebot, please stop spazzing.
<ogra_> its cant count to 26 ?
<infinity> No, it doesn't like to spam the channel.
<infinity> But I'm more curious about what any of those three mass changes were. :P
<ogra_> heh
<stgraber> infinity: my bet would be on a few mass status change for the cloud images (I see they're now all marked as ready)
<infinity> stgraber: I was betting on gremlins.
<plars> xnox: the screenreader situation improved slightly, it starts now but that's about it.  Only thing I can get it to read to me after starting up is the unity controls
<plars> infinity: desktop is still in pretty rough shape I think
<infinity> plars: I don't like the sounds of that.
<plars> infinity: the strange partitioning bug is still there, no oem-config on first reboot for an oem install, screen reader situation is slightly better but still nonfunctioning, and more
<plars> infinity: the oem-config regressed on this build, the automated tests show it working on the previous image, but not the latest respin
<infinity> plars: The partitioning thing can probably be release-noted (wiping out the partition table and rebooting works around it), but we need to look deeper.
<plars> infinity: yeah, for beta at least - it can also be worked around by selecting install only rather than live session
<infinity> plars: The oem-config breakage is a bit more unfortunate.
<infinity> xnox: You still around to given any insight into plars' oem-config bug?
<plars> actually psivaa saw it first - https://bugs.launchpad.net/ubuntu-cdimage/+bug/1231107 is the link
<plars> infinity: also the u1 stuff during install is still broken, probably release-note for beta on that too is ok
<psivaa> infinity: plars: the oem config bug could be due to ubiquity and oem being at skewed versions..
<psivaa> that was the reason when i had a similar issue a while ago according to cjwatson
<infinity> psivaa: Err, oh.  They are?  They really shouldn't be.
<infinity> Grr, they are.
<infinity> That's going to need a respin and a swift kick to nusakan to figure out why. :(
<psivaa> infinity: ack
<infinity> Bah, it's the old version on the server ISO too.
<infinity> nusakan, why do you hate me so?
 * infinity stops the bus and gets out to check on it.
<infinity> plars / psivaa: Okay, there will be a new set once nusakan's settled down and stopped building what it's currently working on.
<infinity> plars / psivaa: I'll manually refresh nusakan's mirror out of paranoia and then rebuild the world a bit harder. :/
<psivaa> infinity: ack )
<psivaa> :)
<plars> infinity: thanks for the heads up - seriously - it's really annoying when you go to enter results and see nothings there because there's a new build. Good to know when it's on the way :)
<infinity> plars: I'll spit out ubuntu desktop first, shouldn't take long.  Hopefully you guys can repeat some testing there.  If the oem-config thing was just the skew issue, most of the rest of our bugs can probably be release-noted for beta.
<infinity> (Though tons there to look at for final release... *sigh*)
<plars> infinity: ok, I need to go run an errand but will be back, and working on this later tonight also
<infinity> Alright.  Mirror SHOULD be sane.
<lool> hey
<lool> I've staged platform-api in proposed which whitelists music-app from getting stopped when in the background -- diff is https://launchpadlibrarian.net/151468112/platform-api_0.19%2B13.10.20130924-0ubuntu1_0.19%2B13.10.20130925.1-0ubuntu1.diff.gz and is in the android bits -- if there's a spot where we can land this, that would be awesome, but I guess the images are close to release now
<infinity> lool: Yeah, we'll probably drop the block late tonight or early tomorrow, depending on how quickly results of this last build come in.
<lool> infinity: ok; great
<lool> early tomorrow is perfect for us to roll the next touch image
<infinity> plars: Do you know anything about the ISO smoketesting automagic promotion bits?
<infinity> plars: Nevermind on the smoketesting thing, Colin educated me.
<jdstrand> hey, click-apparmor 0.1.10 is in proposed (pending publication). can someone hint this through? it is touch only
<cjwatson> Then it probably doesn't need manual attention
<cjwatson> click-apparmor isn't blocked
<jdstrand> ah, so beta freeze won't block it?
<jdstrand> ok
<cjwatson> Beta freeze only blocks packages on the images releasing with beta
 * jdstrand is still not totally clear on when things get blocked
<jdstrand> I see
 * jdstrand will try to remember that
#ubuntu-release 2013-09-26
<maclin> cjwatson, hi
<maclin> we find the bug(Bug #1226441) about ubuntukylin wallpaper, the problem is we change the default wallpaper name in default-settings from "ubuntukylin-default-settings.jpg" to "warty-final-ubuntukylin.jpg" according to name rules. But the ubiquity-dm use "ubuntukylin-default-settings.jpg".
<infinity> maclin: It's getting close to too late to fix that for the beta, can you live with that being broken and fixing it right after?
<maclin> infinity, ok, we will fix it and solve it after beta2, thanks:)
<infinity> plars: Stop finding bugs, we don't want any more.
<plars> infinity: it's a nasty addiction
<plars> infinity: you saw the rescue mode thing I take it?
<infinity> plars: Yeah.  Kinda weird.
<plars> infinity: yeah, I wasn't expecting to see a problem there
<infinity> plars: Neither was I.  Definitely one to look at, definitely too late for beta.
<infinity> plars: Did the oem-config fail go away with the respin at least?
<plars> infinity: well, yes, but hopefully at least this serves to raise some awareness that more needs to be done in the last few weeks we have
<infinity> plars: Lots needs to be done.  Including finding a lot more bugs, I imagine.  Such is release month.
<infinity> plars: And, historically, everyone seems to find 98% of the installer bugs in the last two weeks before release.
<plars> infinity: yes, but oem installs are still not quite right - see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166
<infinity> (Which is weird since, in theory, people claim to be installing through the whole cycle)
<plars> infinity: somehow, I doubt that
<plars> infinity: we do have automated tests for a lot of this stuff, and the oem one on the previous build was absolutely caught by it
<infinity> plars: Yeah, not calling out QA on this, more just the pain of upgradeitis as things get closer to the end of the cycle.
<plars> infinity: but a lot of these seem to rely on odd things being on the disk before hand, not on having a clean slate (as is normally the case in automation for making it consistent)
<infinity> plars: Lots more testers, lots more fuzz, lots more corner cases.
<infinity> plars: Your bugs though, I dunno.  Just bad timing? :P
<plars> infinity: more eyes, and more frequency would help for certain. At least it would hopefully distribute the pain a bit
<plars> rather than loading it all at milestone time
<bdrung> hi. should i try to get a freeze exception for a new upstream release of manpages?
<infinity> bdrung: Not right now, you shouldn't, but in 12h, sure. :P
<diwic> Hi, is pulseaudio 1:1.1-0ubuntu15.4 expected into precise-proposed soon? I uploaded it two months (!) ago.
<ogra_> slow DSL ?
<infinity> Har har.
<bdrung> infinity: i am working on my master thesis (using the kernel API) and will file the bug on monday after handing in the thesis.
<diwic> infinity, it would ease our OEM enablement if it was accepted...
<infinity> diwic: Yeah, the har har was for ogra.
<ogra_> :)
<diwic> if I didn't have to patch the OEM machines manually and they could just use the updated version in the repository
<diwic> infinity, okay :)
<diwic> infinity, thanks for accepting it \o/
<infinity> diwic: NP.  Went crosseyed a bit at the fact that the patches all refer to each other, but oh well.
<infinity> diwic: Looks sane enough when taken as a whole.
<infinity> diwic: When you're verifying, do me a favour and test on 3.2, 3.5, 3.8, and 3.11 (the saucy kernel debs should install on precise without any modification) to make sure it always does what you think it should.
<diwic> infinity, I'll try to do so; however, as usual I'm not the person with the hardware...
<infinity> diwic: Yeah, I realize you might not have the affected kit, though you should be able to test locally to make sure it doesn't do anything unexpected too. :)
<diwic> infinity, I took the patches from upstream as unchanged as I could, hence the third one changing the other two
<diwic> infinity, yeah, I could run a quick check on some hardware that should remain unaffected
<infinity> diwic: Yeah, nothing wrong with applying a patch stack.  I've done much more unreadable things in glibc SRUs.  It's just harder to review. :)
<infinity> diwic: (Which could be why people kept passing it over... We're all guilty of cherry-picking the "easy" queue items first)
<infinity> diwic: Anyhow, all accepted now, so yay.
<diwic> infinity, yeah, on to the next person to poke for testing. :-)
 * Laney eyes ogra_ 
<Laney> In gst-bad you edited control but not control.in
<ogra_> Laney, ugh
<ogra_> Laney, sorry, will fix
<Laney> no, don't
<Laney> I'm uploading 1.2.0
<ogra_> hmm, did anyone test the hybris stuff against it ?
<Laney> to a ppa
<Laney> never fear
<ogra_> k
<infinity> What the...
<infinity> https://bugs.launchpad.net/ubuntukylin/+bug/1230108
<infinity> ^-- Has anyone seen this before?
<ogra_> heh, lovely
<infinity> I can only assume that's a pretty specific driver/hardware combination doing that, but.  Special.
<ogra_> hah, i knew we had something similar before
<ogra_> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/496363
<ogra_> infinity, ^^
<infinity> ogra_: This one's Intel, mind you.
<ogra_> ah, k
<infinity> ogra_: My guess, without further info, is that it's a convertible laptop/tablet that thinks it's in tablet mode when it's not, or something along those lines.
<ogra_> hmm, yeah, wrong DPMS info or some such
<knome> infinity, any schedule for releasing?
<infinity> knome: No firm schedule, but it'll be today. ;)
<knome> infinity, mhm. also, any idea why the xubuntu images were respun?
<infinity> knome: The whole world was respun for a new ubiquity and some other bits.  Sorry about that. :/
<infinity> knome: A quick smoketest of each should be good enough to make sure I didn't blow up your world, I wouldn't bother going too in-depth with re-testing.
<knome> infinity, that's what i thought as well. thanks, i'll boot up a test and check if everything seems in place :)
<infinity> knome: Do you have a xubuntu-specific release announce link for me to link from the collective announce?
<infinity> (we really need a better way to collect these, this really doesn't scale with all the flavours we have...)
<knome> infinity, can guarantee it'll pop up at http://xubuntu.org/news/saucy-salamander-b2/
<knome> infinity, heh, yeah...
<knome> infinity, have you set the notes up in the wiki? :)
<infinity> knome: Working copy looks to be at https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes
<infinity> I'll fork that to something more Beta-appropriate when the time comes, so we can re-use it for final release.
<knome> aha
<knome> will you look at the flavor-specific wikipages too?
<infinity> Irritatingly, I only just noticed that was already there, as I'd been working on the stale TechnicalOverview last night. :P
<knome> awwh :<
<infinity> knome: We can link to the flavour-specific pages from there.
<knome> sure, but will you set those up or should i do that for us?
<infinity> knome: Feel free. :)
<knome> oki
<infinity> I should find some caffeine and re-read these notes to see how they differ from the bits I changed in the stale ones.
<infinity> And people wonder why I hate wikis. :P
<knome> good luck
<knome> infinity, umm, there is at least one problem with the new ubiquity in vbox... the wallpaper is not shown, it's just black background; until you wiggle the window around which then "erases" the black stuff and makes the wallpaper appear
<knome> infinity, ok, i couldn't reprouduce. weird.
<infinity> I tend to blame "it broke in virtualbox" bugs on virtualbox until proven otherwise...
<infinity> cjwatson: Any idea who's to blame for cdimage/www.old?
<cjwatson> infinity: Nope
<cjwatson> infinity: I assume it's a hardlink farm?
<infinity> cjwatson: Yep.
<infinity> cjwatson: I assume it's someone preserving a previous www.prev instead of deleting it.
 * infinity shrugs.
<Laney> Me, probably. Go ahead and kill it.
<infinity> Laney: Alrighty.
<knome> infinity, set up https://wiki.ubuntu.com/SaucySalamander/Beta2/Xubuntu
<infinity> Hah.  So, in random wiki searching, I found Beta11 (yes, eleven) release notes for Ubuntu GNOME.  Someone's planning ahead. :)
<apw> infinity, not me indeed, that is an odd one, ask RAOF perhaps
<apw> infinity, not me indeed, that is an odd one, ask RAOF perhaps
<apw> bah
<infinity> apw: I was going to ask RAOF yes, but he's not around.
<infinity> apw: I was going to ask RAOF yes, but he's not around.
<apw> ;)
<infinity> knome: Feel like being helpful to other flavours? :)
<psivaa> infinity: one of our post upgrade tests check if all the python modules can be imported in the default version.. and PAMmodule fails to import after saucy upgrade
<psivaa> is that serious
<psivaa> ?
<infinity> psivaa: That's a known bug, I believe, that is definitely an issue, but not a showstopper for Beta.
<infinity> psivaa: xnox and slangasek were talking about it last night.
<psivaa> infinity: ok, missed the back log.. quite a bit to catch up during the nights i guess :)
<xnox> psivaa: it should be "import PAM" not "import PAMmodule"
<xnox> psivaa: and I believe it's fixed in latest python-pam upload.
<psivaa> xnox: great thanks
<infinity> Oh, indeed.  Fixed 19h ago.  But then that should have worked in his tests, I'd assume.
<psivaa> infinity: xnox yea, i had a failure about an hour ago
<infinity> Did it get renamed?
<xnox> psivaa: not if in raring it tests "import PAMmodule" and tries the same in saucy, which is "import PAM". basically in python2 both PAM & PAMmodule used to work, with "PAM" being the correct one. In python3 neither worked, until new dh-python was used that auto-renamed the module.so to "PAM"
<xnox> infinity: it's weird, the module declared as "PAM" yet was getting installed as PAMmodule, which worked in python2 but never in python3 =/
<xnox> now it's declared and installed as PAM.
<infinity> xnox: Hrm.  But this could mean there's code out there (and maybe in the archive) that expects PAMmodule
<xnox> infinity: correct, let me do a quick search on codesearch.debian.net
<infinity> xnox: Is there any way to have it be correctly "PAM" in python3 (since it never worked there anyway, as you say), but still be both for python2, to not gratuitously break people's stuff?
<infinity> Also, I would pay good beer for an Ubuntu version of codesearch.
<xnox> infinity: Laney has one running in cannonistack, not sure if he made it public yet.
<Laney> seems to be down
<cjwatson> it's canonistack, down is the default state :P
<xnox> infinity: i did codesearch & did a src grep on all reverse dependencies, they all do "import PAM"
<infinity> xnox: Mmkay.  I wonder how psivaa's scripts autogenerated (at least, I ASSUME it was automagic) the other import.
<infinity> Based on filename or something, I guess?
<infinity> psivaa: Can you just quirk around that in your test setup to s/PAMmodule/PAM/ and carry on with life?
<psivaa> infinity: that's autogenerated but i'll try.. this is happening on a fresh install as well fwiw
<xnox> infinity: going by file names on disk is the only way one can find out about PAMmodule quirk name in the first place.
<infinity> xnox: Of course, random humans still could have done the wrong thing locally, but I suppose people expect that sort of minor breakage of code on dist upgrades.
 * xnox ponders if one can ask python about all modules
<infinity> psivaa: Sure, upgrade or fresh install, the point is that PAMmodule will not work (and never should have, but accidentally did).
<xnox> psivaa: dist-upgrade can remove packages, so surely you need to generate the list of packages to try import afresh after dist-upgrade, instead of assuming it will all work?!
<cjwatson> Oh, I no-change-uploaded fso-gsmd entirely unnecessarily.  Oops.
<infinity> xnox: python -c "help('modules')"
<infinity> xnox: Or "pydoc modules"
 * cjwatson sorts out the arch-specific NBS instead
<xnox> infinity: i get a hang and a bucket and a half of Emacs Lisp code out =/ http://paste.ubuntu.com/6158198/
<infinity> xnox: Your python is possessed.
<Laney> there we go, it is back up: http://162.213.35.4/search?weighted=1&q=import+PAM
<psivaa> xnox: infinity: this is what i get in a fresh saucy install http://paste.ubuntu.com/6158224/  (line 16-19)
<xnox> psivaa: hm, did i fix python3-pam by breaking python-pam ?!
<infinity> xnox: Probably. :P
<xnox> psivaa: have you opened a bug about it already? if not, please do.
 * infinity tests quickly here.
<infinity> (saucy-amd64)root@cthulhu:/home/adconrad# dpkg -l python\*pam | awk '/^i/ {print $2"_"$3}'
<infinity> python-pam_0.4.2-13ubuntu5
<infinity> python3-pam_0.4.2-13ubuntu5
<infinity> (saucy-amd64)root@cthulhu:/home/adconrad# python -c 'import PAM'
<infinity> Traceback (most recent call last):
<infinity>   File "<string>", line 1, in <module>
<infinity> ImportError: No module named PAM
<infinity> (saucy-amd64)root@cthulhu:/home/adconrad# python3 -c 'import PAM'
<xnox> infinity: use pastebinit ;-)
<infinity> (saucy-amd64)root@cthulhu:/home/adconrad#
<infinity> xnox: ^-- Definitely 2 broken, 3 fine.
<infinity> xnox: It was only barely over 5 lines, you'll live.
<infinity> Well, okay, 4 over.
<xnox> infinity: psivaa: fixed locally will upload.
<psivaa> xnox: thanks
<psivaa> xnox: i'll skip the bug then?
<xnox> psivaa: yes.
<psivaa> xnox: ack
<debfx> is an archive admin willing to review steam in NEW (bug #1229045)? It's already in Debian, the only diff would be adding an epoch to the version.
<xnox> psivaa: infinity: uploaded 0.4.2-13ubuntu6
<infinity> xnox: Danke.
<xnox> infinity: Bitte Schon ;-)
<infinity> debfx: I can review it against the Debian source, sure.
<infinity> debfx: Would be nicer if you reupload to Debian with the epoch and sync, though.
<smartboyhw> So, we still haven't got a page like https://wiki.ubuntu.com/SaucySalamander/Beta1 ?
<infinity> smartboyhw: We could do, if you like.  I was just going to link all the flavour notes from the main release notes.
<infinity> smartboyhw: But I can copy that page if people want to dump stuff in there.  Whatever. :P
<debfx> infinity: yep, I'll poke the maintainer
<smartboyhw> infinity, Ubuntu Studio's release notes are at /SaucySalamander/Beta2/UbuntuStudio
<smartboyhw> (I just copied it from Beta1)
<infinity> smartboyhw: Lovely.  That'll do, then.
<infinity> smartboyhw: If you're feeling helpful and wikiful, want to copy the other flavours' Beta1 pages to Beta2 as well, and if they don't get around to editing them, they'll just have stale info? :)
<infinity> smartboyhw: Looks like Edubuntu, Kubuntu, Lubuntu, UbuntuGNOME still need to do theirs.
<smartboyhw> infinity, OK, since I've got to zsync the i386 image and got nothing to do:P
<smartboyhw> Riddell, time to update the Kubuntu release notes though;)
<infinity> smartboyhw: Thanks.  You're a champion.  (Can you tell I hate wikis?)
<smartboyhw> infinity, yes I can tell:)
<smartboyhw> infinity, can you update the CommonInfrastructure page though?
<infinity> smartboyhw: There is no CI.  I moved that stuff to the Release Notes where it belongs.
<smartboyhw> infinity, ouch
<infinity> smartboyhw: We made that decision last cycle.  Someone resurrected it mistakenly this cycle. :P
<smartboyhw> That needs a full update everywhere...
<smartboyhw> infinity, how should I point to it then?
<smartboyhw> Ah, got it
<infinity> smartboyhw: Oh, were people using wiki includes to pull it in?  Ugly.
<smartboyhw> infinity, cry, now I don't know how to link:(
<infinity> It was just being used for the Known Problems section, right?
<smartboyhw> infinity, yes
<infinity> Meh, I can break that back out for now.  I don't want to break everyone's brains when I'm trying to release.
<infinity> smartboyhw: Better?
<smartboyhw> infinity, yes, very:)
<smartboyhw> infinity, I think I done all of them
<infinity> Oh, and someone copied the Beta1 page to Beta2 too...
<infinity> That was you as well.
<infinity> It's all pointing to the wrong locations, of course.
<infinity> I can fix that up, unless you're already in there.
<smartboyhw> infinity, already done:P
<smartboyhw> Do make sure you update the Ubuntu and Ubuntu Touch bits.
<smartboyhw> Cloud, Server also
 * infinity nods.
<infinity> Thanks a bunch.
<smartboyhw> infinity, :)
 * infinity raises his brow at #ubuntu-testing being invite-only.
<smartboyhw> infinity, #ubuntu-quality
<smartboyhw> The -testing channel is abandoned:)
<infinity> Yeah, I'm in -quality apparently, I just forgot about the rename. :P
<smartboyhw> infinity, LOL
<smartboyhw> infinity, asked phillw
<infinity> I thought he stepped down.
<infinity> Or does that not take effect until after release or something?
<smartboyhw> infinity, well, apparently gilir isn't here-.-
<infinity> Maybe I'll grab a quick nap for a few hours while I wait for more tests to roll in.
<pkern> An update to liblockfile is stuck in precise-proposed despite the bug being tagged verification-done-precise
<pkern> Bug is https://bugs.launchpad.net/ubuntu/+source/liblockfile/+bug/941968
<pkern> Could somebody release it properly, please?
<pkern> Hm, ok, the last update is not that great.
<pkern> Nevermind then.
<pkern> It does solve my immediate problem, though. |:
<cjwatson> pkern: That upload closes two bugs, only one of which is verified.
<cjwatson> bug 1011477
<cjwatson> And indeed bug 941968 is only really a qualified success
<cjwatson> adam_g: ^- could you please look at those?
<doko_> cjwatson, looking at python-werkzeug. do we really want to add two other memcaching servers into main, just for running the tests?
<cjwatson> I don't know, honestly I was just drive-bying to try to clean up the breakage Daviey introduced
<cjwatson> So instead of flask alone it's now flask + python-werkzeug that are stuck
<cjwatson> It does seem a bit excessive
<doko_> ok, the tests succeed without these, will drop these b-d's
<xnox> infinity: so my broken python-pam broke openstack-ci, can the 0.4.2-13ubuntu6 upload be unblocked into saucy please?
<didrocks> infinity: cjwatson: we start to have chroot issues on amd64, is that known?
<didrocks> https://launchpadlibrarian.net/151543330/buildlog_ubuntu-saucy-amd64.content-hub_0.0%2B13.10.20130926.1-0ubuntu1_CHROOTWAIT.txt.gz
<didrocks> before we had https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5051948/+files/buildlog_ubuntu-saucy-amd64.content-hub_0.0%2B13.10.20130926.1-0ubuntu1_CHROOTWAIT.txt.gz
 * didrocks retries again then
<didrocks> (same)
<roaksoax> howdy! Anyone know if there are any issues with the archive builders?
<Riddell> kubuntu is good to go :)
<didrocks> roaksoax: confirmed as well
<lool> roaksoax: reported minutes ago by didrocks
<roaksoax> :)
<roaksoax> awesome then!
<roaksoax> thank you guys!
<stgraber> infinity, slangasek: so we've got a bunch of pretty annoying bugs in Edubuntu that I believe I all fixed in the archive now, we'll still release the beta as it's (installation works, all bugs are related to the live session) and tomorrow's image will hopefully be perfect :)
<stgraber> just finishing a test install here and I'll mark both edubuntu images as ready
<cjwatson> didrocks: looking
<cjwatson> didrocks: FWIW, please give the +build link on launchpad.net rather than the log link on launchpadlibrarian.net when reporting this kind of thing
<cjwatson> it's strictly more useful
<didrocks> cjwatson: ok, sorry about it, it's fixed as per webops now
<lool> cjwatson: I guess it was https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5051948
<lool> unless that got a new build id now
<cjwatson> build IDs don't change on retry
<infinity> stgraber: Kay, shiny.
<infinity> xnox: The world will unblock soon enough.
<xnox> infinity: cool, thought so.
<infinity> cjwatson: You have the 403 sorted?
<cjwatson> infinity: Yeah, ChrisS sorted it on #webops before I noticed, and I've retried all affected builds.
<cjwatson> Via the crufty script I wrote on Tuesday morning to trawl through builder histories.  I should expose that properly on the webservice ...
<infinity> Heh.  I wonder how those firewall rules suddenly regressed.
<ogra_> NSA made a typo ?
<cjwatson> infinity: Freaks me out, but I'm going to ignore it unless it happens again, I think.
<stgraber> cjwatson: I believe what happened is that xnox asked IS to block direct access to snakefruit, which they did, that in turn broke image builds and package builds as both access stuff from archive-team.internal. Adding the local buildd subnet to the reverse proxy config solved that.
<xnox> sorry about that =/
<xnox> bad timing.
<infinity> Erm, it shouldn't be using the reverse proxy at all.
<Laney> It isn't
<Laney> It was the archive-team.internal config on snakefruit
<stgraber> infinity: bah, the end of my explenation was wrong, IS had to add a Allow from to snakefruit's apache config
<infinity> Ahh, okay, they 403d the world in Apache, not a firewall thing.  That makes more sense.
<stgraber> infinity: the change they did earlier was block any access to snakefruit's http server that doesn't come from lillypilly (through the rproxy)
<infinity> Was there actually a reason to do that?  Given that archive-team.internal's content is the same as what one can see via the rproxy anyway?
<xnox> hiding implementation detail, and have people.canonical.com/~ubuntu-archive as the canonical location as it was before.
<stgraber> not really, just xnox mentioned that snakefruit.canonical.com was accessible from the outside and cjwatson saying (may correct me) that this isn't the intended way for people to access it and that it may be worth asking IS to block direct access
<cjwatson> stgraber: Oh, sigh, OK
<cjwatson> Right, I certainly didn't mean to block archive-team.internal from inside the DC, that *totally* defeats the purpose
<cjwatson> Just snakefruit.canonical.com from outside
<infinity> Sure, it shouldn't be serving on the snakefruit hostname, only the other, which is obviously defeated by DNS when outside the DC.
<stgraber> cjwatson: right, IS apparently thought of that and allowed Canonical's /21 to connect, they just didn't think of the buildd subnet :)
<infinity> archive-team.internal used to have its very own IP for this reason.
<infinity> I guess that got lost in the move.
<cjwatson> infinity: Right, it did; I only noticed part-way through, but decided I wasn't that bothered since it was much more important when we were sharing with people
<infinity> Yeah.
<infinity> I'm not fussed, really.  This works.  Just differently.
<infinity> And since there were already firewall rules for the IP case, it would have been a cleaner cutover to just steal the IP.  But oh well.
<cjwatson> snakefruit's on a different network, so they couldn't just pull the old IP across.
<cjwatson> Apparently.
<infinity> Ahh.
<cjwatson> I did suggest that :-)
<infinity> darkxst: Is anyone going to mark the UbuntuGNOME images ready?
<infinity> gilir: Around?
<infinity> ogra_: Do you (or anyone, for that matter) still test lubuntu/ac100?
 * xnox doesn't
 * infinity doesn't still OWN an ac100, which makes it tough.
<ogra_> infinity, i promised a test for the final image (and potential fixes)
<ogra_> i wont be able to invest more time thought ...
<xnox> infinity: are we still building it? i thought we gave up on it. and on plumbers it was said that our linux-ac100 kernel is suboptimal and hallyn was looking into updating it's config in the archive.
<ogra_> i guess i should do that next week some time
<infinity> xnox: It's still being built, yeah.
<xnox> infinity: maybe we can trick hallyn into testing it =)
<ogra_> xnox, its a universe kernel maintainerd by a community guy
<infinity> Though, I won't release it with beta-2 if literally no one has tested it.
<infinity> (Which also implies no one uses it)
<ogra_> infinity, see #ac100 ... there are plenty of users
<ogra_> but they usually are actual users
<infinity> Looks like it didn't release with beta-1 either.  *shrug*
<ogra_> or arch hackers
<xnox> ogra_: oh, is there git tree on kernel.ubuntu.com or not even that?
<ogra_> infinity, right, as i said, final image or bust
<xnox> ogra_: is there one on github or some such?
<infinity> ogra_: I meant users of this specific image, not of Linux on the ac100.
<ogra_> xnox, ask marvin24 in #ac100, i think janimo pulled his stuff from github regulary in the past
<ogra_> infinity, yes
<infinity> gilir: Based on test results, I'm going to go ahead and mark everything but your ac100 image as ready.
<ogra_> infinity, me too
<ogra_> infinity, the ones testing it see issues
<ogra_> infinity, the ones who would be able to fix them prefer to hack arch
* infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: open | Saucy Salamander 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
* infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: open, FF | Saucy Salamander 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
<knome> beta 1?
<knome> you mean final beta/beta 2 for flavors which participated in beta 1
<infinity> knome: I just changed the archive state.
<infinity> knome: topicdiff is your friend. :)
<knome> oh, okay.
<knome> is not ;)
<infinity> 11:22 -!- Irssi: Topic: -: Archive: beta freeze
<infinity> 11:22 -!- Irssi: Topic: +: Archive: open
<infinity> ^-- It's my friend! :)
<infinity> darkxst: Based on test results, I'm going to mark UbuntuGNOME's images ready too, and start turning cranks.
<infinity> Aww crap, and need to build source.  Why does that always seem to not be on the checklist?
<infinity> ... and also not commented out in crontab.
<infinity> cjwatson: What's the current correct invocation to build source ISOs?  I don't think I've done it since the python rewrite.
 * infinity is guessing something like "for-project ubuntu cron.source" would do it.  Or maybe just cron.source on its own.
<cjwatson> just cron.source
<cjwatson> infinity: just for the record, the agreement last Thursday was not to lift the migration block after beta release, but to selectively unblock things
<infinity> Mmkay.
<infinity> cjwatson: Err, really?
<cjwatson> just because that would be bad if we found out we disagreed later :)
<cjwatson> 13:10 <ScottK> cjwatson: With no unblock of migration after the beta is out, I would hope.
<cjwatson> 13:10 <cjwatson> ScottK: I think that's what we did last cycle, isn't it?
<cjwatson> 13:10 <ScottK> Yes.
<infinity> cjwatson: I missed that memo.
<cjwatson> 13:11 <ScottK> cjwatson: It's one of those things we end up doing every cycle, but it seems like it's never part of the "standard" way things are going so we end up relitigating it twice a year.
<cjwatson> 13:12 <cjwatson> ScottK: it's in the process now; hopefully that will stick a bit better
<infinity> What we did last cycle was a freeze after beta...
<cjwatson> that sounds like the same thing as ScottK said.  what do you mean, if it's different?
<infinity> Selective unblocks are actually much more irksome from the AA/release standpoint, TBH.
<cjwatson> you mean as in saucy.status = FROZEN?
<infinity> cjwatson: I mean what we did last cycle was an archive freeze.
<infinity> Which comes with its own problem of copies being opaque and the autolander being a pain because of it.
<infinity> But I don't see the point in selective unblocks.
<cjwatson> maybe we should take the opportunity to make unblocks less effort (diff-selection tool etc.)
<infinity> Anything uploaded should be destined for the release pocket right now.  This isn't Debian, -proposed isn't unstable.
<cjwatson> but I'm not hugely bothered as long as we don't open the floodgates again
<infinity> Stopping stupid uploads before they land in the archive is good.
<infinity> Stopping them after they're in the archive is less useful late in the cycle, IMO.
<cjwatson> you seem to have unblocked everything now though
<cjwatson> did I speak up too late?
<infinity> Anyhow, I could set it to frozen or restore the block or do nothing (the third option was what I got from slangasek when we discussed this, and a hard freeze for final).
<infinity> cjwatson: I unblocked when the topic changed.  So, yeah, might have been too late.
<infinity> cjwatson: But setting the archive frozen wouldn't change that, since proposed was already proposed...
<cjwatson> mkay
<infinity> I guess I just don't get the argument that we want things in proposed and then no, actually, we don't.
<lool> you could perhaps stop the publisher run still?
<cjwatson> well, fine, I don't think it's actually cause for panic
<cjwatson> as long as we do actually progressively lock down from here on in
<infinity> Well, what would people like to see happening?  I actually appreciate the archive freeze from beta->final in past cycles.  I'm sure others would disagree.
<cjwatson> I do as well
<infinity> But I think the britney block is too late in the assembly line to actually stop damage, since a bad upload to proposed can still require a painful revert.
<cjwatson> although I think migration freezes are very useful in that they let things build and be tested before we make a decision on them
<infinity> So, I'd prefer it be at the queue stage.
<cjwatson> I'm happy to go for the queue stage, and if some things need to be migration-blocked too (e.g. by touch) then that's fine
<infinity> Most of the decisions being made here should be of the higher level "no, don't push a transition in 2 weeks before release", not a fine-grained "this introduced a bug I don't like, fix it before I let it slip in", surely?
<infinity> Except for whatever touch wants to do, fine. :P
<infinity> If touch wants to block all their stuff wholesale, that could be a hackish solution to the autlander transparency problem.
<infinity> As I can accept those opaque uploads with a bit more confidence.
<cjwatson> well, that's what I've been agitating for ...
<infinity> Alright, let me freeze the archive for now, and we can carry on this discussion after I've injected drugged beverages.
<Laney> Didn't we make queuediff work for those?
* infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: frozen | Saucy Salamander 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
<stgraber> FWIW, I'm in favor of a standard archive freeze instead of a huge britney block
<infinity> One of my least favourite "features" of copies is how the binaries completely bypass NEW.
<infinity> Anyhow.  All frozen now.  Need to find something to drink.
<infinity> stgraber: You built source ISOs recently.  How many months does it take?
<stgraber> infinity: just a couple ;) IIRC it took around 45min last time
<infinity> Kay.  I'll find a large beverage. :P
<slangasek> so are we releasing touch images with the beta?  they don't seem to be marked on http://iso.qa.ubuntu.com/qatracker/milestones/303/builds
<slangasek> hmm, and why is this milestone called "Beta 2"?  It's supposed to be called "Final Beta"... I'd change it but I fear breaking the publishing scripts
<ogra_> slangasek, nope
<stgraber> that one is mine, would be nice if someone could review, it's breaking LTSP ^
<slangasek> ogra_: "nope"?
<slangasek> ogra_: --verbose?
<infinity> slangasek: I think we did it as beta-2 in 13.04 too, for fear of breaking many fragile parts.  But I could be wrong.
<ogra_> slangasek, no beta for touch ... it is far from feature complete
<slangasek> ogra_: ok; who made that call?
<ogra_> slangasek, i belive asac thinks the new hyper controlled way of landing code keeps sus safe here
<ogra_> so that we can land stuff til near the end
<ogra_> slangasek, i dont think anyone even considered doing a beta
<ogra_> so nobody made a call to not do one
<slangasek> ogra_: that's not true, I certainly discussed it with folks
<ogra_> well, didnt come through to my level from anywhere higher
<slangasek> infinity: yeah, I think the filenames were 'beta2' everywhere... just making sure it doesn't leak into public-facing announcements anywhere that way
<slangasek> ogra_: it's standing policy that to be included in a release, an Ubuntu flavor must participate in the final beta; I'll talk to asac
<ogra_> yeah
<stgraber> slangasek: how would a touch beta work anyway? Would that be a blessed "old flipped" image being published as beta?
<ogra_> since we usually dont regress in the images i think any of the recent builds should be good if you want oen for beta
<stgraber> ^ thanks
<slangasek> stgraber: why would it be "old flipped"?
<ogra_> stgraber, it would go in the saucy-beta channel :)
<stgraber> slangasek: because we don't have milestones on system-image?
<ogra_> stgraber, have fun implementing that ;)
<stgraber> ogra_: oh, it's easy to create a channel and copy a single image to it, it'd just be pretty useless as people usually want to get updates ;)
<slangasek> stgraber: doesn't the initial install come from cdimage?
<ogra_> slangasek, nope
<slangasek> ok
<ogra_> cdimage is only for ports nowadays
<slangasek> well, I don't see why that should be the case
<stgraber> slangasek: system-image monitors daily-proposed for any new image, anything that shows up there for the right series gets imported into the matching -proposed channel
<stgraber> slangasek: then once that's tested, the image gets copied between channels
<slangasek> stgraber: sure, but what does that have to do with where phablet-tools pulls the initial image from?
<stgraber> slangasek: phablet-tools pulls the latest full image from system-image (defaults to the stable channel)
<stgraber> slangasek: phablet-tools in system image mode never accesses cdimage.u.c
<slangasek> ok; I don't see why that should be the case
<ogra_> slangasek, theoretically we would hide the cdimage images as an interim product
<slangasek> I would expect the base images to still be distributed from cdimage
<stgraber> slangasek: why?
<ogra_> the fact that ports need to use them makes us keep them public though
<slangasek> because that's where we distribute images from
<ogra_> but thats not the image setup we support
<slangasek> I expected system-image.u.c to be used for the updates only
<ogra_> all app code and image tests are only against system-image images
<infinity> Sort of makes sense for it to all be in one place with the same channel thing, IMO.
<ogra_> we even ask developers to use it in writable mode
<stgraber> slangasek: well, the problem is that system-image uses repacked versions of what we have on cdimage, so if we wanted that, we'd need to either push the repacked files to cdimage only for the initial flash or we'd need to duplicate the repacking code in the client
<ogra_> to not be hit by bugs the underlying hacked together filesystem  setup could cause
<stgraber> slangasek: (we can't simply switch cdimage to publish .tar.xz directly as the ports still need the old .tar.gz, .zip and .img)
<slangasek> stgraber: but system-image is syncing from nusakan anyway, so I don't see why we aren't publishing the .tar.xz from cdimage
<ogra_> well, they actually only need the armhf.zip file
<slangasek> alongside the .tar.gz/.zip/.img
<ogra_> slangasek, that would need a bunch of code changes i suppose
<infinity> slangasek: Speaking of leaking B2 in announces: https://lists.ubuntu.com/archives/ubuntu-announce/2013-April/000170.html
<ogra_> in the updater app etc
 * infinity will not do that in his. :P
<slangasek> infinity: thanks ;)
<gilir> infinity, thanks, I was going to do the same anyway :-)
<slangasek> ogra_: of course it wouldn't
<ogra_> you mean it would just know it needs to pull from cdimage instead of system image ?
<stgraber> slangasek: we could do that, but I really don't see what would be the benefit of this, besides attending a dependency on cdimage to the system-image code (which I'm trying to avoid as we need private servers and extra servers for carriers and ports) and the end result would be just extra cdimage disk use for files we can retrieve from system-image
<slangasek> but ok, if the point is that the full .tar.xz needs to be published from system-image.u.c *anyway* to handle the case where we need to do a full-tarball update, then yeah, it makes sense to not publish at all to cdimage
<slangasek> stgraber: right, I think we're on the same page then - sorry for not understanding
<stgraber> slangasek: right, I'm not publishing anything extra just for phablet-flash, I've got the full tarballs on system-image.u.c anyway :)
<slangasek> so I think that implies that there's no milestone directory etc. that we need to push for Touch on the supported devices
<slangasek> however, that doesn't mean we shouldn't declare Touch to be "at beta"
<ogra_> yeah, given we do an actual milestone every day since weeks ...
<stgraber> slangasek: agreed, we could bless a set of version numbers (one per device) as being beta
<slangasek> stgraber: I don't think we even need to do that
<slangasek> it's the stable channel, it's supposed to be guaranteed good every day, and if it's good enough for a beta, we just say "here's the beta"
<ogra_> stgraber, i think he just means an announcement
<infinity> slangasek: Hrm.  Can you look over the upstart bits in TechnicalOverview and ReleaseNotes and consolidate them.  Things seem to have gone out of sync there.  I suspect the version in TO is what we want, but RN is ahead of the curve for everything else.
<stgraber> slangasek: wfm
<slangasek> infinity: nuke the TechnicalOverview page from orbit
<infinity> slangasek: Gladly, but I figured you might care about preserving those bits first (or maybe you don't, and they were from last release, I'm not sure).
<slangasek> infinity: and why is https://wiki.ubuntu.com/SaucySalamander/TechnicalOverview redirecting me to ../ReleaseNotes?
<stgraber> ogra_: btw, I've been talking with the guys working on the customizations for touch and they'll be the first to run a private system-image server which imports stuff from the public one. Once we've got that figured out and working, the exact same setup will work for ports.
<ogra_> |o?
<ogra_> err
<ogra_> \o/
<infinity> slangasek: It's.. Not for me.
<slangasek> infinity: but no, the stuff on the TO page is WAY too verbose and I didn't even attempt to carry any of it over
<ogra_> stuck shift
 * ogra_ hugs stgraber 
<stgraber> ogra_: basically ports will be able to run the code on their own server, the ubuntu rootfs will auto-import from cdimage, the gpg keys will be swapped with theirs and their device tarball will be generated from their own code.
<slangasek> infinity: ok, it's better now - wonder what that was about
<ogra_> yeah, sounds good
<stgraber> ogra_: I guess we'll just need to grow a --server parameter in phablet-flash to support that and we'll be good
<asac> whats going on?
<ogra_> right
<asac> slangasek: ? :)
<ogra_> asac, touch beta release announcement
<lool> heya
<lool> so IIUC, archive is frozen for now, which means all uploads have to be reviewed by release team, but you guys are considering using hints instead and selectively approving package uploads this way?
<stgraber> lool: no
<lool> stgraber: no to which part?  :-)
<stgraber> lool: there was a discussion earlier and the result was that britney is too late in the pipeline (package already got built) for us to really control what goes in, so we're going with a standard full archive freeze with everything being reviewed by the release team
<lool> so you've really excluded the hints entirely then, sounds bad
<lool> then I'd love getting the two packages above (unity-scope-click/0.1+13.10.20130926.2-0ubuntu1 and ubuntu-download-manager/0.2+13.10.20130926.2-0ubuntu1) approved!  trying to get them in a touch image
<infinity> lool: If certain people (ie: touch) want to put blocks in place, then can.  For most uploads, blocking twice is likely just a waste of time.
<stgraber> damn, I hate syncs...
<lool> infinity: so should I go setup a bunch of blocks for sources only in Touch?
<asac> will this mode go away after the beta is out?
<stgraber> asac: no, we'll remain frozen till release
<infinity> lool: If you want that, yes.  I'm not sure that you do, but that's up to you guys.
<stgraber> infinity: can't remember, do we now have a magic way of getting a debdiff for a sync?
<lool> infinity: ah but that wouldn't change anything about the frozen state
<lool> infinity: we'd still have to ping you folks for every single upload?
<asac> lool: why do we need to add blocks? thought our first problem would be how to get stuff in (and not how to keep it out)?
<infinity> lool: We tend to be fairly responsive but if something's hung up, yes.
<infinity> I'm fine with handwaving anything that's not in a package set until we get near final release.
<infinity> stgraber: Not that I know of.  I believe it involves stabbing yourself in the face repeatedly and cursing the autolander.
<stgraber> infinity: yeah... I just went to the PPA, grabbed the stuff from there and diffed with the archive but that's a real waste of time... I may get bored of that rather soon and hack something together...
<stgraber> lool: anyway, both approved
<lool> stgraber: thanks
<infinity> stgraber: The queue knows the origin, queudiff could be tought to perform that same waste of bandwidth.
<stgraber> infinity: yeah, that's what I meant by "hack something together" :)
<slangasek> infinity: hi.  archive freeze?
<slangasek> as I said last week, I don't think we should be freezing the archive.  I feel very strongly that we should be using britney instead
<ogra_> ++
<slangasek> a) the release team should not have to be micromanaging uploads, b) we really don't want to be on the critical path for touch work
<seb128> can we get
<ogra_> yeah, it would be one slowdown more in an already awfully slow process
<seb128> c) uploads shouldn't have to go through some stupid weird google document workflow
<stgraber> seb128: c) isn't the release-team's fault ;)
<stgraber> slangasek: I think infinity's plan is to treat ubuntu-touch as unseeded and let them through directly until final freeze like we've been doing in the past for any unseeded package
<infinity> slangasek: See scrollback.  Some people think we should have a full britney block, some an archive freeze.  If the choice is between those two things, a freeze is more sane.
<slangasek> I don't agree
<slangasek> as stated last time we discussed this
<infinity> slangasek: If we *only* want to block touch, that's different.
<mdeslaur> release team: can I upload a fix for LP: #1226509?
<slangasek> we want to block all seeded things, not just touch
<infinity> slangasek: Okay, and if we seed all things, I disagree with you wholeheartedly.  A britney block is the wrong place to stop broken uploads.
<stgraber> mdeslaur: looking
<infinity> slangasek: Once someone inadvertently starts a transition or introduces a massive changeset, reverting is much more annoying than just rejecting.
<slangasek> infinity: what is the purpose of the freeze?
<slangasek> philosophically speaking
<stgraber> mdeslaur: looks like a bugfix to me, so sure, go ahead
<mdeslaur> stgraber: thanks
<slangasek> I would say it's to be a safety net to prevent accidental regressions as a result of devs not coordinating appropriately prior to upload
<infinity> slangasek: I could turn that around and say "what's the purpose of blocking all seeded things?"
<slangasek> infinity: the exact same thing
<infinity> slangasek: Okay, but people not coordinating prior to upload doesn't get fixed by letting them upload.
<slangasek> except one requires active management by the release team at time of upload for every package, and one can let us delegate part of that work
<slangasek> for proposed-migration
<slangasek> also
<slangasek> who was saying we want a full-archive block?
<slangasek> that might be the easiest to implement, but it's not consistent with our historic post-beta freeze policy
<slangasek> what we want is "unseeded gets waved through, seeded gets a closer look"
<stgraber> really? I'm pretty sure we stayed frozen post-beta for the past 2-3 cycles
<slangasek> stgraber: as a matter of mechanism, not of policy
<stgraber> and yes, ~ubuntu-release is assumed to just click accept on any unseeded package
<infinity> stgraber: Yeah, but spiritually, he's right, in that we just let unseeded through.  Ish.
<slangasek> the *policy* is "unseeded is officially unfrozen, but we can't selectively freeze the archive so we have to poke them manually"
<infinity> (Though, I did still check for obvious "dude, you're doing a library transition 3 days before release, really?" things)
<slangasek> infinity, stgraber: did we rule out a britney block for all-seeded on practical grounds?
<infinity> slangasek: I don't have massively strong opinions on it, but I actually find blocks more annoying to manage, not less, and it's indisputable that they don't offer the same level of protection against flat out stupid and FFe-breaking uploads.
<infinity> Because you can't un-upload something once it's in the archive.
<slangasek> but you can certainly rm it from proposed
<slangasek> which is all the same to me
<stgraber> slangasek: yeah, I think the biggest issues with britney are: no notification, no tooling to grab diffs, painful to push new unblocks and pretty hard to revert things in case something's actually broken in the upload (as things will already have built against it in proposed)
<infinity> slangasek: Still forces version constraints, could need rdep rollbacks, etc.
<slangasek> infinity: whereas the other way we have to have somebody on the release team always on call to avoid holding up touch development
<infinity> slangasek: Someone uploads libfoo_2.0 over libfoo_1.0, you want to put your foot down, you now have an epoch.  HAND.
<slangasek> and while we could send queuebot notices to your phone, I don't think that's actually what we want ;)
<stgraber> so doing a full freeze, dropping the blocks and having us wave through unseeded+touch seemed much easier, then the touch guys can use britney as they usually do, the only extra overhead is on ~ubuntu-release to check the packageset field and click accept
<slangasek> infinity: I think that's the tail wagging the dog
<slangasek> we can certainly deal with such cases without epochs if we care about that (the ugly upstream+really-oldupstream mocking trick)
<slangasek> that's assuming it happens at all
<infinity> slangasek: I think every time someone says "oh, we can just delete what we don't like from proposed", they're missing fundamental concepts of how this all works.
<slangasek> I think I know how -proposed works
<infinity> slangasek: Sure, you don't need an epoch, that was just an illustration.
<infinity> slangasek: I think you do too, so I'm a bit confused by the statement. ;)
<infinity> The only way forward once something is in the archive is forward.  Always.
<slangasek> yep
<infinity> This isn't a big deal when forward is just some bug fixes.
<slangasek> and the cases where we actually need to back things out is *so rare* that putting a full archive freeze in place to prevent it is tail-dog-wag
<infinity> It's irksome when forward is rolling back a complex accidental transition (yes, this happens, yes, I've rejected last-month uploads for this, it's not a strawman to prove a point).
<lool> can we automate accepting packages without a packageset?
<slangasek> yes, I understand it's not hypothetical - but it's still sufficiently rare that I don't believe it's a better use of the release team's time to have to hand-approve every package in the queue
<infinity> We have pretty good timezone coverage, is it really so onerous to just have an AA/RM wave through non-packageset stuff?
<seb128> infinity, I don't know about this cycle, but every other cycle we had annoy delays at times with that
<stgraber> lool: I tend to not trust the absence of a packageset as a green flag instead relying on seeded-in-ubuntu instead, but yes, we could automate something to look at the queue for packages without packageset set, then check using seeded-in-ubuntu and if that's clean, let it through
<stgraber> lool: most of us already deal with the queue using the API, not the webUI
<infinity> seb128: You were almost always uploading seeded stuff in previous releases.  And yes, we were reviewing those.
<infinity> There's a third option here.
<infinity> cu2d runs as a bot with AA permissions.  If it has a concept of "safe to slam in" and "not so much" sets, it can do its copies with --auto-approve.
<infinity> And entirely bypass the queue for touch.
<stgraber> it'd have to be clever enough to know if something's seeded or not
<stgraber> I certainly don't want unity, indicators, ... any of those cu2d packages to bypass the queue
<infinity> stgraber: No more clever than whatever hackish script generates the massive block (and then gets out of date as people swap deps around in a last minute rush to upset people who like feature freezes).
<stgraber> infinity: sure, that's why I'm in favor of the archive freeze and not the massive block too, I try to be consistent in my opinions ;)
<slangasek> infinity: yes, it is onerous, and it slows down the development of Touch.
<stgraber> infinity: and why I suggested that I'd be fine with us scripting auto-accepts if the source isn't in any packageset and that the binaries aren't seeded anywhere (using seeded-in-ubuntu) as those are the two checks I do before letting an unseeded package through
<slangasek> infinity: would you be happy with scripted auto-accepts, like stgraber suggests?
<slangasek> and would we be able to do such scripting for packages in touch?
<stgraber> slangasek: sure, I believe touch should be unseeded and only be on the ubuntu-touch image, so should be easy enough to check (that's how I reviewed the list of standing FFes for touch the other day)
 * slangasek nods
<infinity> I'd be alright with that.
<infinity> It's basically the same as my cu2d suggestion, but with checks at a different spot.
<infinity> And a spot stgraber trusts more, so I'm fine with that.
<slangasek> ok, seems like that's a way forward then
<slangasek> should it be part of cu2d for the touch packages?
<slangasek> (the --auto-approve)
<stgraber> I'd really prefer it doesn't, too much potential for troubles and not something owned by the release-team or a release team member
<slangasek> ok
<slangasek> stgraber: would you have time today to put something together to drive the auto-accepts for touch-only + unseeded?
<stgraber> slangasek: yep, should be easy with a bit of copy/paste from queuebot. I'll let people know once I've got something so they can stop accepting things in the queue (need something to test against ;))
<slangasek> stgraber: ok, thanks :)
<infinity> stgraber: To be fair, while note technically owned by release, cu2d is effectively owned by archive admin.  But I'm happy enough with your proposed solution.
<infinity> s/note/not/
<infinity> Anyhow, I'm going to go back to crossing my eyes at trying to verify this beta release mirror layout.
<infinity> And lunch, while mirrors settle.
<infinity> Or breakfast.  Or whatever this is.
<infinity> zul: Is there an FFe for this python-ceilometerclient?
<zul> infinity:  its just bug fixes i believe
<infinity> zul: Commit 3499631b1a32b2125bd89de2e7ce45d9dd19a7c4 is definitely more than a bugfix.
<infinity> And a couple others.
<stgraber> slangasek, infinity: I've got a script now, please keep stuff in the queue so I can test it :)
<infinity> stgraber: You say, after I accept a bunch of stuff...
<stgraber> (currently been testing against precise-proposed but that's not ideal since seded-in-ubuntu doesn't work against older series)
<infinity> stgraber: libunity-webapps is still there (was about to review it), but that's an "is seeded" test, at least.
<infinity> stgraber: Sadly, I accepted all the seeded stuff before you asked. :P
<slangasek> stgraber: great!
<stgraber> stgraber@castiana:~$ ./auto-accept
<stgraber> Skipping 'libunity-webapps' because it's in the following packagesets: ubuntu-desktop
<stgraber> Skipping 'python-ceilometerclient' because it's in the following packagesets: ubuntu-server
<stgraber> (it first looks at packagesets, then goes to check for seeds as that's a costly check)
<infinity> stgraber: Does snakefruit have everything you need to run it there, cronned at * or something?
<slangasek> stgraber: so, what frequency can this run with?  and, is it bound to your home network?
<bdmurray> slangasek: does the verification of bug 1210447 look okay to you?  It seems fine to me
<slangasek> right, that's where I was going with that question
<infinity> slangasek: Jinx. :P
<stgraber> infinity: no seeded-in-ubuntu on snakefruit :(
<infinity> stgraber: Throw a dev-tools checkout in ~ubuntu-archive for now, request the package be installed if precise is good enough for your uses?
<infinity> (Might also have firewall issues)
<stgraber> infinity: oh, and we need network access to ubuntuwire
<infinity> In fact, we have a dev-tools checkout.
<infinity> Arguably, we should be running these ubuntuwire services ourselves, a bit closer to the archive.
<infinity> seeded and reverse-depends and whatever else.
<infinity> But for now, I've requested a firewall hole.
<stgraber> infinity: squid.internal lets me access ubuntu-wire, so that should be good enough
<infinity> stgraber: Ahh, that works.
<infinity> stgraber: I'm happy with the libunity-webapps review, BTW.  Feel free to accept it blind once you're finished your tool testing.
 * infinity really goes to find food now, before he passes out.
<slangasek> bdmurray: isn't that covered by an MRE?
<slangasek> in which case, yes
<stgraber> infinity: gah, just reviewed ceilometer for nothing (didn't see your comment above) :) I'll reject for now
<lool> stgraber: powerd should be a good test
<stgraber> lool: yep
<bdmurray> slangasek: well, its a provisional MRE but yeah
<slangasek> bdmurray: right, then LGTM
<stgraber> ubuntu-archive@snakefruit:~$ ./auto-accept
<stgraber> Accepting: powerd
<stgraber> Accepting: mediascanner
<stgraber> Accepting: mediaplayer-app
<stgraber> Skipping 'libunity-webapps' because it's in the following packagesets: ubuntu-desktop
<slangasek> bdmurray: btw, would you happen to have time today to look at the gnu-efi + sbsigntool packages in the queue?  I'd like to get that out the door so I can forget all about SecureBoot again :)
<stgraber> so confirmed it DTRT with both the packageset and seeds check, will get the script out of dry-run mode now
<slangasek> hurray, made bug #1205075 someone else's problem
<bdmurray> and is it just me or does the schooltool-book upload to raring look like a mistake?
<stgraber> and ran for the first time, we should see 3 accepts nowish
<slangasek> tada
<stgraber> ok, now we just need to run that thing every, say, 5 minutes?
<slangasek> every minute, please
<stgraber> ok
<slangasek> unless you know precisely which minute out of every 5 to run it to ensure it sees the queue updates :)
<infinity> The queue updates every minute.
<slangasek> ok
<infinity> And so should the auto-accept.
 * slangasek nods
<infinity> lool / asac: So if you guys also want to do blocks for touch, you have that power delegated.  But this compromise here should blance quick accepts of unseeded uploads with late-cycle paranoia for other images.
<infinity> s/blance/balance/
<stgraber> I have a tiny concern about the script hammering LP and ubuntuwire a bit more than it should since I'm not doing any caching for past entries, but I guess it won't be that bad and if someone complains, it's just a matter of sticking a cache on the thing
<infinity> stgraber: Thanks for the quick hack.  Love your work, crazy tool man. :P
<infinity> stgraber: It won't hammer LP any appreciable amount.  ubuntuwire could be another story.  But you ARE grabbing the json via a squid proxy.  If you're not forcing cache invalidation, that should catch the hammering.
<slangasek> "crazy tool man" -- the best of the MegaMan mods
<stgraber> alright, it's been cronned and the output redirected to a .log file. I've commented all the "skipping..." ones to avoid getting a mile long log file after an hour, we can always turn those back on if we need to figure out why something didn't get auto-accepted
<ogra_> ^^^ this ubuntu-touch-meta introduces two new binaries, can someone guide them out of binary NEW please ?
<infinity> stgraber: Say, did your script already fail? :)
<stgraber> infinity: I'm looking at it :)
<infinity> ogra_: And yes, once it's built, I'll jam it through.
<ogra_> thanks
<stgraber> infinity: now to figure out why it works fine when ran manually and fails under cron...
<infinity> Environment?
<stgraber> that's my guess, but it's not writing anything to stderr so it's failing in a rather silent way...
<stgraber> put it into verbose mode for now so I can see whether it at least gets to the queue properly
<infinity> stgraber: Need PYTHONPATH=/home/ubuntu-archive/python maybe?
<stgraber> Skipping 'android' due to Invalid output from seeded-in-ubuntu.
<stgraber> that typically means it's not happy with my http_proxy, which weirdly enough I don't have in my env either... anyway, easy enough to fix
<stgraber> let's see if the next run accepts android
<infinity> stgraber: Just call it with http_proxy=http://squid.internal:3128/ like the autosync above?
<infinity> Ahh, you did. :)
<stgraber> yep :)
<infinity> stgraber: Same problem.  Also, s/>/>>/
<stgraber> infinity: I just s/>/>>/ :) but yeah, same problem, so maybe not a proxy problem after all, I'll get the code to print the actual error
<bdmurray> slangasek: shouldn't bug 1066038 have a raring task?
<stgraber> infinity: you were correct earlier, I needed the PYTHON_PATH, I just didn't think I did because it was set by default in ~ubuntu-archive's environment
<stgraber> android got accepted, so looks like it's working fine now
<infinity> stgraber: I'd suggest timestamps in the log too, so reading it once it gets large isn't quite so hard.
<infinity> stgraber: (And maybe package_version, so we don't end up with 37 androids, all alike)
<infinity> And I really need to do the eating thing now.
<infinity> slangasek: I'll be double-checking mirror health and putting together the final announce as soon as I get back from food, if you have touch verbage for me by then.
<Riddell> are we there yet?
<slangasek> bdmurray: 1066038> precise/quantal/raring, you mean?  Good question; I wasn't intending to do any separate SRU verification for that change, which is why I didn't open tasks
<slangasek> infinity: sorry, got caught by an unhelpful OOM condition here that made everything go wonky and am now piecing my desktop back together... and I need food too before I go on
<slangasek> infinity: so it'll be a little bit before I can have anything for you
<darkxst> infinity, thanks ;)
<slangasek> Riddell: so unfortunately, even though we ran into this problem last cycle already and /thought/ we had addressed the issue by fixing our checklists, apparently we missed a spot and are again in the situation of being unable to change the website redirect outside of UK business hours :P
<slangasek> so I believe everything is /published/, and flavors can feel free to announce etc., but the Ubuntu announcement won't go out until we can fix the web redirect so that we're not flooding the pipe
<slangasek> i.e., "when London wakes up"
<lool> mdeslaur: dsc0t-make-check     FAIL status: 0, stderr: ../../test-driver: line 95: 29235 Aborted                 (core dumped) "$@" > $log_file 2>&1
<lool> mdeslaur: systemd autopkgtest failed
<lool> mdeslaur: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for details
<lool> and link to jenkins jobs
<lool> mdeslaur: to clarify, it's an autopkgtest of a package depending on systemd
<slangasek> lool: looks like there are two adt failures? one for colord, one for systemd itself
<slangasek>  cp: cannot create regular file â/tmp/mkinitramfs_QeYyHu//lib/modules/3.11.0-8-generic/kernel/drivers/net/ethernet/natsemi/natsemi.koâ: Input/output error
<slangasek> ... ok then
<slangasek> lool: that appears to be a pre-existing bug in colord, it's been failing continuously since July and apparently no one has cared :/
<lool> I think infinity forced the colord side
<lool> but the other failure probably prevented it from migration
<slangasek> the other failure looks like a random jenkins slave failure
<slangasek> the dmesg on that one implies fs corruption
<slangasek> plars: ^^ is that something you would be able to fix?
<slangasek> plars: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-systemd/85/ARCH=amd64,label=adt/
<knome> slangasek, what are you suggesting for flavors?
<slangasek> knome: that you should feel free to proceed with any per-flavor announcements you had planned without waiting for the central mail to go out
#ubuntu-release 2013-09-27
<stgraber> adam_g: hey there, that troveclient upload is supposed to contain some file permission fixes, but I'm not seeing that in the diff, did you miss something?
<stgraber> adam_g: ah, nevermind, I re-read the changelog entry and it's just the modes of the files within debian/ which can't be represented in a diff, will accept the upload now
<adam_g> stgraber, ah, cool. thanks
<stgraber> libsystemsettings1 (from ubuntu-system-settings) is seeded in:
<stgraber>   lubuntu: supported
<stgraber> ubuntu-system-settings (from ubuntu-system-settings) is seeded in:
<stgraber>   lubuntu: supported
<stgraber> in case someone wonders why ubuntu-system-settings isn't getting auto-accepted
<stgraber> the reason for that seems to be indicator-bluetooth on non-gnome based flavours
<slangasek> stgraber: erm, that sounds entirely bogus
<stgraber> slangasek: it's broken ordering of indicator-bluetooth dependencies
<slangasek> accepting
<slangasek> stgraber: well, if it's seeded in "supported" anyway, that shouldn't trump the fact that it's a touch package and covered by the policy for touch
<stgraber> slangasek: yeah, as I said in -ci I'm not against getting it approved but I'd like to make sure someone will take care of the wrong dependency ordering of indicator-bluetooth
<slangasek> I don't see why it's picked up by lubuntu supported at all; http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.saucy/supported seems to show an infinite loop
<stgraber> yeah, there seems to be a unity related loop in there, I didn't look much closer than that, however the depends on indicator-bluetooth is wrong and should be fixed (which may be enough to convince germinate to drop ubuntu-system-settings from that seed so we don't have to force it in the future)
<slangasek> I don't see that the dependency is wrong; it's arbitrary which one is listed first, anything that actually cares which one is pulled in should make sure it's installed before pulling in indicator-bluetooth
<slangasek> pulling g-c-c + gnome-bluetooth in on the phone is no less wrong than pulling u-s-s in on the desktop
<stgraber> well, I don't see why someone would suddenly need to add a dependency for some gnome packages when a release ago they didn't have to, so adding any alternative that you don't want everyone to use should be done by prepending them, not appending
<stgraber> bah, the other way around :)
<slangasek> that's fair, but lubuntu isn't *actually* depending on unity anyway
<slangasek> so by this point anyone who is, and who doesn't want the phone implementation, has already dealt with this - forcing the dependencies to be flipped now is just causing churn for the phone images
<stgraber> well, we have no idea how many Lubuntu users out there actually installed indicator-bluetooth post-install and that germinate output says that if any did, they'll end up with ubuntu-system-settings on their system, so I agree it's not a critical bug to fix, but I still want it fixed by release
<stgraber> (especially as I believe we got all the other indicators fixed in the same way recently when something similar affected Edubuntu a few days back)
<slangasek> We can estimate the number of lubuntu users installing indicator-bluetooth at zero.  It doesn't integrate with lubuntu, and people don't install lubuntu if they're looking for unity.  The bug is in germinate, not in u-s-s.
<slangasek> if the phone seed + indicator-bluetooth both get fixed before release, then that's fine, but it's a minor issue
<stgraber> slangasek: what needs fixing in the phone seed? ubuntu-system-settings has been listed in there since it's been uploaded to the archive.
<slangasek> stgraber: is it listed in there in an order that ensures germinate won't pick up g-c-c + gnome-bluetooth *and* u-s-s?
<stgraber> slangasek: both the indicators and ubuntu-system-settings are listed in the same seed, so I believe so. Most if not all other indicators list those the other way around, so I don't see how fixing the odd one would change anything.
<slangasek> stgraber: in fact, indicator-bluetooth is listed first in the seed before any of the other indicators or u-s-s.  So with the current seed, this dependency is the only thing that's keeping the touch image from pulling in the wrong deps.
<slangasek> which is exactly why we shouldn't be in a hurry to flip or'ed dependencies around that aren't actually hurting anything
<slangasek> ah, it's ubuntu-defaults-builder
<slangasek> lubuntu inherits from platform/supported-development-desktop, which lists u-d-b, which depends on unity-common
<slangasek> stgraber: so given that 'supported' is, by definition, "seeded stuff that's not on the images", shouldn't we ignore supported for this check?
<slangasek> not quite sure why this only shows up in the lubuntu seed, really, given that it's part of "supported-common" which is used everywhere - but anyway, I don't think "supported" is what we meant by "seeded".
<stgraber> I suspect there's a fair amount of server packages that are in supported (due to limited space) and which we don't want to just let through, so I don't think allowing packages only seeded in supported through is a good move
<stgraber> nagios3, exim4 and freeradius are some that come to mind at least and I know we've got a bunch more in our seeds
<slangasek> stgraber: right, but I think that's because supported has a special meaning for Ubuntu ... because it means "and that other stuff in main".  But for !Ubuntu, I don't think it has any meaning
<slangasek> certainly, the presence of unity in the lubuntu seed shows that it doesn't mean anything in *that* case
<slangasek> so what about ignoring supported for !Ubuntu?
<plars> slangasek: I haven't really dealt with the adt tests, that's jibel and pitti... I could try retriggering it if you think it would help
<slangasek> plars: well, it's not the tests so much as the environment... that error clearly points to fs corruption
<slangasek> plars: is that anything you could fix?
<slangasek> plars: barring that, a retry is also fine :)
<plars> slangasek: I didn't see any obvious issues on the build slave, could be something in the jenkins environment not getting cleaned up properly. The run-adt-test script there does have a datestamp of today
<plars> the job itself isn't updating it though
<plars> so I'm not sure if there's another job somewhere that pulls the latest of that, or if someone updated it by hand today
<slangasek> plars: so whatever filesystem was corrupted is no longer an issue?
<plars> slangasek: those errors are after it's already in the VM, but the host system seems ok
<slangasek> plars: and the VM isn't reused across multiple jobs?
<plars> slangasek: It's probably cow, but I'm not familiar with the setup
<slangasek> hmm, alright
<slangasek> so if you could retry the job, that'd be keen
<plars> slangasek: yeah, looks like it does: qemu-img create -f qcow2 -o backing_file=$DISKPATH $BCKPATH
<plars> slangasek: these jobs are started in an unusual way it looks like, but I'll give it a shot
<slangasek> right... so there could be corruption on the underlying base image, or the VM itself might've somehow corrupted it
<plars> slangasek: still failing
<plars> blame: arg:systemd_204-0ubuntu13.dsc dsc:systemd
<plars> badpkg: dependency install failed, exit code 1
<plars> quitting: erroneous package: dependency install failed, exit code 1
<plars> slangasek: any chance it's a legitimate failure?
<plars> slangasek: there's also a .crash file getting picked up from the run for initramfs-tools
<mfisch> Evening all. Does the beta et al freezes apply to syncing a new debian package into Universe?
<slangasek> plars: I don't see any way it could be a legitimate failure in the systemd autopkgtests that the /tmp filesystem is corrupt.  Was this on the same jenkins slave again?
<slangasek> mfisch: syncing a new Debian package into universe is covered by feature freeze
<plars> slangasek: talking to pitti about it now, apparently that machine caused some weird problems like this recently
<slangasek> ok
<plars> slangasek: he's worked around it for now, it came back green this time
<slangasek> alright, thanks :)
<didrocks> sil2100: Mirv: any of you published friends? I wonder why it came without any landing requests ^
<sil2100> didrocks: not me, maybe robru ?
<didrocks> robru: did you? ^
<sil2100> Since I saw a task for unblocking libfriends assigned to him
<didrocks> sil2100: maybe, but it's not about publishing it without a landing slot
<sil2100> Maybe robru misinterpreted it...
<didrocks> can we have anyone unblocking libunity + scope-home?
<infinity> didrocks: s/unblocking/reviewing/ and yeah, I'll look in a sec.  Sorting some things.
<didrocks> thanks infinity
 * cjwatson goes to accept the pile of langpacks
<Laney> cjwatson: Think pitti was doing it
<cjwatson> ok
 * infinity hands some buildds to i386 for the incoming barrage.
<Laney> care to change the default release in queuediff?
<infinity> cjwatson: Oh, if you didn't catch up on backscroll, we now have a hack in place that auto-accepts non-set/unseeded packages, so unapproved should only be full of things that actually need review.
<cjwatson> Yep, I heard
<cjwatson> infinity: want me to look at didrocks' request?
<infinity> cjwatson: I was grabbing it, but if you're keen on reviewing unity, I won't stop you. :P
<infinity> Oh, I guess it's just libunity, how bad can it be?
<Mirv> didrocks: nope
<cjwatson> If you're already on it I'll leave you to it
<infinity> cjwatson: Alrighty.
<stgraber> ^ that's me marking the milestone as released
<Riddell> sigh, they should have gone to a ppa, I'll delete
<smartboyhw> Riddell, -.-
<ogra_> qeueu party !
<ogra_> *queue
<didrocks> ogra_: will, now, it's killing party for Riddell :p
<ogra_> didrocks, doom3 queue party then ;)
<apw> someone got lucky
<xnox> stgraber: hm cherrypy3 in ubuntu. I go to look.
<attente> hi, can i request an unblock of indicator-keyboard? this bug was fixed: https://bugs.launchpad.net/indicator-keyboard/+bug/1228489
<Laney> attente: I don't see it
<attente> Laney, the bug?
<Laney> attente: Also, no need to request approvals now that beta is done; we'll be reviewing https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text= often
<Laney> the upload
<seb128> I'm going to do a manual upload in a bit, so don't worry about the upload
<seb128> (need the .pot to be added since that launchpad fix hasn't been deployed yet)
<Laney> So, nothing to request for this one
<attente> oh ok
<attente> Laney, seb128, thanks
<Laney> Feature freeze still stands for other stuff, of course
<attente> Laney, do i need a FFe for this bug?
<Laney> not for bug fixes
<Laney> was just making sure that me saying "no need to request approvals" wasn't too broadly stated
<attente> ah, understood
<seb128> attente, Laney: it's already in saucy: https://launchpad.net/ubuntu/+source/indicator-keyboard/0.0.0+13.10.20130924.2-0ubuntu1
<Laney> oho
<attente> oh.. i didn't realize that
<attente> yay :)
<infinity> zul: Did you discuss the above upload with anyone, or just feel that the appropriate response to a reject was to upload the exact same thing again and hope for a different review?
<infinity> zul: Ahh, you filed an FFe bug this time.  Would have been nice to reference that in the changelog... And also not mysteriously delete the last version from the changelog too.
<zul> sorry
<apw> $ md5sum ubuntu-13.10-beta2-server-amd64.iso
<apw> 4d869a82e8bc4e88de6379a0609fe598  ubuntu-13.10-beta2-server-amd64.iso
<apw> dammit ... not that channel ok
<attente> Laney, i have this FFe for unity-greeter, can you please take a look at it?
<infinity> zul: Can you fix up the changelog to not drop the 1.0.3-0ubuntu2 revision from history, and include a ref to the FFe?
<attente> https://bugs.launchpad.net/unity-greeter/+bug/1228207
<zul> infinity:  sure
<Laney> attente: ok
<Laney> attente: Didn't see it before because it's not on the ubuntu package
<Laney> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&field.status:list=NEW&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-release&field.structural_subscriber=&field.component-empty-marker=1&field.tag=&f ...
<attente> Laney, sorry about that, i'm not really familiar with the FFe process
<Laney> ... ield.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search&orderby=st ...
<Laney> ... atus&start=0 â the URL I use to see outstanding requests
<Laney> omg
<Laney> http://is.gd/CgE4Hu
<infinity> *cough*tinyurl*cough*
<infinity> Or is.gd. :P
<attente> ah, so FFe requests need to be on ubuntu? should i re-write the request?
<Laney> it's fine, I'll add the task
<Laney> I'm just sayin' that's why I didn't see it so far
<attente> oh ok
<attente> thanks Laney
<infinity> It should be against the package, yes, not the upstream project.
<attente> ok, i see, thanks infinity
<Laney> In other news, I just superglued my fingers together
<infinity> Did you type that with your nose?
<Laney> I've ripped them apart
<cjwatson> You can reduce that URL to https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-release&orderby=status if you don't mind it also showing Fix Committed
<Laney> The oresum bar remembers it for me
<attente> Laney, thanks!
<stgraber> Rejected oslo-config, some changes in the upstream changelog looked like features and I don't see a FFe or a bug report justifying why this should get in after FeatureFreeze
<stgraber> Laney: wow, that's one confusing diff for glib-networking :)
<stgraber> though apparently it's pretty much exclusively automagic changes and addition of tests, so I guess that's fine
<Laney> yeah I think it's ok if you filter out the guff
<stgraber> yeah, didn't see any obvious bad change in there, I'll let it in and accept the the new binary once it shows up
<Laney> thanks
<Laney> we should totally have a tool to filter noise from diffs
<infinity> Laney: Like filterdiff?
<Laney> I guess it'd wrap filterdiff
<rtg> infinity, a nice fat saucy kernel to gum up the works for you.
<infinity> rtg: Mmm, fat and saucy.
<rtg> indeed
<infinity> rtg: That's a remarkably conservative point release.  Urgent bugfixes in there, or is Greg still hung over from New Orleans?
<rtg> infinity, 117 stable patches I think. thats not totally conservative
<infinity> rtg: It's pretty conservative, given the size of some of the recent ones.
<rtg> true
<infinity> rtg: Accepted.
<rtg> infinity, thanks
<zul> stgraber:  1232062 for oslo.config
<zul> hi can i get oslo-config accepted please (#1232062)
<apw> bug #1232062
<Riddell> zul: accepted
<zul> thanks
<Riddell> qt guys ship minified javascript and are suggesting to put a pointer to sources, is that acceptable? http://lists.qt-project.org/pipermail/development/2013-September/013226.html
<infinity> Riddell: No.
<Riddell> didn't think so
<infinity> Riddell: As stated in that post you link, pointing to somewhere else (that might change, not stay in sync, disappear) isn't an acceptable form of "providing the preferred form of modification".
<stgraber> Riddell: for packaging, I believe you should either use an already packaged version (libjs-*) or ship the upstream modifiable version of the library (if the minified version gives you a performance improvemented, then you could minify it at build time but the source package needs the full version)
<stgraber> *improvement
<stgraber> Riddell: what? http://launchpadlibrarian.net/151652586/mplayerthumbs_4%3A4.11.1-0ubuntu1_4%3A4.11.2-0ubuntu1.diff.gz
<stgraber> Riddell: that seems pretty minimal for a new upstream release ;)
<jodh> stgraber/slangasek/xnox: FYI: just raised FFe bug 1232119 for upstart.
<xnox> jodh: i didn't think there needs one.
<stgraber> jodh: bugfixes don't need FFe, is that more than a bugfix?
<jodh> xnox/stgraber: ah right, thanks - yes it's just a bug fix so I'll close that sucker :)
<Riddell> stgraber: lots of kde sc packages don't get updates between releases, but they're all released nevertheless
<stgraber> Riddell: so what's the point in uploading that if it doesn't even change the version number in any of the source files? anyway, someone other than me rejected it :)
<Riddell> stgraber: they are all packaged by a script so it's more effort not to upload it than to upload it
<Riddell> I expect gnome does similar
<didrocks> cjwatson: infinity: if you can look at the unity7 stack, that would be awesome ^ (unity8 is depending on it as well to get some good fixes on touch)
<didrocks> (yeah, unity depends on unity ;))
<didrocks> then, it will enable us to cut an image and get ogra_ some sleep :)
<didrocks> (mediascanner is coming in < 3 minutes)
<ogra_> heh
<ogra_> you all sound like i would lack sleep :)
<ogra_> i'm *not* infinity :)
<didrocks> ah no, the mediascanner we needed is already in ;)
<ogra_> yes, its on -changes
<cjwatson> didrocks: firefighting something else right now
<didrocks> ogra_: I hope for you it's not that bad ;)
<didrocks> cjwatson: sure, no worry ;)
<Laney> I'll look
<Laney> Best not to ping individual RT members
<didrocks> thanks Laney!
<didrocks> (and good luck, it's quite a lot)
<Laney> Well, can split it with someone
<ogra_> dont you let half packages through !
<stgraber> Laney: was planning on doing some of them after lunch here, so if you give up I'll pick up the rest
<Laney> half packages?
<ogra_> if you split them :)
<Laney> why would I randomly split packages
 * Laney is confused
<slangasek> to try to probe the inner truths of package particle physics
<ogra_> <Laney> Well, can split it with someone
<Laney> deb rpm duality
<Laney> Oh I see, you mean accepting half of them
<Laney> stgraber: nux compix unity-scope-guahuahfaiu unity-scope-audacious OK
<Laney> -home changes a translated string; not sure about that and unity is left for your enjoyment
<Laney> a visitor just turned up, better go see what's up for a bit
<Laney> o/
<slangasek> ogra_: do you know why /etc/adjtime exists on the Touch images?
<ogra_> slangasek, it doesnt, but as i understood timedated falls over if it isnt writable ?!?
<ogra_> (i guess it would create it)
<slangasek> ogra_: I have /etc/adjtime here on my device; not sure how it got there if it's not part of the image
<ogra_> slangasek, pitt can give yu details i think
<ogra_> slangasek, it was explicitly added to the writable files which creates it if it doesnt exist ...
<slangasek> according to Laney, timedated falls over *if* /etc/adjtime exists *and* isn't writable
<ogra_> well, that stuff will go away again once pittis (and stgraber's) changes for timezone selection land on monday
<slangasek> no
<slangasek> /etc/adjtime is *not supposed to be there*
<ogra_> then there should be a writable dir and no adjtime
<stgraber> stgraber@castiana:~/mnt$ tar Jtvf ~/Desktop/phablet-flash/imageupdates/pool/ubuntu-5219cfe1d590fddbebe1228872ff1529156efdc996571da44cbbe2438b37cee9.tar.xz | grep adj
<stgraber> -rw-r--r-- root/root        10 2013-09-27 04:15 system/etc/adjtime
<slangasek> it's not supposed to be in /etc/writable either
<stgraber> so it sure is in the image generated on nusakan...
<ogra_> yes
<ogra_> as i said
<ogra_> there was an assumption that timedated needs it in the commit that adds it to writable-files ... pittis change will drop the code that creates it
<ogra_> and pittis change is scheduled for monday ... so image 71 should not ship adjtime anymore
<slangasek> ogra_: pitti's change moves the file to /etc/writable, which is *still wrong*
<slangasek> we should find what *created* the file, and fix that
<ogra_> slangasek, i'll talk to pitti then
<ogra_> it wont be fixed befoe monday anyway
<ogra_> slangasek, i'm pretty sure stgraber's touch initrd script touches /etc/adjtime if it doesnt exist but is in /etc/system-image/writable-paths
<ogra_>                                        if [ ! -d "$dstpath" ]; then
<ogra_>                                                 # Deal with redirected files
<ogra_>                                                 if [ "$4" = "transition" ]; then
<ogra_>                                                         cp -a $dstpath $srcpath
<ogra_>                                                 else
<ogra_>                                                         touch $srcpath
<ogra_>                                                 fi
<ogra_> thats the code doing it
<ogra_> and the timestamp on the file in my  install agrees
<stgraber> ogra_: nope
<stgraber> ogra_: the initrd never has write access to / so if the file is not there, it may create it under /userdata but it certainly won't be able to create it under /etc
<stgraber> ^ I rejected unity-scope-home because it's changing a translated string after UIF without an approved exception
<ogra_> stgraber, well, i'm pretty sure that file was never there before i merged cwaynes MP
<ogra_> which only added them to writable-paths
<ogra_> stgraber, omg, really ?
<stgraber> ogra_: what I pasted before was the output of a tar ztvf of the rootfs, and it clearly was in there :)
 * ogra_ sighs that breaks the whole planning for touch :(
<ogra_> (the home scope thing)
<ogra_> stgraber, hmm, it definitely doesnt come from a package
<stgraber> ogra_: sure why not, the package is in pretty much all our images, the only change was a string after the string freeze, so yes, perfectly matches the criteria for rejection
<ogra_> and i surely havent added code to create it anywhere
<ogra_> stgraber, oh, it was supposed ot have a fix ...
<ogra_> *to
<ogra_> yeah, i agree, if its only the string change that wouldnt have helped anyway :)
<stgraber> yeah, it was the only change in there
<stgraber> cdimage@nusakan:/srv/system-image.ubuntu.com$ tar ztvf /srv/cdimage.ubuntu.com/www/full/ubuntu-touch/daily-preinstalled/20130927/saucy-preinstalled-touch-armhf.tar.gz | grep adj
<stgraber> -rw-r--r-- root/root        10 2013-09-27 08:15 etc/adjtime
<stgraber> no idea where that's coming from, but something in the image build process sure generates the file ;)
<ogra_> yeah
<ogra_> well, its not in livecd-rootfs
<stgraber> and that's before any of the system-image stuff ever runs :)
<ogra_> hmpf
<ogra_> root@ubuntu-phablet:/# grep /etc/adjtime /var/lib/dpkg/info/*
<ogra_> /var/lib/dpkg/info/util-linux.postrm:		rm -f /etc/adjtime
<ogra_> not from a postinst either
<stgraber> so must be some command spawned from a postinst creating it then
<stgraber> accepted the result of the autolanding stack. Unity had a pretty confusing changelog but the code changes look fine.
<ogra_> stgraber, yay, thanks ...
 * ogra_ waits for britney before spinning a new image 
<slangasek> ogra_: live-build scripts/build/lb_chroot_hacks.
<ogra_> in live-build itself ?
<slangasek> yes
<ogra_> smells like a bug, why dont we have it in other builds ?
<stgraber> I suspect we do in all desktop images
<slangasek> yes
<slangasek> but it's a bug that went under the radar before
<stgraber> question is, why did dba think that was needed at all...
<ogra_> \o/
<slangasek> well, Debian does use /etc/adjtime.
<slangasek> (it shouldn't, but the reasoning why is difficult to explain effectively so I haven't tried to get that change upstreamed)
<stgraber> ah, didn't know that, so I guess we missed that difference when we rebased on the newer live-build?
<stgraber> anyway, easy enough to fix for any new builds
<slangasek> yes, uploading live-build now
<stgraber> cool, I'll let it through when it's in the queue, maybe we'll have it in place before the next touch build then
<ogra_> stgraber, i can wait :)
<ogra_> touch is all manual ... from code commit to released image
<stgraber> accepted
<slangasek> stgraber: so did we come to any conclusion about packages seeded in "supported" for !Ubuntu?
<stgraber> slangasek: I think I'd have to look at the json file to convince myself it's safe (as I'm not sure all ubuntu supported packages show up under ubuntu), I'd also probably want to make sure none of the existing flavours use supported in a way to indicate that those packages are things they care about and have documentation on but are post-install or language/region specific packages to be installed post-install
<stgraber> so currently, status quo seems easier especially as we haven't seen a flood of those so far
<slangasek> you're checking both seeds and packagesets, right?
<slangasek> shouldn't "think we care about but is post-install" be in the packageset, even if it's not on the image?
<slangasek> s/think/thing/
<stgraber> it should, but the packagesets are generated from the seeds...
<slangasek> hmm
<stgraber> well, some/most flavours ones are, kylin is manual
<ogra_> stgraber, oh, will writable-paths cope with the removal of adjtime ?
<stgraber> yep, it should simply fail to bind mount and move on
<ogra_> great
<ogra_> go britney ... i know you can make it
<slangasek> stgraber: and then we should follow through to remove adjtime handling from the writable-paths stuff as well, and make sure the file is correctly removed on upgrades
<stgraber> slangasek: yeah, my debdiff for lxc-android-config already removes it from writable-paths so once that one land, we'll be good
<slangasek> o
<slangasek> k
<stgraber> we won't need to do any removal on touch since the file will just go away in the next image, though we probably ought to for desktops
<stgraber> not sure what's the best way of doing that though, adding an rm to some common package's postinst?
<slangasek> probably util-linux, I'd guess
 * ogra_ sees live-build vanish from britney ... 
<ogra_> yay
<ogra_> time for an image then :)
<stgraber> ogra_: did you see it publish (rmadison live-build)?
<ogra_> stgraber, if it is gone from tehg excuses page its pretty sure in, no ?
<ogra_> *the
<stgraber> hmm, I guess it should yes, I tend not to trust that and always triple check with rmadison :) anyway, live-build is fully published, so go ahead
<stgraber> (and since we moved the archive stuff to a new box, rmadison got much faster, so it's less of a pain to use nowadays)
<ogra_> well, just using madison after apt-get update should do as well
<ogra_> thats what i usually do
 * stgraber takes lxc
<stgraber> I'll take that one, sounds like a reasonable use of my last 15min of work for the day :)
<stgraber> oh and it's an actual upload, not a sync, sweet!
<stgraber> well, looks like I'll need to find something else to do before my EOD, that one was way easier to review than I expected ;)
<slangasek> libhybris is in core?
<stgraber> apparently
<stgraber> also it seems to be building debs used by kubuntu, go figure
<slangasek> er, um
<stgraber> as in, daily-live, not supported :)
<slangasek> pulseaudio depends on libhardware2
<rsalveti> right
<stgraber> that'd make sense if seeded-in-ubuntu would also list it for say, every other flavours :)
<rsalveti> do I need to do anything to get libhybris released or just wait for it to be published?
<stgraber> rsalveti: I accepted it in the archive, not sure if there's a block on it by the touch release team
<rsalveti> are they doing armhf-based builds?
<stgraber> ah, that might be it, yes
<stgraber> yeah, kubuntu desktop builds on armhf
<rsalveti> right, that's it then
<stgraber> and I haven't been building edubuntu armhf in a long long time, so that's why it's not listed
<rsalveti> pushing new gstreamer-bad in a few minutes as well
<stgraber> so in theory, that means the FFe for libhybris in bug 1208989 isn't valid since some of the binaries are included in non-touch flavours, though that upload was a bugfix, so no problem with that.
<stgraber> (and I'm not seeing any obvious feature addition since FFe for packages affecting the Kubuntu images)
<slangasek> well, I wonder if that means the kubuntu desktop images don't actually have a working pulseaudio on armhf
<slangasek> and whether anyone's tested that
<stgraber> trying to get testing history data from the iso tracker to see if someone tested kubuntu desktop armhf lately
<slangasek> the pulseaudio patches to *use* libhybris seem to have been added post-FF with no FFe bug
<rsalveti> hm, not sure if that was added after FF
<rsalveti> that was to add support for modem/pcm using the android hal
<stgraber> no armhf desktop result for kubuntu since saucy opened apparently
<slangasek> 1:4.0-0ubuntu2 says "add patches for Ubuntu Touch"... that's the earliest mention I can see
<rsalveti> yeah, aug 27
<rsalveti> that was the first one
<slangasek> oh, two days before feature freeze, I see :-)
<rsalveti> :-)
<stgraber> still not ideal that non-touch flavours end up pulling that code too, can't that be done as a pulseaudio plugin in a separate package? (I have no idea how pulseaudio works besides the fact that it has modules ;))
<rsalveti> probably, need to ping diwic next monday
<rsalveti> someone? ^^ :-)
<stgraber> that got auto-accepted
<rsalveti> perfect
<rsalveti> indeed
<rsalveti> was thinking about the good subject
<rsalveti> bad is not seeded
<rsalveti> *subset
<darkxst> have the ubuntu GNOME cron jobs been switched back on?
<stgraber> no
<stgraber> I guess we should do that for all the products
<stgraber> let me do that quickly
<stgraber> all done
<darkxst> stgraber, thanks
<ogra_> stgraber, did you leave touch on manual ?
<stgraber> yep
<ogra_> :)
#ubuntu-release 2013-09-28
<cjwatson> ogra_: apt-cache madison after apt-get update works, but (a) it takes longer to run all that than it does to run rmadison, (b) it introduces an unnecessary delay since you have to wait for ports.ubuntu.com to update, which livefs builds don't require
#ubuntu-release 2013-09-29
<stgraber> I did that, this upload was adding and removing binaries to an existing source package without a clear explenation of the impact. I asked for the uploader to come explain in here.
<stgraber> (I'm not 100% sure this was a FF violation but not knowing the package too well, it was hard to know for sure, so as it's a seeded package, I prefer to err on the side of caution)
#ubuntu-release 2014-09-22
<bluesabre> Release team, please let us know if there is any objection to https://launchpad.net/bugs/1372085 - we have ack from docs and translation teams
<ubot2> Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]
<ubot93> Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]
<ScottK> bluesabre: Did you send the mail to the translators ML?
<bluesabre> ScottK, wasn't sure whether the mail should be sent before or after upload
<bluesabre> I can send it now
<ScottK> Before the approval.
<bluesabre> ok
<ScottK> Write in the bug when it's been sent.
<bluesabre> ScottK, done.
<knome> ScottK, most affected should know this already :)
<ScottK> knome: Still the mail should be sent.
<ScottK> bluesabre: Approved.
<bluesabre> thanks ScottK
<knome> ScottK, sure, agreed. :)
<jack_> hi, release team, would you please review the FFe request at bug #1371165?
<ubot2> bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/1371165
<ubot93> bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/1371165
<jack_> Laney, hi, are you around?
<Laney> hi JackYu (assume that was you), will look at the queue of ffe requests soon
<bluesabre> Release team, please review https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1372391 and let us know if you approve.
<ubot2> Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]
<ubot93> Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]
<knome> i've also pinged Riddell on sponsoring it since he did another upload of it earlier today, but others are free to take it :)
<Riddell> you have?
<Riddell> knome: any screenshots in docs or anywhere that need updated?
<knome> nope, slideshow is the only place we have screenshots in
<knome> well in addition to the website, but those are not used for documentation :)
<Riddell> knome: groovy, uploading
<knome> cheers!
<mlankhorst> infinity: I've tested basic KDE and lightdm, made sure that some of the tests that hung earlier on llvm-3.5 didn't regress, and I'll commit to doing .1 before final release, can you give your ok in https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1364003 so I can upload mesa 10.3.0?
<ubot2> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]
<ubot93> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]
<Riddell> mlankhorst: ooh new mesa? should I test it out?
<mlankhorst> feel free, it's in ppa:canonical-x/x-staging
<Riddell> gotcha
<Riddell> mlankhorst: when you say you tested KDE what do you test?
<mlankhorst> that compositing works without crashes
<Riddell> mlankhorst: so you play around with kwin?
<mlankhorst> Riddell: yeah just the basic things though..
<mlankhorst> enabling/disabling compositing, creating/closing window
<Riddell> mlankhorst: and do you test on all the major video card types? cos in the past we've had problems that occur only on 1 type in one of these FFe mesas
<Trevinho> Laney: hey, could you put some love on https://bugs.launchpad.net/compiz/+bug/1356981 ? :)
<ubot2> Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]
<ubot93> Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]
<Laney> Trevinho: I just loaded it up
<Laney> before your ping
<Trevinho> Laney: ah, cool... :)
<rbasak> Could somebody review bcache-tools from Utopic NEW, please? It's a pretty straightforward package.
<rbasak> (and small)
<infinity> mlankhorst: Commented.
<ScottK> infinity: FYI, kwin upstream say's he's not tested this version of mesa at all and if stuff breaks, we're on our own (he's focused on the Qt5 port we'll use in the next cycle).
<ScottK> Given the complete lack of kwin expertise in the Kubuntu team, I'm officially concerned.
<ScottK> Riddell: ^^^
<didrocks> JackYu: FYI ^
<Riddell> yeah I'm also against it I'm afraid, we can't adequately test it in the time
<JackYu> didrocks, great^
<infinity> ScottK / Riddell: What level of testing would we need to be happy enough?  We can't stop updating mesa because an upstream hasn't tested, this is part of being a larger distro, we sometimes have to take the hit and do the testing (and even fixing) ourselves.
<infinity> THough, yes, the timing is bad, and if we can't test in time, that's a valid reason to NACK.
<ScottK> infinity: I'd be less unhappy if I had some idea who "ourselves" might be.
<ScottK> (re fixing)
<infinity> ScottK: Well, in a Debian context, that would be the maintainers of the packages affected.  In Ubuntu, I'm not sure who should own such a breakage.  If it was "Ubuntu breaking a flavour with our own weird stuff", I'd say Canonical UE owns the problem, but when it's "a flavour needs to keep older versions out of paranoia", that's a bit harder to lay blame. :P
<infinity> Anyhow, I'd love to just see enough testing that people were confident enough.
<infinity> If that can't be done, you guys can NACK, it's well past FF.
<ScottK> How about out of experience that every time we do this, it goes badly.
<ScottK> That's not paranoia, that's history.
<infinity> Wasn't the breakage in the past API/ABI breaks?
<infinity> This one's ABI compatible, I thought.
<ScottK> My recollection is that they weren't all advertised as incompatible.
<Riddell> I don't think it's paranoia to not want risky FFe updates, that's kindae the point of FFe
<ScottK> infinity: Also see Riddell's latest in the bug.  Testing didn't go well for him.
<Riddell> I guess I'd like to see testing reports on intel, amd and nvidia using kwin 4 and 5
<infinity> Yeahp, fair enough.
<infinity> mlankhorst: So, that's no longer a +1. :P
<Riddell> from kwin dev mgraesslin: "As with each mesa version it could mean that the
<Riddell> world explodes (recently we learned that we are no longer allowed to use lose
<Riddell> binding on Intel drivers)."
<barry> sru team: i have a package that must be backported to trusty (it's currently only available in utopic) in order to fix a potentially sru'able bug in another package.  is it allowed for the first package to go into -updates instead of -backports?  ftr: we would need 'wheel' to be available to sru a fix for LP: #1290847
<ubot2> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
<ubot93> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
<ScottK> barry: Doesn't that also imply a stack of changes in other packages to give them wheels?
<ScottK> Also, it probably matters if it has to be in main who would have to say it's OK.
<barry> ScottK: it does
<barry> ScottK: maybe i should just make the error message say "install python-virtualenv and use -p python3"
<barry> and leave it at that
<barry> it's *a lot* of effort to backport a proper fix
<barry> sadly
<infinity> barry: If a less intrusive fix is possible, that's preferrable.
<infinity> barry: We *can* backport new sources to -updates as SRUs, and occasionally do, but I'd prefer it's a last resort, not a go-to.
<barry> infinity: i think the less intrusive fix is print("go use virtualenv")
<barry> infinity: which i'm actually fine with
<barry> infinity: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847/comments/48
<ubot2> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released]
<infinity> barry: Functionally, what ends up being the difference between A and B?  Does either (or both) escape using packaged binaries, is there a security impact to recommending one over the other, blah blah?
<infinity> barry: If printing explicit instructions on how to use virtualenv solves the issue with no real negative side-effects, I think that's fine.
<barry> infinity: there really is no functional difference imho.  it's just that the functionality of virtualenv comes built-in with py3.4 now
<infinity> barry: Kay, but the external virtualenv continues to work as well is the implication?
<barry> yep
<infinity> barry: Could this be hacked to that trying to use the built-in triggers using the external (and print a helpful message instead of a messy backtrace if it's not installed?)
<infinity> s/to that/so that/
<infinity> barry: ie, could "python3 -m venv" transparently check for virtualenv, error if not install, else fork "virtualenv -p python3", and people could then start using the new interface, even if it's using the old method?
<barry> infinity: i'm not sure i like that.  e.g. i'm not positive that the cli switches are totally aligned.  i think i'd rather tell people what to do than do it for them
<infinity> barry: Kay, if they wouldn't be 100% compatible, I agree it's a bad idea, so just printing the "yo, this is broken, try the other thing" would be fine, IMO.
<barry> infinity: would you like to add a comment to that bug with your official sru hat on?
<infinity> barry: Feel free to copy and paste. :P
<barry> ;)
<infinity> barry: Just make sure the printed message attempts to not be too negative/scary, while also being informative enough that people aren't left with more questions than answers.
<barry> infinity: good point
#ubuntu-release 2014-09-23
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 2 | Archive: Final Beta Freeze | Utopic 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
<knome> alpha?
<knome> isn't beta 1 technically out :)
<infinity> Oh, I didn't change that bit. :P
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Beta 1 | Archive: Final Beta Freeze | Utopic 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
<knome> just caught my eye
<knome> is something specific keeping the ISOs from building?
<infinity> ?
<knome> beta 2 images haven't appeared in the testing tracker, but maybe that's another problem
<infinity> Oh, we literally *just* froze for Beta2/FinalBeta, whatever you want to call it.
<infinity> So, nothing in the tracker yet.
<knome> right, that explains it then :)
<knome> any idea of an ETA for first images?
<infinity> Once we get the tracker set up, I'll de-cron the world, and then probably kick off a build of everything before I go to bed.
<knome> oki, cheers, and thanks for all the hard work again
<ScottK> infinity: While you were in there unmoderating stuff for u-d-a, you didn't happen to see my dmb mail from earlier today, did you?
<infinity> ScottK: I did, and I let it through at the same time.
<ScottK> OK.  Thanks.
<ScottK> There it is.
<ScottK> ta
<infinity> ScottK: What made you so sure I self-moderated? :P
<ScottK> How many years have I known you?
<infinity> Like, more than two.
<ScottK> Plenty to have guessed that.
<Mirv> Laney: ^ that compiz, no US timezone trainguards caught the ffe approval
<mlankhorst> infinity: but I did test kwin
<mlankhorst> Riddell: I did test kwin, not sure if 4 or 5, just the default of kubuntu desktop in utopic
<mlankhorst> never heard of kwin5, to be honest..
<infinity> mlankhorst: I don't doubt that you tested it, though seemingly not as thoroughly as Riddell did.
<elfy> infinity: do you know when beta images are likely to start showing on the tracker? and good day to you :)
<infinity> I'm going to hit the button to mass build in ~20m.
<infinity> elfy: So, shortly after that, locking order and luck depending.
<elfy> ok - thanks infinity :)
<mlankhorst> I'm going to need information from Riddell then since it doesn't match my experience
<mlankhorst> Riddell: what graphics card do you have?
<mlankhorst> and 32-bits or 64-bits?
<mlankhorst> Riddell: and as far as I can tell kwin5 is not part of ubuntu
<Riddell> mlankhorst: I've intel on amd64 running plasma 5 from ppa:kubuntu-ppa/next
<Riddell> can't say I can claim to have tested it thoroughly, only that I've tested it and noticed some problems that I didn't notice before, but then maybe I wasn't looking.  the brekage after the apt dist-upgrade is probably due to that upgrade to mesa I expect
<mlankhorst> is that going in 14.10?
<infinity> Err, yeah, if this is the Qt5 kwin that's going into 15.04, that really shouldn't block 14.10 stuff...
<mlankhorst> fwiw i tested kwin4 again and it worked on radeon/nouveau/intel (ivb)
<RAOF> FWIW I've been running 10.3 on my haswell, and it's gone swimmingly.
<infinity> Riddell: So, while I understand the concern that it *might* break things, I'd like to revisit this, testing agaisnt packages that are actually in utopic.
<infinity> Riddell: Nobody's PPA gets to tell the archive what it can and can't include.
<Riddell> right, I'd like to testing it as I test beta 2 images
<Riddell> right, I'd like to test it as I test beta 2 images
<Riddell> but that'll still be intel only
<infinity> Riddell: mlankhorst claims to have tested amd/nvidia/intel, but if you can give him hints about specific things to do/test other than boot, log in, look around for obvious icky stuff, I'm sure he'd be all ears.
<Riddell> mlankhorst: what did you do for your tests?
<mlankhorst> mostly on 64-bits, test LIBGL_ALWAYS_SOFTWARE=1 and see if there is anything obviously wrong, test normal radeon/intel/nouveau, even tested the resizing after your comment, nothing failed
<mlankhorst> though 32-bits a little too
<mlankhorst> fwiw I tend to run mesa snapshots on precise with kwin 4.10.97 currently
<mlankhorst> didn't notice any issues with kwin lately
<Riddell> I've made a testing matrix, will try to fill it in during beta 2 tests today and tomorrow https://docs.google.com/spreadsheets/d/1KchGJ6d50Knx9hGS7MvSRKhId-yBMOpPpUoihKHyJm0/edit?usp=sharing
<mlankhorst> Riddell: now add mir / without mir and the various cards and watch your testing matrix explode ;-)
<Riddell> fortunately I care not for mir, but I ought to for wayland (but well, I'll leave that for another year)
<mlankhorst> can you test with what's in the archive first please?
<Riddell> sure
<mlankhorst> because all those things work for me on nouveau/amd64
<Riddell> great
<Riddell> queuebot: spammer
<infinity> Riddell: Anyhow, I don't want to get in the middle of this any more than I already have, but the reason this is (potentially) landing as late as it is is that I gave mlankhorst a preliminary ACK weeks ago, under the assumption that due diligence was shown, and he went off to test and report back.
<infinity> Riddell: If we can reasonably prove that it's not harmful to utopic, there are obvious wins (hardware support, and dropping llvm-3.4 on the floor), so I'd like to at least try and see if we can make it happen.
 * Riddell wonders why okteta is in ubuntu-desktop
<mlankhorst> why would one not want to have a kde hex editor in ubuntu? ;-)
<mlankhorst> Riddell: !intel works correctly it seems
<mlankhorst> I tested those things with radeon and nouveau against 10.3 with i386 and amd64, didn't test kwin5 yet though
<cjwatson> man-db sync is for bug 1370059; also bug 1372673 along the way.
<ubot2> bug 1370059 in man-db (Ubuntu) "FFe: man-db 2.7.0" [Undecided,Confirmed] https://launchpad.net/bugs/1370059
<ubot2> bug 1372673 in man-db (Ubuntu Trusty) "excessive debconf use when triggered" [Undecided,New] https://launchpad.net/bugs/1372673
<mlankhorst> Riddell: hey how do I start kde5?
<Riddell> install kubuntu-plasma5-desktop and log in to Plasma 5 session
<mlankhorst> oh I did that, but also seems to need plasma-desktop
<mlankhorst> dolphin draws updates just fine
<Riddell> yeah that was a curious one off bug I had which I can't recreate now
<mlankhorst> the konsole thing seems to be a focus bug, clicking on the other window and back works fine
<mlankhorst> not really a mesa bug though
<mlankhorst> if you click in a certain way it seems that konsole believes it lost focus
<mlankhorst> but switching to another window and back works
<Riddell> I expect it's a general kwin bug, I just need to check if it happens in mesa 10.2 to confirm it's not mesa's fault
<mlankhorst> they're focus bugs, it's not like it stops rendering, it just stops believing it has focus
<mlankhorst> selecting a line in konsole works
<mlankhorst> same bug with mesa 10.2.6 here..
<Riddell> figures, I'm downloading beta 2 candidates now to test
<infinity> cjwatson: You should tell your man-db upstream to get on board with our release cadence.
<cjwatson> Yeah, that guy sucks
<infinity> He also talks funny.
<infinity> cjwatson: So, feel free to let that man-db into proposed, looks sane.  We'll unblock it for the next respin, assuming the current crop isn't found to be completely perfect. :P
<Riddell> every iso is beautiful in its own special way
<infinity> *snort*
<infinity> I guess I should try to sleep.
<infinity> Catch you all "tomorrow".
<cjwatson> infinity: done, thanks
<pitti> ^ there are no effective upstream changes betwen 13.92 and 14.0 (that's rc2 vs. final, often the case)
<pitti> just some small packaging noise (bumping standards-version), plus getting back in sync
<pitti> so that's almost zero riskk
<pitti> ^ already in production
<pitti> (i. e. autopkgtest CI machines)
<pitti> cjwatson, infinity, ScottK, stgraber: ^ notes to whoever looks at unapproved these days/hours
<oSoMoN> hey, Iâve got webbrowser-app sitting in the unapproved queue, Iâd be glad if someone could ack it (it implements security certificates visual feedback, and has been thoroughly tested)
<ogra_> oSoMoN, do you have a freeze exception ?
<ogra_> (we're in final beta freeze)
<oSoMoN> ogra_, no, IÂ donât
<ogra_> not sure, but you might need one
<cyphermox> could someone please review wpa; it's a small but rather important/useful bug fix
<Laney> pitti: Don't think there's need to ping per se, people poll the queue
<pitti> Laney: ah, I didn't mean "do it now", but wanted to leave some information for people who do look at the queue
<pitti> as these are syncs and thus rather inconvenient to review
<Laney> fair enough
<Laney> at least 'queue fetch' works for those these days
<pitti> I'm fine with not doing that though, not sure how the unapproved reviews are done today
<cjwatson> slangasek: ^- could you review that fairly quickly so that we can unblock the phone?
<slangasek> looking
<slangasek> cjwatson: seems like this problem would've been caught at image build time if live-build/ubuntu-touch/hooks/48-setup-env.chroot were set -e; I wonder if an audit here is warranted
<slangasek> (and accepted)
<ogra_> slangasek, oh, pretty please
<cjwatson> yeah, possibly
<slangasek> ogra_: well, I can just add 'set -e' to all of them, and then when they start failing you know they were buggy :)
<ogra_> probably not right now ... but i would also like to clean up /etc/environment
<ogra_> (but that needs some real world testing too)
<slangasek> yeah, being reminded of that file again is going to require a liberal application of ethanol to reverse
<ogra_> haha
<ogra_> i guess 80% of it can just be wiped
<slangasek> SHLVL=1 - yes please :P
<ogra_> but i also think that will need a day of actual heavy testing each single removal
 * slangasek nods
<ogra_> which eats time nobody has atm
<rbasak> ^^ missing bug reference bug 1371805. Sorry, noticed just after uploading.
<ubot2> bug 1371805 in python-django-openstack-auth (Ubuntu) "Please merge python-django-openstack-auth 1.1.6-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1371805
<zul> can someone reject nova-compute-flex please, i need to upload the changelog
<zul> er..update the changelog
<Laney> accepted wpa as an unblock candidate
<Laney> don't know if we have anywhere to record these
<bregma> can I please get an unblock of Compiz in utopic-proposed since the required FFe for #1356981 was approved?
<wxl> anyone know why there's no lubuntu-desktop release? i wonder if i can just add it
<wxl> stgraber:  can you tell me where lubuntu desktop went?
<elfy> wxl: you might need infinity for that
<wxl> infinity: ? looking for wee lost lubuntu desktop
<wxl> anyone? :(
<jamespage> Please could another member of the release team review the python-xstatic FFe/sync requests I outlined via email last week; we have a completely broken horizon in the archive right now and I'd like to fix it!
<balloons> stgraber, can you confirm https://launchpad.net/~lubuntu-product-managers is the manager for lubuntu builds
<stgraber> those two shouldn't affect the beta but will be useful for touch, they've been succesfuly tested in a PPA ^
<infinity> wxl: Err, crap, accidentally build the desktop ISO for trusty.  Looks like someone else fixed it for you, though?
<wxl> infinity: i figured it out thank you :)
<stgraber> win 54
<stgraber> gah, works better with a / in front of it
#ubuntu-release 2014-09-24
<mlankhorst> infinity: so looks like from the table that the problems Riddell had were not caused by mesa 10.2 -> 10.3
<infinity> mlankhorst: Alright.  Can you get him to sign off on your findings, and let's JFDI this upload once he has?
<infinity> mlankhorst: If we have cause to respin, I might like to get it in the beta to get wider testing, but realistically, it would probably land right after.
<elfy> infinity: if lightdm gets a fix for the vm issue will that likely cause a respin
<infinity> elfy: Yeah.
<elfy> hopes it gets fixed :)
<mlankhorst> infinity: looks like he has
<mlankhorst> according to comment #12 on bug 1364003
<ubot2> bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New] https://launchpad.net/bugs/1364003
<infinity> mlankhorst: Alright, if you're willing to commit to fixing kwin/mesa issues (if there are any, which looks less and less likely), a fresh +1 from me.
<mlankhorst> goodie
<infinity> mlankhorst: There's no transition required or anything, right, just a regular ol' mesa upload?
<infinity> elfy: Which bug is that?
<mlankhorst> just a mesa upload
<infinity> mlankhorst: Right, make sure you're happy with your current source and fire away, then.
<infinity> elfy: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1371651 ?
<ubot2> Launchpad bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged]
<infinity> elfy: That looks like a bit of a blocker to me.  Would certainly be a ship-stop RC for the final release, and I'm about 98% sure it should be for the beta too.
<elfy> infinity: agreed
<infinity> elfy: I mean, on the one hand, I don't care deeply about VMs, and neither do the majoriy of our actual users.
<elfy> unless we move to systemd really quickly - seems to work ok with that :D
<infinity> elfy: But, on the other hand, the majority of our QA processes revolve around VMs working right. :P
<elfy> well yea - I'm off that opinion re vms - but as you say the majority of testing is done with vm
<infinity> Or, rather, I don't care deeply about *desktop* VMs (except for the above mentioned QA concern).
<infinity> Server VMs are a whole different story, but if you're running lightdm on a server, you should probably find a new job that doesn't involve being near servers.
<elfy> infinity: I understood what you meant
<mlankhorst> anyway mesa in unapproved now :P
<infinity> mlankhorst: I'll review and pick it up in the morning, and then we can talk unblocking it for the beta.
<mlankhorst> oke
<jibel> the fact that it's reproducible on VMs doesn't mean it is not a problem on hardware too, until we know what causes it.
<cyphermox> would it be possible to unblock wpa despite the freeze? I think it would benefit everyone, especially those who work in office buildings where the roaming issues are more likely to happen, and is critical for touch :)
<jibel> seb128, could someone look at bug 1371651 ? it happens on all the flavours in vbox and qemu, I didn't try on hardware.
<ubot2> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
<seb128> jibel, that would be one for robert_ancell but he already called it a day at this time I think
<jibel> seb128, anyone else? looks like a race in the boot sequence. lightdm doesn't even try to start
<seb128> jibel, not sure, maybe jodh can help if an upstart job issue?
<jamespage> please could the nova-compute-flex packages be rejected from the NEW queue - zul and I reviewed last night and we want to make some changes prior to acceptance into the archive
<jibel> jodh, ^^ any idea about bug 1371651, I attached syslog with --debug enabled
<ubot2> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
<JackYu> hi, release team, who could help to look at the Critical bug #1372731?
<ubot2> bug 1372731 in Ubuntu Kylin "the slideshow for ubuntu kylin utopic beta-2 rc is ubuntu's slideshow" [Critical,Confirmed] https://launchpad.net/bugs/1372731
<JackYu> cjwatson, infinity, ping...
<cjwatson> looks like livecd-rootfs is using the wrong live task
<JackYu> cjwatson, thanks. Could you fix it?
<cjwatson> usually when I make that kind of comment it's stream-of-consciousness on the way to fixing it :P
<JackYu> cjwatson, great^ !
<cjwatson> stgraber: committing your livecd-rootfs change to bzr so that I can commit more stuff on top
<cjwatson> infinity: ^- could you please review livecd-rootfs for ubuntukylin?
<Laney> where do the actual sources.list buildd chroot overrides live?
<Laney> Want to check how backports is handled
<cjwatson> Laney: lp:launchpad, lib/lp/soyuz/adapters/archivedependencies.py
<Laney> cjwatson: Cheers - I was hunting for https://bugs.launchpad.net/launchpad/+bug/888665/comments/27 which I found in the chroot itself
<ubot2> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released]
<JackYu> cjwatson, hi, it seems that livecd-rootfs was updated, should we rebuild the iso for beta-2?
<cjwatson> JackYu: No, it's still waiting for review in the queue.
<cjwatson> JackYu: I can't (well, shouldn't) review my own change there, so can't help further right now.
<Laney> Accepted
<Laney> Don't know if you want a respin given the probably lightdm one
<Laney> probable
<JackYu> cjwatson, Laney, thanks. Let me try..
<Laney> It'll take a while to get into the release
<cjwatson> you need to check "rmadison livecd-rootfs" before triggering builds
<cjwatson> it must be >= 2.246
<cjwatson> specifically "rmadison -s utopic livecd-rootfs", in fact
<JackYu> OK, I will check.
<cjwatson> Laney: would you care to review python-apt and software-properties as well (mostly my changes so I can't review)?  We want those in ubuntu-rtm sooner rather than later really
<cjwatson> Bit of a stack behind them
<Laney> cjwatson: 'kay, just disappearing for lunch though but after that
<mlankhorst> xnox: hey is https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1242572 still important?
<ubot2> Launchpad bug 1242572 in xkeyboard-config (Ubuntu) "xkeyboard-config, console-setup, and ubiquity should use Super+Space for switching keyboard layouts" [Medium,Confirmed]
<ypwong> JackYu, new livecd-rootfs ready
<stgraber> cjwatson: oops, sorry about that, thanks for taking care of it!
<JackYu> ypwong, thanks, rebuilding...
<Laney> cjwatson: Accepted
<Laney> Will be subject to the block
<cjwatson> That at least gives me binaries to copy, thanks
<stgraber> cjwatson, slangasek, infinity: hey, so I've been chatting with hallyn about an ipxe issue he's having when migrating VMs between precise and trusty. Apparently qemu is a bit retarded and requires that the option ROMs match perfectly on the source and target, otherwise VM restore fails. As a result, hallyn is looking for a way to get precise's ipxe on trusty.
<stgraber> one of my suggestions is to have a ipxe-legacy package or something of the sort which at build time downloads and extracts the option roms from the past releases and then ships those inside its own binary package. Now the question is, is that something we can actually get into the archive, seeing how it wouldn't be entirely trivial to find the matching source?
<stgraber> I guess the package could include the series and package version that was used as the source of each of the binaries so someone can then go fetch the source for that one either from archive.u.c or from old-releases.u.c or directly from LP, but not nearly as easy as it'd usually be
<cjwatson> I can't think of a good answer for that
<cjwatson> Is there really no way to relax qemu?
<cjwatson> Alternatively, have the upgrade process take copies of the old files in the preinst until it's sure (somehow) that it doesn't need them any more; I think I've seen that done somewhere else and it would be simpler ...
<stgraber> so apparently it's not just a pointless check in qemu, feeding it the wrong binary (say, padded with zeros at the end) makes it fail on reboot
<cjwatson> After all you *only* need this on upgraded systems
<stgraber> cjwatson: no, you don't. The use case is two hosts, one on precise, one on trusty, both fresh installed, then live migrate a VM between the two
<cjwatson> Ugh
<cjwatson> You would have to ship the source somehow; I don't know whether it's still possible to build it, maybe with an old compiler and just the right options
<cjwatson> Shipping source that it isn't actually possible to build doesn't count as source IMO :P
<stgraber> cjwatson: ok, so pointing to the precise source package isn't good enough then? because if you do run a precise system and build the binary on it, you will get the expected binary :)
<cjwatson> It's a pretty grey area, but this feels on the dark side of grey to me
<stgraber> ok
<stgraber> hallyn: so preferred way would be to just ship the precise source in trusty, potentially tweaking it to use the same compiler and other bits to ensure we don't have any potential size difference or broken binary
<hallyn> so yanking the prcise .deb and extracting the rom would be frowned upon then?
<stgraber> hallyn: with the obvious and preferred alternative being to just fix qemu to be a bit more reasonable (say, just store the path in the migrate state and only read said file at boot time)
<cjwatson> The benchmark for me is whether a user can actually make changes to the source we supply
<cjwatson> If it's this picky it kind of feels to me as though the option ROMs should be stored in the migrate state ...
<cjwatson> But I know little about qemu internals
<hallyn> is building a container inside the package build to build the old packag in ok? :)
<hallyn> agreed, and i think rharper has (this week) been discussing that with upstram
<cjwatson> Only if you can do that unprivileged
<hallyn> but that doesn't help the current case - which, fwiw, is to enable migration from precise->trusty
<hallyn> what kernel are the buildds on?
<stgraber> well, you don't need a container, fakeroot+fakechroot+debootstrap mostly works
<cjwatson> hallyn: look at the top of any build log
<stgraber> and we've got a few packages doing that kind of ugliness already
<hallyn> i wasn't sure if they were all the same these days
<cjwatson> they're the same across non-virt x86
<hallyn> but again - pulling the ro mfrom the precise package, which is build all from source, doesn't really violate the "user can make changes to the source we supply" bencmark
<cjwatson> I dunno, I don't feel persuaded but I cannot currently properly articulate my counterarguments
<cjwatson> sorry
<hallyn> np, i'm just looking for the best way, don't parcticularly care what that ends up being
<cjwatson> it feels like an RC bug of the form "can't rebuild this from source in the latest release"
<hallyn> buildds ar eon 3.2, not good enough for unpriv containers ,so i'd have to go with regular fakeroot+
<hallyn> true
<hallyn> tbh right now the precise package does build (with one change) in trusty just fine, so we don't (currently) need t oworry about the chrooting
<cjwatson> oh well that sounds like the path of least resistance then
<hallyn> until the next isolinux breaks the build a bit more
<hallyn> so is it preferred that i 'pull-lp-source' the package fro mdebian/rules, or include the source in the trusty package source?
<cjwatson> latter IMO
<stgraber> hallyn: so I think so long as the only time we care about this is precise to trusty, just getting the precise source SRUed to trusty and then depend on it should do the trick. That's assuming qemu will be a bit more reasonable going forward and we won't run into that problem with every single Ubuntu release in the future.
<cjwatson> with a "make update" or similar
<cjwatson> I suspect you can't talk to the Launchpad webapp from the buildds anyway
<hallyn> rharper: ^ do you think that in the next 6 months we may get reasonable handling of romfiles on migration?
<cjwatson> only to the archive itself
<hallyn> I don't know what 'make update' is
<cjwatson> a hypothetical target to update the source from the archive on a developer's system
<stgraber> either one source package with a make update as suggested by cjwatson or make a sed script which you can run against the ipxe source in precise to turn it into a new ipxe-legacy source package
<stgraber> basically the exact same trick we do for HWE backports, except that one will be the other way around :)
<hallyn> you mean just to make it so it builds ok in trusty?
<cjwatson> yeah
<cjwatson> ubiquity has to embed other source packages for different reasons and does this kind of thing
<rharper> hallyn: upstream?  I don't know;  we'd need to provide a proposal;  any change to migration (and savevm) format is going to be controversial
<rharper> likely met with "it's a downstream" problem
<hallyn> this isn't about the machine type, it's purely about needing versioned romfiles to migrate across versions
<rharper> hallyn: it's a support issue w.r.t where the boundaries are w.r.t migration support
<rharper> the only place you can be certain migration works (modulo bugs in the code) is between same architecture , same OS version, and same QEMU versions
<rharper> as soon as you change one of those, the likelihood of failure is MUCH MUCH higher, and a vendor needs to validate that specific deviations work
<rbasak> Could you pull it out of the scope of the archive?
<rbasak> We already publish resources needed by other tools that are "trans-release", IYSWIM.
<hallyn> stgraber: above you said "just getting the precise source SRUd to trusty and then depend on it" - that  makes it sound like you're talking about a separate 'ipxe-legacy' package, as opposed to shipping the precise ipxe source under debian/legacy in the ipxe trusty source?
<rbasak> MAAS needs installer images from multiple releases, for example.
<cjwatson> possible; would probably require Launchpad work
<rbasak> How about a simplestream feed of ROMs extracted from different releases?
<stgraber> hallyn: correct. There are basically two ways of doing things, either a single source package with both source trees and an update script as suggested by cjwatson or just take the whole source package from precise, rename all occurences of ipxe to ipxe-legacy in there, apply your patch and upload as a new source. Then update ipxe to recommend ipxe-legacy.
<hallyn> rbasak: what would guide the fetching and installing of those?  (it coudl be a nicer solution than messing with the ipxe source)
<rbasak> hallyn: we have simplestreams tools in the archive, so it shouldn't be too difficult.
<hallyn> stgraber: i didn't think the latter would be possible for trusty as an sru
<stgraber> hallyn: we've been introducing new packages as SRUs in the past, there's no technical issue with that but it's pretty rare
<hallyn> rbasak: but it would require a whole new repo of roms
<rbasak> True.
<rbasak> That can be a fairly static web resource though.
<stgraber> rbasak: you do ultimately get into the same problem though, you're shipping a binary for which the source is only available in an old, possibly out of support release and where you can't actually rebuild it to produce an identical binary (because of toolchain variations over time)
<rbasak> stgraber: I think it's reasonable this way round though.
<rbasak> You're publishing the binary out of a binary distribution for which the entire source is available.
<rbasak> You can rebuild the binary using the release of the distribution from which it is from.
<stgraber> rbasak: the exact same was true of the initially suggested idea of just having the package build in trusty grab the binary from precise, and that was deemed not good enough
<rbasak> I think there's a difference here.
<rbasak> It's assumed that all binaries in Trusty can be rebuilt entirely from Trusty sources.
<cjwatson> it makes me uncomfortable so I don't think I'm prepared to say I'd accept it.  I haven't actually vetoed it
<rbasak> That assumption breaks in that case.
<cjwatson> but certainly actually grabbing it from a precise-generated repo would be simpler in some ways
<rbasak> OTOH, take it out of the scope of the archive, and that invariant still holds.
<stgraber> rbasak: the other concern I've got with the out of the archive method is that any corporate environment will likely have a local mirror and firewall off external access, so they won't be able to get those binaries
<rbasak> stgraber: true. simplestreams is a format designed to make it easy to mirror though.
<stgraber> and that may be all fine as a solution going forward, but pushing that as a SRU would seem like a pretty severe regression to me
<rbasak> MAAS and Juju have the same concern, and it's a unifying format for anything that needs to be mirrored and cryptographically verified.
<rbasak> I agree it's not great in an SRU, but is it really a regression if the whole thing is broken already and the solution is that you need to mirror a binary?
<stgraber> hmm, true, if the only thing we were to ship that way was the precise binary on trusty, that may be fine
<rbasak> The only thing I'm suggesting publishing this way is the necessary binary.
<rbasak> Nothing else. Everything else, including support code, can come via an SRU.
<stgraber> I still think the best fix here is just get the precise source into trusty, solving the immediate problem withouth much more complexity, then fix qemu to be more reasonable, either by storing the ROM content in its state or by loading the blob entirely back from disk every time it needs it
<rbasak> It does sound reasonable that qemu should send across the ROM contents during a live migration if it requires it on the other end.
<rbasak> My suggestion is definitely a long term thing. Pointless if it's just a one-off.
<ogra_> is there a chance someone could let the HUD out of unapproved ? it has a touch only fix in it that blocks otehr landings
<rbasak> Especially if the precise source will built on Trusty and generate the required binary there. Then just import the source into Trusty under a different name.
<stgraber> we also have another problem here which thankfully we haven't ran into yet, if I was to SRU an iPXE bugfix in precise and that'd make the binary say 900 bytes larger somehow, then I'd be into the weird case where I'd have running VMs expecting the older smaller binary and some running with the new larger one, what happens when we try to migrate both of those set of VMs?
<stgraber> rbasak: it currently does with just a small change to the source apparently, so we're lucky in that sense
<hallyn> rbasak: so yeah lets keep that in mind for a longer term solution.  bc i also expect more headaches inthe future from toolchain changes which make building the legacy version in modern releases.
<rbasak> So with simplestreams, you could publish all the binaries.
<hallyn> perhaps something to discuss at uds
<rbasak> As long as the other end can figure out which one it wants, you could get it.
<hallyn> so i'll work on a ipxe-legacy package this afternoon.  thanks all.
<rbasak> (by version, or sha256, or any other key)
<stgraber> rbasak: except that qemu only knows about a single, non-versioned, path :)
<rbasak> Try each until it doesn't fail :-P
<rbasak> (yeah that's terrible I know)
<stgraber> :)
<hallyn> stgraber: true (single non-versoined path) and we need a libvirt change to handle that
<hallyn> so this really does need to be handled in qemu source longer-term
<stgraber> hallyn: have you tried live migrating an OVMF backed VM? surely the same will happen with the OVMF blob
<hallyn> (libvirt has to pass an option to qemu to tell it to use the older file)
<hallyn> stgraber: haha.  no.  haven't touched ovmf other than to push annoying papers away with those letters on them
<stgraber> :)
<hallyn> rharper was mentioning it yesterday though.  sounded like it does not in fact handle that yet
<rharper> OVF (not sure about OVMF) is just a container (tarball)  libvirt doesnt run an OVF, some other mgmt tool needs to unpack, define, and start
<cjwatson> OVMF is a UEFI BIOS image for VMs
<cjwatson> entirely different :)
<rharper> ah
<rharper> stgraber: qemu/libvirt do not migrate any of the rom files associated with a VM;  rather the assumption is the destination host is "compatible" with the source; that's a problem left up to the management application orchestrating the migration in the first place.
<Odd_Bloke> rcj: o/
<mdeslaur> the bash update I just uploaded to utopic is a critical security fix
<cjwatson> mdeslaur: thanks, reviewing
<mdeslaur> cjwatson: thanks
<cjwatson> infinity: we could make an argument for respinning the world for this bash vuln
<cjwatson> maybe
<zul> can yo ureject the nova-compute-flex again
<ogra_> mdeslaur, can we have it into rtm too ?
<cjwatson> ogra_: how about I copy it directly?
 * sil2100 is fine with that
<cjwatson> I think I need to wait for it to be published first though
<mdeslaur> utlemming: you probably want new ec2 images for that bash update also
<cjwatson> ogra_,mdeslaur,sil2100: copied to rtm now
<mdeslaur> cjwatson: thanks
<sil2100> cjwatson: thanks!
<utlemming> mdeslaur: ack, incidently our images will automagically respin once it hits the archive
<utlemming> mdeslaur: but yeah, we'll have new images for that
<mdeslaur> utlemming: sweet, wasn't sure if that was being done yet or not. glad to hear it is.
<utlemming> mdeslaur: the only part that is manual for us is the promotion to calling it beta-2. Otherwise cloud images are automagically built on archive changes.
<infinity> rbasak: FWIW, I wish people wouldn't recommend simplestreams as a knee-jerk response to distribution methods. :P
<infinity> rbasak: While it's technically true that it's designed to be mirrored/mirrorable, every time you ask a customer/user to mirror Yet Another Repository, you've upped the complexity by a ton.
<infinity> rbasak: Especially in a case like this qemu thing, where it's entirely non-obvious that they'd need to do so without, perhaps, reading some obscure README along the way.  It's not like juju, where it kinda just fails to be useful until you've understood why.
<infinity> Fundamentally, any time we do anything outside the archive.ubuntu.com FTP tree, there better be a really good reason for it, not just an "oh, this is hard in the archive, let's push the burden elsewhere, whee".
<lool> Hey, so network-manager in unapproved improves the reporting of visible WiFis; changes were discussed with upstream and tested by Mathieu, HERE folks and myself
<lool> basically too many / too old wifis were reported prior to this change
<lool> mathieu tested on desktop
<infinity> Hrm, that langpack upload timing was unfortunate.
<cjwatson> stgraber: shouldn't ~ubuntu-archive/auto-accept have some kind of lock if it's going to run at * * * * * ?
<infinity> cjwatson: Probably, though it shouldn't take longer than a minute.
<infinity> (Maybe the langpack-fest has broken that assumption, though)
<cjwatson> infinity: I just saw two running at once, which is why I asked.
<stgraber> oh, that's the first time I hear of it taking more than a minute
<infinity> stgraber: Probably owing to the 292 queue items.
<jdstrand> fyi, cups just has some apparmor updates, no code changes
<wxl> cjwatson: i figure you're probably the best contact on this subject. any idea what is amiss here? https://bugs.launchpad.net/ubuntu/+source/yaboot/+bug/1367448
<ubot2> Launchpad bug 1367448 in yaboot (Ubuntu) "kernel 3.16.0-14-powerpc-smp won't boot" [Undecided,Confirmed]
<rsalveti> stgraber: was planning to sync livecd-rootfs into rtm, but saw there's one big change regarding groups and so on that you pushed
<rsalveti> stgraber: anything you want to test/validate first or do you think the sync should be fine?
<infinity> wxl: Hrm, the kernel could have gotten too big for yaboot again. :/
<infinity> wxl: I meant to switch powerpc to grub this cycle, I probably should have found time for that.
<wxl> infinity: didn't realize that was a common problem. any ideas on solutions?
<wxl> infinity: it's sad that i've been trying hard as all get out to get ppc testers and it takes until beta 2 for people to finally start helping argh
<infinity> wxl: Well, that's just a shot in the dark, but it's happened before.
<wxl> infinity: who might i point this at that could better assess the situation?
<infinity> wxl: Me or cjwatson, I suppose, but I'm not sure we'll be able to diagnose and fix for the beta.
<wxl> infinity: well even if we could aim for the release that might be nice. at least looking into it would help and perhaps encourage our ppc testers to get off their you-know-whats next cycle :)
<infinity> wxl: I have a yaboot-using PPC machine running trusty here, I can slap the utopic kernel on it and see if it explodes.
<infinity> Ideally, though, we should ditch yaboot and move to grub2.  But if this is what I think it is, it'll affect upgrades, which is a nastier problem.
<infinity> This happened sometime between hardy and lucid too.
<wxl> infinity: well that's good to know!
<wxl> as far as grub2, yeah, i guess that deserves some discussion
<wxl> i certainly like the notion of being more standardized
<infinity> wxl: I think the only discussion required for grub2 is to decide on someone doing the work. :P
<wxl> hahahah
<wxl> i thought you were volunteering infinity :)
<infinity> wxl: Well, and if we try to forcefully upgrade people's bootloaders, or just ship new installs with grub2 and let old ones stay yabooty on upgrade.
<wxl> that seems like a legitimate approach
<infinity> But letting old ones stay with yaboot implies making sure yaboot works. :P
<wxl> yeah well that right there may be a good argument for forcefully changing
<wxl> i mean the arch *IS* community supported. is it safe to assume that community can handle supporting yaboot ad infinitum?
<infinity> wxl: IBM still uses yaboot internally, so it has an active upstream, but yeah, I don't think it's sane for us to pretend we can/will support it ourselves when things go wonky like this.
<infinity> wxl: Oh, hrm, the two reports I can find are both 32-bit.  I don't have any 32-bit hardware with yaboot.
<infinity> wxl: I'll test on my 64-bit machine, but if that Just Works, then this'll be a bit more fun to diagnose.
<wxl> infinity: yeah memory's a little different there, eh? bummer.
<wxl> infinity: lars who reported it in iso testing is a Good Guy. he's always willing to help. i'm sure he could provide assistance where needed.
<infinity> My 32-bit machine can't run yaboot, so that's less helpful. :P
<stgraber> rsalveti: sync should be fine. The change will prevent the uid/gid changes and will fail your build and get you a diff if anything extra shows up. So it's perfectly safe to sync but you may need to tweak the included user and group lists if your next build fails. The provided diffs will make that pretty easy as you can basically just copy/paste from them if they make sense.
<rsalveti> stgraber: great, will sync and trigger a new image then, thanks!
<infinity> wxl: trusty yaboot and utopic kernel boot fine on 64-bit, FWIW.  So, yeah, this'll need some deeper digging that I can't do locally. :/
<wxl> infinity: well let me know if you come up with anything else
<infinity> wxl: I might be able to test/diagnose with qemu, but I certainly won't have time to do it in the next 24h.
<wxl> infinity: yeah and my luck with virtualized ppc has not been great. it'll take 24h just to load up the OS :)
<infinity> -CONFIG_KERNEL_START=0xc0000000
<infinity> -CONFIG_PHYSICAL_START=0x00000000
<infinity> +CONFIG_KERNEL_START=0xc2000000
<infinity> +CONFIG_PHYSICAL_START=0x02000000
<infinity> Could be this...
<infinity> wxl: Do you have a machine that's affected by this, or are you just relaying for others?
<wxl> infinity: relaying mostly. i have a 64 ppc and that's about it :(
<wxl> infinity: but i'm happy to help coordinate. as the release manager for lubuntu, i'm trying REALLY hard to keep ppc alive..
<infinity> wxl: Well, I might spin up a test kernel later today, if you can find someone to test it.  It won't get fixed for the beta, but if we know we have a fix in the pipe, we can just release the image with a caveat that it only works on 64-bit machines until the next daily that includes a new kernel.
<wxl> infinity: can do
<ogra_> stgraber, rsalveti, oh, i thought cjwatson wanted the software-properties fixes landed before syncing livecd-rootfs
<rsalveti> ogra_: that was published
<ogra_> oh, which did already happen
<ogra_> yeah, ignore me
 * ogra_ hides in a corner
<mdeslaur> The nss update fixes a critical vulnerability
<infinity> wxl: Okay, pretty sure we found the problem and fixed it blind.
<mdeslaur> cjwatson: ^
<mdeslaur> cjwatson: also needs to be copied to rtm
<wxl> infinity: what 't'was?
<mdeslaur> (details: https://www.mozilla.org/security/announce/2014/mfsa2014-73.html)
<infinity> wxl: See the tail end of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1363180
<ubot2> Launchpad bug 1363180 in linux (Ubuntu Utopic) "utopic alternate install CD doesn't boot" [Medium,Confirmed]
<infinity> wxl: Personally glad it didn't turn out to be a yaboot bug.  Boot loaders being unable to load $nextseries kernels are an upgrade nightmare. :P
<wxl> excellent thanks infinity. should i consider the other bug a dupe of this?
<infinity> wxl: I already duped the other one.
<wxl> ah wonderful thank you infinity !
<wxl> infinity: could you give me a heads up when the dailies have the fix in them?
<infinity> wxl: I'll try to remember, but best to just subscribe to the bug and see when it's fixed.  The next daily after the fixed kernel is in will work.
<wxl> oh right, derp thanks :)
<infinity> wxl: And you can just notify your testers that testing the beta on 32-bit kit is a lost cause, and just focus on 64-bit testing.
<wxl> infinity: well, at least for release, yeah. working on it.
<wxl> meanwhile i'm glad to see progress is being made on the lightdm, now upstream issue :)
<rbasak> infinity: I'm just seeing a pattern here. So much stuff at the moment seems to be "trans-" release, IYSWIM. That doesn't fit well with the existing model.
<infinity> rbasak: juju is a unique snowflake in this case, really.  I'm not sure it's fair to say it's a common problem.
<infinity> rbasak: The qemu thing can be treated as a one-off, I think.
<infinity> rbasak: If it really does turn out to be a common problem going forward, I think it's worth discussing the simplestreams stuff being hosted under the archive.ubuntu.com tree.
<infinity> rbasak: Cause it's wildly unintuitive and a bit hostile to people with longstanding Debian/Ubuntu backgrounds to suddenly require mirroring extra stuff just to make an internal mirror work.
<infinity> rbasak: (It's possibly worth having that discussion just for the sake of juju, really, even if nothing else needs it)
<mlankhorst> \o/
<mdeslaur> infinity: perhaps you could handle the critical nss release to utopic, and the copy to rtm? cjwatson didn't respond.
<infinity> mdeslaur: I can certainly handle the former.
<infinity> And only a 500k diff...
<mdeslaur> infinity: new upstream, sorry
<infinity> Hrm, how did that ppc64el patch ever work, I wonder?
<infinity> It was testing for ppc64el, not ppc64le.
<infinity> mdeslaur: Also, what's with the weird empty changelog entry?
<infinity> +nss (2:3.17.1-0ubuntu1) utopic; urgency=medium
<infinity> +
<infinity> +  * SECURITY UPDATE: update to 3.17.1
<infinity> +    - see USN-2361-1
<infinity> +  * debian/libnss3.symbols: updated for new version.
<infinity> +  * debian/patches/38_ppc64le.patch: removed, upstream.
<infinity> +
<infinity> +  *
<infinity> +
<mdeslaur> infinity: we didn't get _any_ details on what the issue was
<infinity> + -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Wed, 24 Sep 2014 07:58:07 -0400
<mdeslaur> oh, wait, there's an extra line?
 * mdeslaur looks
<mdeslaur> argh, wth
<mdeslaur> infinity: I can re-upload if you want, didn't notice that
<infinity> mdeslaur: Go ahead. :)
<infinity> mdeslaur: I'm nothing if not a pointlessly anal-retentive jerk about these things. :P
<mdeslaur> don't worry, that makes two of us :)
<hallyn> hm, i was goign to call the legacy ipxe package 'ipxe-legacy', but i suppose calling it 'ipxe-precise' would be more future-proof?
<infinity> hallyn: If we suspect we'll have to do this again in the future, yeah.
<infinity> hallyn: I'd like to have to, mind you.
<hallyn> yeah i've got a nasty feeling i'tll happen again
<hallyn> you'd like to have to?  do it again?
<infinity> Err, not have to.
<infinity> Fingers missed a word.
<infinity> Riddell / ScottK: I assume the mess of KDE stuff in the queue is for post-beta?
<infinity> Riddell / ScottK: Or were you planning to jam it all in and respin ASAP?
<mdeslaur> lol "Rejected by Adam Conrad: spite"
<infinity> mdeslaur: That might be my default rejection reason when I have nothing more constructive (and when I know the uploader).
<infinity> I'm a little more polite with people who don't know me. :P
<mdeslaur> hehe
<infinity> I'm not sure how I'm meant to be productive with a purring ball of fluff attacking me.
<stgraber> infinity: I'd recommend you let unity-settings-daemon through, that'll save you a bunch of space on the beta-2 media, the current version depends on a bunch of -dev packages for no good reason
<infinity> stgraber: Ew.
<infinity> zequence: Is anyone doing ubuntustudio beta testing?
<zequence> infinity: I will be, yep
<infinity> zequence: Kay, just wanted to make sure someone was, since I saw no results yet.
<slangasek> infinity: so you're driving final beta - bash in utopic-proposed is a security update; can it be hinted through?
<xnox> did i file an FFe bug correctly? I was hoping to land updated btrfs for beta, I guess that's a tad late for that https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1372367
<ubot2> Launchpad bug 1372367 in btrfs-tools (Ubuntu Utopic) "FFe Upgrade btrfs-tools to 3.16" [Undecided,New]
<xnox> but would be great for final.
<xnox> there is a new point release however that I still need to package, so there will be another update after that.
<xnox> I made it be blocked in proposed until release team approval.
<Riddell> infinity: yeah post beta
<infinity> slangasek: It can be, yeah.  We'll pick it up on the respin, if/when that happens (I'd like to see a lightdm fix happen, but not sure if it will)
#ubuntu-release 2014-09-25
<slangasek> infinity: ok - not really in a position to add the hint for bash now, could you add it when you get a chance?  (or else I'll try to get it later)
<infinity> slangasek: Unless I get a lightdm fix, I'm not seeing massive arguments to respin anyway (respinning for security fixes that we can just release 5m after the images publish isn't worth it)
<infinity> slangasek: So, we'll see what people come up with for lightdm later tonight.
<slangasek> infinity: is that an argument for not accepting them in?  I don't follow
<mdeslaur> there's going to be another bash update in the next few hours, FWIW
<infinity> slangasek: No, more just an "if you were accepting it to get it on the images, it might not do so".
<slangasek> right, I don't care about the images which are always out of date the instant they arrive :)
<mlankhorst> infinity: hey should mesa be moved to main?
<infinity> mlankhorst: By "main", do you mean release?
<mlankhorst> yeah
<infinity> At some point, yes.
<mlankhorst> ok
<jamespage> Laney: morning
<jamespage> Laney: going back to our xstatic conversation last week, would it be more paletable for horizon to re-bundle the xstatic dependencies its split out for this cycle? thus avoiding lots of delta with Debian and minimizing the security footprint of Horizon JS dependencies in Ubuntu main
<jibel> jodh, good morning, seb128 assigned bug 1371651 to you. Are you actively looking at it? Is there more information I can provide?
<ubot2> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
<Riddell> kubuntu plasma 5 isn't on the iso tracker for beta 2, can someone remind me how to add it?
<Riddell> syslinux still has no option for OEM and a random "back" entry
<jodh> jibel: Just updated the bug. I'm not seeing the issue with 20140923. Do you?
<jibel> jodh, I reproduced with 20140923. It's easier to reproduce with vbox than qemu. On qemu it happens once every 5 boots or so
<jodh> jibel: sounds like a kernel issue then. I don't believe it's upstart that's the problem here.
<jodh> jibel: can you reproduce on amd64?
<jodh> jibel: the bug has been tagged amd64 but nobody seems to have seen the problem on amd64 right?
<cjwatson> Riddell: yeah, I see I've just been handed a critical bug for that, I've been meaning to poke at that :-/
<jodh> jibel: oh I see, elfy presumably has seen it on amd64.
<jibel> jodh, let me try on amd64
<jibel> jodh, same problem on amd64
<jodh> jibel: can we get a list of packages that have changed between the 2014-09-19 image and the previous one?
<jodh> jibel: doing a reboot loop to try to recreate atm...
<jodh> jibel: just updated the bug. can you recreate if "quiet splash" is not specified in /etc/default/grub ?
<jibel> jodh, without "quiet splash" lightdm always starts. tried on 5 boots
<jodh> jibel: that's what I'm seeing. I tried a lot more boots too. So that suggests it's a kernel issue.
<Laney> jamespage: It might be - would that avoid the need for all of the xstatic deltas?
<Laney> Sorry for the slow reply
<Laney> I'd still prefer a second opinion. :)
<jamespage> Laney: yes it would
<jibel> apw, can you help on bug 1371651 ?
<ubot2> bug 1371651 in lightdm (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged] https://launchpad.net/bugs/1371651
<Laney> I find the "re-bundle because we don't want to offer full security support" to be a bit uncomfortable
<Laney> like we've got your back if you use the libraries through xstatic but not directly
<Laney> but I could be out of whack on this hence asking for someone else to think
<jamespage> Laney: did you see jdstrand's comment last week?
<Laney> Yeah
<jamespage> Laney: so essential what we're doing by bundling all of the xstatic bits in horizon is maintaining the status-quo
<jamespage> as in that's exactly what horizon upstream where doing last cycle
<rtg> can someone please approve linux 3.16.0-18.25 in the Utopic queue ?
<cyphermox> could someone please review and release wpa? it's an important fix for roaming issues
<elfy> jodh: yea - definitely seen it on both 32 and 64 bit assuming you're talking about 137165, one of the xubuntu testers first found it on the 19th October Daily
<elfy> and without quiet splash I still had the same issue
<elfy> jodh: to confirm that last - in vb 64bit without quiet splash - it drops to tty1 on boot
<elfy> service lightdm status = stop/waiting
<jodh> elfy: ok, please could you capture that detail on the bug?
<elfy> added the stop/waiting - but I did say I was landing at tty1 in comment at the beginning of the week
<elfy> bbl
<jdstrand> Laney: fyi, I looked at the new horizon approach from jamespage. security team is ok with it (since, as mentioned, it is the status quo wrt support)
<Laney> jdstrand: Seems okay to me if you guys are happy with that
<jdstrand> Laney: well, it is hard to be happy about embedded code copies, however, it is maintaining the status quo and we already had this discussion in the horizon MIR several cycles ago
<Laney> Well, indeed, embedded code copies was my original unhappiness
<Laney> It's relative... :)
<jodh> jibel: any news from the kernel team?
<jibel> jodh, no.
<jibel> apw, around?
<jodh> jibel: how about trying a problematic image with an older kernel to see if it's recreatable?
<arges> cjwatson: the bash security update (4.3-9ubuntu2) seems to be stuck in proposed.
<cjwatson> arges: up to infinity whether to unblock it, as he's driving the final beta
<ogra_> infinity, drive faster !
 * ogra_ needs the hud from unapproved :P
<zequence2> In case anyone wonders, Ubuntu Studio testing for the i386 will be finished no later than about 2h from. Hope that's cool with everyone.
<zequence2> 2h from now, that is
<apw> jibel, i am looking at that now, do i see you saying that after install on reboot (on kvm) it will occur one in 5 as well?
<jibel> jibel, yes approximately on kvm it's reproducible 20% of the time, on vbox it's 100%.
<apw> jibel, that seems likley to turn out to be two different issues; but we shall see
<jibel> apw, ok, for the moment i'd like to understand the scope and impact of the problem to know if it's a ship-stopper for beta 2 or not
<apw> jibel, yep, working on that, when you have it in vbox what is the frambuffer normally called for that
<jibel> apw, how do I know?
<apw> lsmod | grep fb perhaps
<jibel> apw, this command returns nothing, but dmesg tells, vesafb and it uses fb0
<apw> vesafb that seems reasonable, and available as far as i can see... odd
<infinity> jibel: If it's only happening in VMs, I'm inclined to not call it a ship-stopper.
<infinity> jibel: (I was hoping a fix would be sorted out by now, but I don't see it worth delaying the beta by a day or more)
<infinity> apw: The lack of vesa in lsmod would be because of CONFIG_FB_VESA=y
<infinity> (Was that always true?  I could have sworn it used to be a module)
<ogra_> yeah, it used to be
<cjwatson> we've gone back and forward on that iirc
<infinity> jibel: Can we generally confirm that this lightdm/fb/plymouth/whatever issue doesn't seem to happen on real hardware?
<infinity> jibel: If it's limited to VMs, I'm inclined to not care for B2, and then hunt people down to make sure it's fixed ASAP afterward, since it affects testing.
<jibel> infinity, I didn't see any report on HW and didn't reproduce on HW either, nor omer. So it seems limited to VMs and affecting vbox more than others.
<jibel> infinity, the workaround is simple, press esc on boot to display the boot menu or remove "quiet splash" or start lightdm manually
<infinity> jibel: Right, I care about virtualbox very little, free desktop VMs a bit more (because of testers), and server VMs a lot more, who aren't affected.
<infinity> jibel: elfy claimed he could reproduce even without quite/splash, which seemed a bit sketchy.
<infinity> jibel: But either way, if it's only VMs, it's not a blocker for me.
<arges> infinity: according to the bug report it also affects KVM VMs
<jibel> infinity, on another topic, what's your opinion on the lack of OEM option in the boot menu?
<jibel> infinity, bug 1334189
<ubot2> bug 1334189 in gfxboot-theme-ubuntu (Ubuntu) "pre-boot menu offers no OEM mode on Utopic live images" [Critical,Confirmed] https://launchpad.net/bugs/1334189
<infinity> jibel: Again not a beta blocker, but seems like a regression we should want fixed.
<cjwatson> I intend to fix that, there's just only one of me :)
<infinity> cjwatson: Hire that Evan guy.
<jamespage> Laney, jdstrand: ^^ horizon as we discussed; I'll deal with the sync request FFe's now
<Laney> Ta
<jdstrand> nice!
<Laney> I'll leave it to be flushed out after beta if you don't mind
<jdstrand> fyi, apparmor upload is to fix a small policy bug and more importantly updates the lxc Breaks version
<jamespage> Laney: fine - its not on any of the images...
<Laney> ah, even better, then the auto accept script should do it
 * Laney looks suspiciously at it
<elfy> infinity: it doesn't matter what I do - unless I'm either booting with systemd or manually starting lightdm - it doesn't work here
<Laney> Oh
<Laney> It's doing an 'is this in any packageset?' check too
<Laney> Is that useful in addition to seeded-in-ubuntu?
<elfy> infinity: and what did you mean by sketchy?
<jamespage> Laney: its seeded in the server-supported seed
<jamespage> so won't auto-accept
<Laney> I thought auto-accept was accepting everything not on images
<jamespage> Laney: that would be nice :-) but I don't think that's the case
<jamespage> Laney: have neutron in the queue as well - same situation
<infinity> Laney: No.
<infinity> Laney: auto-accept is meant to be "the stuff people probably don't care about specifically", hence !packagesets.
<Laney> Why does the release team care that I care about pinta?
<infinity> Laney: It's a rough guess, erring on the side of caution.
<infinity> Laney: Generally, if someone cared enough to add something to a packageset, they should care enough to give it an extra level of review before release.
<arges> infinity: hey. can you approve the bash update 4.3-9ubuntu2 ? it has that security fix and seems to be held in -proposed
<Riddell> infinity: do you know how I can get Kubuntu Plasma 5 on the beta2 iso testing page?
<infinity> Riddell: Ask stgraber nicely, the ISO tracker is a mystery to me.
 * Riddell bats eyelids at stgraber 
<infinity> arges: There's another upload coming anyway, but we can let it through if people are panicking about their unsupported development system having a security bug for a day.
<Riddell> anyway, beta 2 is good for kubuntu and kubuntu-plasma5
<infinity> Riddell: Oh, hrm, I never built plasma5 images, I guess you were testing the previous day's dailies.
<infinity> Riddell: I suppose the only major change there was a kernel bump, if you're happy with what you tested, meh.
<Riddell> I didn't notice any problems, anything specific in that kernel bump?
<infinity> Riddell: Just your usual march of kernel uploady progress.
<stgraber> Riddell: I suspect it's just not on the manifest, let me check
<stgraber> hmm, no, it is...
<infinity> stgraber: It could be on the manifest, but since I never rebuilt the images, it never would have landed.
<infinity> ie: All my fault.
<stgraber> infinity: ah, yeah, that'd certainly explain it :)
<infinity> (I didn't realise plasma5 was in the releasy set)
<stgraber> Riddell: blame infinity :)
 * infinity feels adequately blamed.
 * Riddell finds himself in a maze of twisty blame corridors all alike
<infinity> Riddell: So I'm well-informed for next month, do you intend to *release* -plasma5 as well, or were you just doing milestones to keep tabs on progress?
<Riddell> infinity: yes we'd like a release
<infinity> Riddell: Alright, good to know. :)
<Riddell> we will but appropriately large "tech preview, don't expect any suport" labels all over it
<wxl> infinity arges is this for 14.10?
<infinity> wxl: "this"?
<infinity> wxl: Oh, bash?  Yeah.
<wxl> infinity: yep, cool, thx. :)
<stgraber> Riddell: do you want to release the current image (September 22)? if so, I can copy that over to beta-2
<Riddell> stgraber: yeah
<stgraber> infinity: note that the naming of the plasma 5 image makes publish-image-set very unhappy (either it'll refuse to print you anything or it'll just crash)
<infinity> stgraber: You didn't fix that when doing B1?
<infinity> stgraber: I'll fix it when it explodes, then.
<arges> wxl: yea
<wxl> infinity arges is there a bug related to this that i can watch?
<infinity> Oddly enough, I don't see one.
<wxl> arges: sounds like you got a job to do :) ^
<infinity> Oh, but this is the bug for the new upload that hasn't happened: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1373781
<ubot2> Launchpad bug 1373781 in bash (Ubuntu) "bash incomplete fix for CVE-2014-6271" [Undecided,Confirmed]
<infinity> wxl: Not sure how that would be arges's job.
 * arges is googling for the CVE it exists somewhere
<wxl> infinity: he brought attentiopn to it, so ;)
<arges> https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1373688
<ubot2> Launchpad bug 1373688 in bash (Ubuntu) "Bash Code Injection Vulnerability via Specially Crafted Environment Variables" [Undecided,Fix released]
<infinity> wxl: Yeah, I think mdeslaur must have slipped him something under the table.
<arges> wxl: ^^
<wxl> heheheh
<wxl> thanks guys!
<stgraber> infinity: no, I just did things manually for beta-1
<stgraber> infinity: I didn't find a good way to fix the script because the problem is that the product name is just wrong :)
<infinity> stgraber: Which?  kubuntu-plasma5, or some pretty name?
<stgraber> infinity: I can quickly fix it now though. We need to rename the product on the tracker from "Kubuntu Plasma 5 <arch>" to "Kubuntu Plasma 5 Desktop <arch>" so it matches our regexp a bit better, then update the list on cdimage to match and then add it to the regexp in the script
<infinity> stgraber: Ahh, so the silly pretty names.  Check.
<stgraber> yeah
<infinity> stgraber: If you know what needs fixing, please fix so it's not a panick in a month.
<infinity> Or a panic.
<stgraber> doing
<stgraber> Riddell: go file some results :)
<stgraber> tracker and nusakan updated for the name fix, now looking at ubuntu-archive-tools
<stgraber> Riddell: I'm going to mark plasma-5 ready for a few minutes so I can test my fix
<Riddell> stgraber: it's ready, I'm done testing
<Riddell> so just keep it marked ready
<stgraber> ok
<stgraber> infinity: publish-image-set fixed and tested
<infinity> Shiny.
<stgraber> infinity: oh, and one thing I've been working on lately is making sure we've got two contacts for each product on http://iso.qa.ubuntu.com/qatracker/series/43/manifest, I suspect there are a bunch more (Canonical flavors) that need updating, let me know if you see some of those and know who should be the right sign-off contacts
<stgraber> that should save us some time on release week too
<stgraber> looking at it, I think we need some updates to netboot, desktop, core and server
<infinity> stgraber: Well, netboot/armhf has a contact that no longer works for us, nor is involved in the community. ;)
<stgraber> zequence: do you have any fallback contact for ubuntu studio sign-off when you're not around?
<infinity> stgraber: core is a joke, and I can always test and sign off on all of them.
<infinity> stgraber: And netboot, despite being in the "manifest" isn't something we'd ever not ship.
<stgraber> infinity: yeah, netboot is basically, we need someone to confirm that d-i isn't busted in the archive (out of sync with kernels or the like)
<infinity> stgraber: (ie: it's a mistake based on misunderstanding of other people that it was ever in a go/no-go ship manifest)
<infinity> stgraber: Anyhow, I think it's realistic to make the responsible parties for netboot be the usual d-i upload suspects.
<stgraber> but yeah, we can't not release it, but it's something we need to confirm is good before we release, so might as well be on the checklist
<infinity> stgraber: We can hunt down QA people for answers on what they've tested, but ultimately it'd be me, Colin, et al who make the call if it's busted or not.
<infinity> stgraber: It was always a complete fiction that the other people listed there were in any way signing off on it. :P
<stgraber> infinity: ok, so I'll update all of core to be you and Steve as a fallback and all of the netboot to be you and Colin as fallback
<infinity> stgraber: For bonus points, can those names be hyperlinks to LP accounts, in case someone's not on IRC and I want to throw email at them?
<infinity> A hypothetical me, there, I think *I* know how to email everyone on that list, but I doubt that's universally true.
<stgraber> infinity: maybe, I don't know if I do any kind of html stripping in that field :)
<zequence> stgraber: Not currently, no
<stgraber> zequence: is that something you think you can change or do you really want to be the only one in control of studio sign-off for release?
<stgraber> willcooke: hey there, I assume you're the new sign-off for Ubuntu Desktop, can you nominate a fallback too?
<willcooke> stgraber, seb128 is the natural choice
<stgraber> willcooke: ok, thanks
<willcooke> np
<stgraber> jamespage: heya, you're the current sign-off for Ubuntu Server. Is that still accurate? if so, I'd need the name for a fallback, if that's not accurate, I'll need two names :)
<infinity> Dangit, have we still not killed amd64+mac server images?
<jamespage> stgraber, smoser, gaughen or me
<infinity> We should do that.
<jamespage> stgraber, that covers most timezones
<jamespage> apart from apac
<infinity> jamespage: We're civilised people who would never release at, say, midnight Hawaii time, so you're safe.
 * infinity whistles.
<stgraber> jamespage: ok, I'll like gaughen / smoser / jamespage for the contact order, that matches what we do for the other Canonical flavors (manager / techlead / timezone fallback) :)
<Laney> TZ=Pacific/Johnston mutt
<stgraber> hmm, not sure what my brain was doing there :)
<stgraber> s/like/put/
<Laney> that was my mutt invocation for alpha 2
<gaughen> works for me stgraber
<stgraber> infinity: there we go, the manifest is now all shiny. The only SPOF we have there is zequence, hopefully he'll find a fallback soon or will make sure to stay awake for the whole release day :)
<infinity> Laney: I did one on Honolulu time, which is the same thing, apparently. ;)
<infinity> stgraber: I have every confidence in zequence not letting us down.
<infinity> zequence: Please avoid crossing streets anywhere near busses.
<zequence> I'm probably too crazy in traffic to be trusted with this responsibility
<jdstrand> where are the release notes for utopic? I looked here https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes (doesn't exist) and https://wiki.ubuntu.com/Releases (no link)
<stgraber> beta 2 is usually the first milestone to ship using the central release notes page, so my guess is that nobody created it yet
<jdstrand> i see
<infinity> jdstrand: did you just volunteer?
<jdstrand> I can
<infinity> jdstrand: (Not astually as hard as it sounds, copy and paste from Trusty, empty 99% of it out, add the two things you cared about, done)
<jdstrand> yeah, that is what I figured
<infinity> jdstrand: I'd love the help, if you'd like to be helpful. :)
<jdstrand> sure, I'll do it
<infinity> \o/
<jdstrand> it is almost the least I could do
<infinity> I shall go find breakfast, or whatever meal it is when you haven't slept since yesterday morning.
<mdeslaur> infinity: crack an egg into a red bull
<infinity> mdeslaur: That sounds like death in a cup.
<mdeslaur> infinity: make sure your will is up-to-date
 * ogra_ wonders when ben collins managed to conquer mdeslaur's IRC nick
<ogra_> ah, wait, that would be an egg in redbull inside a beer
<mdeslaur> oh wow, people actually do that?
<mdeslaur> without having a heart attack?
<ogra_> ben does the most dangerous combos, yeah
<ogra_> you might get a heart attack, but since you also get a blackout you wont remember ... so no worries
<mdeslaur> lol
<jdstrand> infinity: ok, https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes and https://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes points to it
<jdstrand> meh
<jdstrand> infinity: https://wiki.ubuntu.com/Releases points to it
<infinity> \o/
<infinity> I'm going to watch some breakfast while I eat my TV, and then give that a once-over while I wait for a bit more testing to roll in, then we should be releasy soonish.
<zequence> Had a corrupted iso before, which held me back a  bit. I should be ready within an hour with the last Studio testing
<elfy> zequence: you want me to do anything?
<elfy> not doing anymore xubuntu stuff at this stage
<zequence> elfy: That's ok. I'm just about to test the final iso
<elfy> ok
<elfy> infinity: so I assume Mark as Ready - even though the lightdm/or whatever in vm issue
<infinity> elfy: Yeah, we're going to ignore that issue and fix it ASAP after the beta.
<elfy> infinity: okey doke
<zequence> stgraber: No one else is currently both active and even faintly knowledgable, but I do agree that it would be good if there were someone who could step in
<zequence> Anyway, I'm finally done testing.
<bdmurray> Could an SRU team member look at releasing aptdaemon in trusty - bug 1324833?
<ubot2> bug 1324833 in aptdaemon (Ubuntu Trusty) "crash handler does not include package version" [High,Fix committed] https://launchpad.net/bugs/1324833
<bdmurray> arges: maybe you could look at releasing aptdaemon to trusty-updates?
<arges> bdmurray: sure one second
<arges> bdmurray: ok done.
<jibel> infinity, apart the broken boot menu, the plymouth issue and a network driver issue, ubuntu desktop looks okay-ish.
<jibel> network driver on mac only
<infinity> Network driver issue?  I missed that one.
<jibel> infinity, dave had problems installing bcmwl
<infinity> wxl: How's lubuntu looking?
<davmor2> infinity: on mac I select 3rd party drivers but get no wifi post install
<infinity> davmor2: Fun.  Kay.  Didn't see a bug linked from the tracker for that.  I assume you filed one, though?
<wxl> infinity: gimme a sec it's been a busy day :/
<davmor2> infinity: no was confirming it with another install filing it now, I'm assuming it is ubiquity right?
<infinity> davmor2: Probably not, but that'll do for a placeholder while we try to decide who's really at fault.
<infinity> davmor2: Please grab installer logs, etc, since we might be debugging blind.
<wxl> infinity: are we calling things confirmed despite https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1371651 ? :)
<ubot2> Launchpad bug 1371651 in plymouth (Ubuntu) "Daily does not boot into graphical interface after installation" [Critical,Triaged]
<wxl> s/confirmed/ready/
<jibel> wxl, yes, we'll ignore it this time and fix ASAP after beta
<elfy> apw: just tried the ppa for that - not working for me here - commented in bug
<wxl> so i'd like to ask someone's advice on this: i have a couple partially tested images that worked fine for beta 1. should i call them good? apparently we had plenty of ppc testers but not so much elsewhere :( speaking of ppc, it doesn't boot on 32 and is untested from what i know on 64, so i'm not calling it ready
<infinity> wxl: If it was untested on 64-bit entirely then yeah, it shouldn't be released.
<infinity> wxl: We'll have it fixed on 32-bit tomorrow, so people can test on their G4s again.
<wxl> infinity: but like amd64 and i386 are not fully tested for all testcases. i'm inclined to call it good, since beta1 was fine, but that may be an error of judgement. that's really waht i need some advice on.
<infinity> wxl: As for "partially tested", the bare minimum that I figure a flavour needs to do is "boot, install, reboot -- computer didn't explode".  I'll release anything in that state, if you ask me to, the rest of the bugs are yours.
<elfy> lol
<wxl> yeah :/
<knome> pretty much agree with that.
<elfy> from my point of view I am happy that the bugs we've got aren't ours to fix :)
<infinity> wxl: Basically, beyond "it boots and installs stuff and doesn't actively harm users", I leave further discretion to the flavour leads about the quality they want or care about in their releases.
<wxl> someone is running a testcase on amd64 now
 * wxl facepalms
<wxl> amd64 is the real bummer since there is no alternate testing of any kind and the only passed testcase is the for live session
<wxl> i guess i can't call it ready
<wxl> so i guess i'm done infinity :(
<infinity> wxl: You've got time, I'm still wrangling paperwork and source CDs.
<wxl> infinity: how much time?
<infinity> wxl: Find a guinea pig to smoketest your amd64 alternate in the next hour. ;)
<infinity> (or two)
<cjwatson> That's loads of time, for the warty preview I smoketested amd64/i386/powerpc in I think 30 minutes end to end :)
<cjwatson> From end of image production
<wxl> cjwatson: hey we can't ALL be cool as you :)
<jibel> wxl, what do you want to test, lubuntu alternate amd64?
<cjwatson> that was ten years ago, I was just a guy with too many computers in his bedroom
<cjwatson> not the international man of mystery I am now
<wxl> jibel: yes that would be a great start thank you
<knome> you mean you are still the same guy, but covered in the fog of mystery? ;)
<jibel> wxl, okay, syncing
<wxl> thank you
<cjwatson> knome: some kind of fog anyway
<knome> hehe :)
<davmor2> infinity: bug #1374126 do you need anything else? I added the installer syslog
<ubot2> bug 1374126 in ubiquity (Ubuntu) "mac is not installing bcmwl even though 3rd party drivers is selected" [Undecided,New] https://launchpad.net/bugs/1374126
<davmor2> battery dying no charger nearby arrrggghhh I hate having to pack my office
<knome> davmor2, let me fix that for you... s/having to pack//
<knome> :]
<davmor2> knome: the council is our landlord they are rewiring our property as well as ripping out and refitting the bathroom and kitchen, we've been packing for the lst 2 weeks they start tomorrow my office is last cause I still need to work tomorrow, not fun :)
<knome> yeah... i work from home too, and i know moving isn't fun
<knome> or any kind of thing that stops you from working
<jibel> wxl, I tried a default installation and lvm/encrypted both went fine but the password I set it not recognized after installation which is really weird. also the plymouth issue is really annoying for the user don't see the password field in the boot screen
<jibel> wxl, digging why it rejects my password
<wxl> hm
<balloons> jibel, are you running through the server tests atm?
<balloons> if so, MAAS shouldn't be in there
<balloons> let me remove it
<jibel> balloons, I'm doing some smoketests of lubuntu
<jibel> wxl, lubuntu alternate amd64 guided and encryption tests case are okay. I don't know why it didn't work with a French keyboard layout though.
<jibel> *test cases
<jibel> and entire disk passed too
<wxl> jibel: thanks i'll call them good
<wxl> also it looks like someone finished the desktop testcase
<wxl> admittedly for manual paritioning :/ but i think i'll call it good
<wxl> ok release notes done, email ready to be sent; i await your command infinity
<wxl> are we ready to release yet?
<bdmurray> slangasek: Could you fully phased aptdaemon in trusty-updates?
<bdmurray> slangasek: there were regressions detected because aptdaemon crashes didn't used to include the version number...
<slangasek> bdmurray: done
#ubuntu-release 2014-09-26
<infinity> wxl: Getting there.
<knome> i guess i'm the only one around who could push the xubuntu announcement to our website, and i'm about to hit the bed
<wxl> infinity: no worries, just checking
<knome> so our announcement will most probably be a tad late :)
<wxl> hehe
<infinity> knome: Announcements matching reality is probably not critical. ;)
<knome> not really, but just FYI, if somebody wonders what's going on
<wxl> knome: just stay out of ubuntu+1 :)
<infinity> wxl: So, skipping ppc entirely, despite the tests that claim to have been done?
<infinity> Oh, done but all failed because it didn't boot. :P
<infinity> Nevermind.
<wxl> infinity: i know they're only 32 bit
<infinity> Skipping away.
 * wxl nods
<mdeslaur> can someone please reject 4.3-9ubuntu3 from the queue, please
<mdeslaur> sorry, bash 4.3-9ubuntu3
<infinity> mdeslaur: With pleasure.
<mdeslaur> infinity: thanks
<infinity> mdeslaur: Yet another fix needed?
<mdeslaur> infinity: build issue, bison isn't regenerating the file from the patched source because of a timestamp issue
<infinity> mdeslaur: Whoops.
<mdeslaur> infinity: what's the filesystem used on the builders?
<infinity> mdeslaur: ext3/ext4, depending (so, yes, some might not have micro-second timestamps, if that's your issue)
<mdeslaur> yeah, I've hit that a couple times
<infinity> mdeslaur: The vast majority are ext4 at this point, but that's not something one should rely on (and I consider it a bug if a build system needs precision timestamps anyway, since it rules out building on a lot of filesystems)
 * mdeslaur nods
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Beta 2 | Archive: Feature Freeze | Utopic 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
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.1, Utopic Beta 2 | Archive: Feature Freeze | Utopic 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
<wxl> yay we're released
<lool> would a RT member mind reviewing and releasing network-manager from unapproved? it brings wifi scan fixes that we need in RTM for the wifi based positioning
<Laney> I assumed we'd unfreeze
<Laney> Not?
<apw> Laney, we have nominally remained in hard freeze from beta to final so that things in main get extra review (iirc)
<apw> (final beta)
<Laney> Maybe, I forgot what we did last time
<apw> that is my memory, i don
<apw> don't think it is intended to imply a higher bar, just more care being applied
<Laney> I know
<Laney> lool: no patch headers, bug reference or description of the problem being solved :( - forwarded upstream?
<infinity> Laney: Can you hunt down the uploader of that gtk+3.0 and investigate if it breaks ABI?
<infinity> Laney: At a glance, it looks like it's altering argument counts for at least one non-static function (but that might just be hard to read right in the diff context), which would need at best a symbol version bump, at worst, a new SOVER.
<infinity> Laney: (I'd do the hunting myself, but I should be asleep, and need to be up again in ~4h)
<infinity> Laney: Actually, I'm going to reject it, pending further investigation, just in case.  But please do hunt down said person and see about investigating properly.
<lool> Laney: yes, this was discussed with upstream
<lool> cyphermox: ^ do you have upstream references for the NM changes?
<cyphermox> ha?
<cyphermox> it was on IRC, really
<cyphermox> we came up with a solution that was proposed to dcbw, and we all mutually agreed this was what was required
<cyphermox> I'm not sure tvoss posted the patch yet
<cyphermox> perhaps I'll just go ahead and ship it to the mailing list now
<Laney> I picture it disappearing into the void
<cyphermox> Laney: ?
<Laney> If not forwarded upstream
<lool> cyphermox: can we open a bugzilla ticket with the patch?
<cyphermox> sure can
<lool> thanks
<Laney> would it be bad to reupload with the reference?
<Laney> or, I guess there's a VCS?
<Laney> infinity: Okay, I'll see in a minute
<cyphermox> it will be in ~network-manager/network-manager/ubuntu shortly
<Laney> seb128: ^? did you upload gtk by any chance?
<lool> Laney: this is fairly urgent I'm afraid
<Laney> Isn't it always :)
<lool> eh
<Laney> I accepted it - please update the VCS with the appropriate headers
<lool> thanks
<lool> cyphermox: ^ if you dont mind
<seb128> Laney, yes I did for printing/cred, why?
<seb128> shouldn't be an abi change, it's in the printing code which is used only by gtk itself
<seb128> that's a backport from gtk 3.13
<infinity> seb128: Can you double-check it doesn't affect any exported functions?
<Laney> It seems from first glance to change the signature of exported symbols
<infinity> seb128: The diff sure made it look like it might.
<seb128> k
<seb128> sorry I have to go, I can do that this afternoon
<seb128> I just sponsored a backport of an upstream commit
<seb128> that change is in debian unstable btw and they didn't change anything afaik
<seb128> but I can check later
<infinity> seb128: At first glance, it only looks like added args, so wouldn't be an ABI break, just an ABI progression (ie: need symbols min versions updated), but I could also just not be getting enough context.
<seb128> that's not an external symbol afaik
<seb128> the print module is just used by gtk itself
<infinity> seb128: "just used by gtk itself" is a statement, not necessarily a reality.  If the symbols are public symbols in an object we ship, and that object has an ABI, it has a contract.
<infinity> Unless it's a plugin that literally only GTK *can* load.
<seb128> ok, discard it, I don't care
<infinity> Anyhow, just have a check sometime.  If my glance was wrong, cool, we can accept from rejected.
<seb128> well, I fail to see what outside gtk would load the gtk print dialog
<seb128> but I don't have the slots to do work on that, I though it would be a no issue change
<seb128> so if it's not let's drop it
<ogra_> could someone unembargo the hud package from unaccepted ?
<ogra_> (i need it for a pending fix)
<infinity> (base)adconrad@cthulhu:~$ nm -D /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1200.2 | grep gtk_print_backend_set_password
<infinity> 0000000000318bd0 T gtk_print_backend_set_password
<infinity> seelaman: FWIW, definitely not in a plugin.
<infinity> Err.
<infinity> seb left.  Bah.
<cjwatson> infinity: Any reason I shouldn't start working my way through the queue?
<rbasak> bcache-tools has in the Utopic NEW queue for a while now, if you have time to look at that.
<rbasak> (please)
<cjwatson> oh I was talking about unapproved, new is a different headspace ...
<infinity> cjwatson: Work away.
<infinity> cjwatson: Fairly sure you can ignore half of it (all the KDE stuff), which I expect Riddell/ScottK to get to soon.
<infinity> cjwatson: But all the pending syncs probably want love.
<infinity> (and oh, how we all love reviewing syncs)
<infinity> cjwatson: Though, if you're, y'know, bored for a few minutes, getting to the bottom of the grub2/ppc64el breakage (or reverting to the cross-build hack for now) would be nice.
<infinity> Not that I ever verified that it didn't work, I just took your word for it and didn't release that ISO.
<cjwatson> infinity: There were patches on grub-devel this morning which I'm going to apply
<cjwatson> Well, not for the nvram bit
<infinity> cjwatson: I haven't looked at how it works now.  It's still building a 32eb binary, right, just using the native toolchain?
<cjwatson> But at least for the VSX chaos
<cjwatson> RIght
<infinity> cjwatson: Kay.  When you think it's all fixed, I should try it on my old PowerStation, to make sure it's happy on old very big-endian-only kit.
<infinity> Though testing on a POWER3/4/5 would be ideal, since that also rules out accidental AltiVec leakage too.  But what are the odds?
<infinity> Oh, except testing it on my machine would mean manually extracting the binary from the ppc64el package.  That's a bit of a pain.
<infinity> Alright, I'm giving up on the fiction that I'll be able to sleep between now and when the exterminators come to tear apart my apartment.
 * cjwatson raises eyebrows at queuebot
<cjwatson> infinity: I've reviewed all the syncs in the queue with the exception of libav, which I requested.
<lool> hey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows network-manager has been waiting for autopkgtests "in progress", but it's been 3 britney passes that they are finished and green in jenkins
<lool> it looks like britney is not getting the right status from the tests
<cjwatson> film at 11
<rbasak> Could this be anything to do with the recent maintenance?
<cjwatson> unlikely
<cjwatson> it's just broken sometimes
<cjwatson> that said
<cjwatson> when I go to the "private" link for friends, the job is apparently still running
<lool> the public one has a recent date and is finished
<cjwatson> though not the n-m one
<lool> ah friends
<cjwatson> the public one is basically just informational
<cjwatson> the relevant status file on snakefruit is dated a bit over an hour ago ...
<cjwatson> but screw it, I'll just force it
<cjwatson> don't have time for subtlety
<cjwatson> hint committed
<lool> in other news, I intend to do a source + binary copy of qtubuntu-sensors ubuntu2 from ubuntu-rtm to ubuntu as ubuntu as an ubuntu1 source with the same contents, but that's a lower version
<lool> it might end up in unapproved
<cjwatson> don't need to tell us in advance, we'll be notified
<davmor2> cjwatson 's been committed man we need a plan to break him like they did with murdoch......I love it when a plan comes together.
<cjwatson> infinity: I just realised - the dubious ppc64el changes in grub2 never made it into utopic, because I forgot to do grub2-signed
<cjwatson> infinity: so final beta might be bootable on ppc64el after all ...
<oSoMoN> hey release team, if I can do anything to help approve webbrowser-app quickly, let me know (this landing only has unintrusive bug fixes, and needless to say, has been thoroughly tested)
<cjwatson> oSoMoN: it's ok, we're reasonably on top of the queue at the moment
<oSoMoN> cool :)
<infinity> cjwatson: Oh.  I guess I should have actually looked into it and tested instead of taking you at your word.  I guess I could still test that image and release it before it gets culled.
<cjwatson> infinity: might be a plan, yeah
<cjwatson> sorry for misinormation
<cjwatson> +f
<oSoMoN> that was fast indeed, thanks :)
<infinity> cjwatson: In that case, please don't re-enable dailies, I'll get to testing today/tomorrow.
<cjwatson> ok
<infinity> I guess I could chattr that daily so it can't go away. :P
<infinity> Probably a bit unfriendly.
<cjwatson> or just hack cdimage/etc/purge-days
<cjwatson> cowboy "ubuntu-server 10" in there for a while or something
<infinity> cjwatson: Oh, yeah, I've done that in the past.
<infinity> Done.
<cjwatson> infinity: doesn't appear to be bootable on snyder.  Of course, the latest debian-installer was built against the broken grub-ieee1275-bin
<infinity> cjwatson: Oh, of course it was, cause it was built in proposed.
<infinity> cjwatson: So, the migration status is meaningless.
<infinity> Also, this is an argument for me adding exact (= ) deps to d-i's output.
<infinity> Have britney enforce a rebuild any time anything it was built with changes.
<infinity> Or implement Built-Using, fill it in properly, and make Britney enforce that.
<infinity> The former is much less effort, though. :)
<infinity> I suppose we can't avoid properly implementing Built-Using forever though, so we should probably do it.
<cjwatson> infinity: ^- could you review that?  I'm aware the pre-existing code is horrible, and I'm flying blind; but I don't think it can make things worse, and apparently the bug reporter is working to a deadline
<cjwatson> infinity: also, can we turn dailies back on now that we know ppc64el was hosed?
<infinity> Laney: Did you triple check that that was the only public symbol that was affected by that patch?
<infinity> cjwatson: Yes to the latter.  Maybe to the former, I'm waiting on exterminators to knock on the door, I can make no promises once they do.
<Laney> Pretty sure. I gave up trying to fiddle with acc to check though
<cjwatson> infinity: ok, I'll go ahead and do the latter.  I'll keep your purge-days cowboy for a bit though
<infinity> cjwatson: Huh.  People partition /dev/mdX?  Weirdoes.
<cjwatson> dmraid apparently
<cjwatson> and yeah that's much what I thought
<cjwatson> maybe a consequence of the new dmraid looking like mdadm thing
<infinity> Oh yeah, it would do.
<infinity> That pattern just gets prettier on every iteration, doesn't it?
<cjwatson> it sure does
<cjwatson> one of these days ...
<infinity> cjwatson: s/hs/hms/ -> lexical order, or subconscious desire to join the navy?
<cjwatson> lexical
<cjwatson> (Ã¢llo c'est l'heure)
<cjwatson> (oh wait I've mangled that, it was "a l'eau, c'est l'heure")
<infinity> cjwatson: And maybe context would be enlightening, but why does the second block hand vdX, but the first not?
<cjwatson> I would love to know that
<cjwatson> this is in the category of "too scared to fix without extensive testing")
<infinity> Lovely.
<cjwatson> the whole thing needs refactoring
<infinity> With a shotgun behind the shed, yes.
<cjwatson> but to do that safely I have to test it on every device type
 * didrocks learnt today a new way how English people mock French, thanks cjwatson :p
<cjwatson> didrocks: apologies, feel free to mock English
<cjwatson> to be fair I think that was more mocking the navy, but point taken :)
<didrocks> cjwatson: I think I'm doing that everyday butchering the language with all those typos ;)
<didrocks> cjwatson: no worry, was just interestingâ¦ Took me some googling to understand the reference though
<infinity> The English are too easy a target.  It's like kicking a toddler in the face.
<infinity> Except that the toddler's only going to look that way *after* you've kicked him.
<apw> cheek
<jamespage> ^^ point release needed for openstack horizon
<jdstrand> fyi, libvirt has a few libvirt-lxc apparmor policy refinements
<ogra_> that dbus and ubuntu.touch-session need to go in together ^^^^
<Laney> ogra_: you've found everything that expects this old path?
<wxl> are those updates for the bash fix???
<cjwatson> er that's just the dailies
<cjwatson> I don't know why they're showing up as Beta 2
<wxl> i didn't think beta 2 implied dailies
<wxl> ah ok
<cjwatson> I think it's because Beta 2 hasn't been marked as Released in the tracker
<ogra_> Laney, that path was dropped from desktop about one release ago ... thats touch only nowadays
<cjwatson> infinity: ^-
<ogra_> Laney, desktop even used to use it from a different location in home when it still used it
<Laney> what is 'desktop'?
<ogra_> Laney, ubuntu desktop ... that was the original consumer
<ogra_> from years ago
<Laney> I'm not making any distinction like that
<ogra_> Laney, anyway, it is touch only
<jdstrand> that contains ^ apparmor policy updates that were reviewed by upstream and tested by me and the server team
<infinity> cjwatson: Oh, I didn't mark Beta2 as released on the tracker, that's why.
 * infinity tries to remember how to do that.
<infinity> Done.
<cjwatson> ta
<wxl> infinity: your g5 uses dvi?
<infinity> wxl: PowerStation, not G5, but close enough, and yeah, dual DVI.
<wxl> infinity: did you manage to get to the splash screen or did you just check yaboot success/fail the other day?
<infinity> wxl: Hrm?  I didn't test any PPC images (except server on a VM)
<wxl> infinity: ah, ok, nevermind.
<ogra_> Laney, was that Q+A just out of interest or did you plan to unleash dbus ?
<ogra_> hmm, seems he said good night in another channel ...
<ogra_> could someone else please let dbus thought then (else AP/smoke testing on touch will break now that ubuntu-touch-session landed)
<infinity> ogra_: Does it really still need the mkdir there?
<ogra_> hmm, i guess not ... unless it doesnt trust upstart to create it (all apps log there under touch anyway)
<ogra_> its a no-op i guess
<infinity> Kay.
 * ogra_ hugs infinity 
<ogra_> i'll drop that line in a subsequent upload
<ogra_> (for cleanness)
<infinity> ogra_: Well, assuming something else creates it.  Maybe others are relying on it. :P
<ogra_> i'm pretty sure init creates it when it starts the session .. but yeah, i dont mind either way
<Laney> ogra_: I was actually interested in the answer
<Laney> but I just got "it's touch only"
<ogra_> Laney, well, the only other consumer was the hud ... that dropped using it
<stgraber> can somebody pretty please review and accept ^ that's fixing ubuntu touch
<infinity> stgraber: Looking.
<infinity> stgraber: Ew?
<infinity> stgraber: Why aren't packages doing this on install?
<ogra_> infinity, they do ... thats the prob :)
<stgraber> infinity: they assume adduser/useradd will do it for them
<infinity> ... and why isn't it?
<stgraber> infinity: but they don't call adduser/useradd when we already created all the users for them
<infinity> Okay, and why are we creating the users instead of letting the postinsts do it?
<ogra_> infinity, with readonly images (and readonly /etc/passwd) but dynamically assigned UIDs you get a mess
<stgraber> infinity: and we create all of the users and groups ahead of time to avoid misordering on the image which breaks the world when uids and gids suddenly change between images
<ogra_> if your readonly image ships a different UID all your RW bind-mounted dirs owned by that user get messed up
<infinity> Oh, gross.  Okay.
<infinity> Yeah, I get the problem.
<stgraber> infinity: yeah, not too pleased I had to come up with that hack, but the alternative was even worse :)
<stgraber> infinity: (alternative was to detect changes on the device and do some chown all over the place from initrd)
<infinity> stgraber: Yeah, that's not at all viable.
<ogra_> well, androoid just ships a header file with hard mapping of user and group IDs ... you can only change them at compile time
<stgraber> at least now we've got a static list of uid/gid and a second hook which detects additions and fails the build, so we're guaranteed some consistency
<ogra_> (as replacement of any password mechanism)
<infinity> stgraber: Well, I'm not happy with the explanation, but I guess it's the one I'm going to get. :P
<infinity> stgraber: Want to review jdstrand's lxc upload?
<jdstrand> stgraber: (it includes what we agreed to earlier and reviewed by hallyn)
<infinity> I guess this libvirt upload goes with it?  Seems like it relates.
<jdstrand> infinity: it doesn't actually. it is just similar changes for libvirt-lxc
<jdstrand> (they're wholly separate)
<infinity> jdstrand: Not dependencies, but worth reviewing together to make sure the changes seem to match functionality.
<jdstrand> sure
<slangasek> infinity: could you have a look at FFe bug #1374609?
<ubot2> bug 1374609 in perftest (Ubuntu) "[FFe] update perftest to 2.3+0.12.gcb5b746-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/1374609
<jdstrand> stgraber: fyi, the libvirt-lxc changes don't use the more lenient unix (receive) and signal (receive) because these a) each container has its own profile and b) there is no preexisting policy for libvirt-lxc prior to utopic
<jdstrand> stgraber: also, libvirt's control file was updated previously for apparmor
<infinity> 1.2-OFED-1.4.2-2 -> 2.2.0.19-1 -> 2.3+0.12.gcb5b746-1 ... This package sure has some creative versioning.
<infinity> slangasek: No open bugs since it was uploaded (or at all, for that matter, I wonder if it has users?), built everywhere, complete leaf.  Go for it.
<stgraber> jdstrand: yeah, I don't care about libvirt, that's fine to use the more restrictive one there :)
<stgraber> I'll do the review for both
<slangasek> infinity: thanks
#ubuntu-release 2014-09-27
<bluesabre> please reject the above gmusicbrowser, it does more than just fix bugs, I'll file a proper FFe request
<bluesabre> follow-up FFe for above gmusicbrowser... https://bugs.launchpad.net/ubuntu/+source/gmusicbrowser/+bug/1374682
<ubot2> Launchpad bug 1374682 in gmusicbrowser (Ubuntu) "[FFe] gmusicbrowser 1.1.13 for Utopic" [Undecided,New]
<mdeslaur> Could someone please reject bash?
<ogra_> hmm
<ogra_> why doe steh bot not approve that ?
<ogra_> *does the
<cjwatson> because it's in a packageset
<cjwatson> I've accepted it now anyway
<ogra_> thanks
<bluesabre> cjwatson: while you're around, can you reject the gmusicbrowser 1.1.13 upload I erroneously pushed last night?
<cjwatson> sure, done
<bluesabre> thanks :)
<cjwatson> mdeslaur: done
<mdeslaur> cjwatson: thanks
<mdeslaur> cjwatson: can you let that bash through please? ^
<cjwatson> mdeslaur: sure
<mdeslaur> cjwatson: thanks
<cjwatson> would be nice if somebody could summon the fortitude to review my openssl upload and grub2 sync; have people chasing me for both ...
#ubuntu-release 2015-09-21
<flexiondotorg> didrocks, If you have a moment can I ask a favour? Please can you update the ubuntu-mate-meta package?
<didrocks> flexiondotorg: looks good to me, but did you discuss it with the release team to get a FFe or such?
<didrocks> (there is little rationale in the commit message for the seed addition)
<flexiondotorg> didrocks, I haven't because this is new ground. Need some advice.
<flexiondotorg> The packages were updated recently in the archive.
<flexiondotorg> These version are now compatible with Ubuntu MATE.
<flexiondotorg> So, I'd like to include them in Ubuntu MATE.
<flexiondotorg> I wasn't sure if I needed a FFe to add package to Ubuntu MATE that are already in the archive?
<didrocks> flexiondotorg: it's still a new product "feature" (by default). Should be easy to get it acked, but still worth getting a FFe for it
<flexiondotorg> OK
 * flexiondotorg goes to file a bug.
<didrocks> the rationale is "it's easy to get back if we see the feature being really broken and needing to be reverted"
<didrocks> (and so, won't delay the whole Ubuntu release)
<flexiondotorg> didrocks, Thanks for your help. How does this look? - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1497880
<ubot93> Launchpad bug 1497880 in ubuntu-mate-meta (Ubuntu) "[FFe] Please update ubuntu-mate-meta package" [Undecided,New]
<didrocks> flexiondotorg: I guess a rationale about what's the added value for the feature will be appreciated by the release team
<didrocks> otherwise, the rest is good :)
<flexiondotorg> didrocks, Opening post edited accordingly :-)
<didrocks> flexiondotorg: excellent!
<flexiondotorg> didrocks, Can I get an ack on that? ;-)
<didrocks> flexiondotorg: I'm not part of the release team, so get someone from that team :)
<didrocks> (archive admin team/MIR team for me, a little bit different)
<flexiondotorg> didrocks, Ah, sorry. I thought you were.
<flexiondotorg> didrocks, Thanks for helping.
<didrocks> no worry!
<ogra_> would someone be so kind and let linux-raspi2 (and meta) out of NEW  ?
<didrocks> ogra_: happy to review and to ack once the release team acked the FFe
<didrocks> (which should be a one minute thing for new packages :p)
<ogra_> hmm, who does universe approval nowadays ? Laney ?
<Laney> no
<Laney> all of the release team does all packages
<flexiondotorg> didrocks, Can you update ubuntu-mate-meta for me please? I have an "OK" from Laney :-)
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1497880
<didrocks> flexiondotorg: sure, doing!
<ubot93> Launchpad bug 1497880 in ubuntu-mate-meta (Ubuntu) "[FFe] Please update ubuntu-mate-meta package" [Medium,Triaged]
<flexiondotorg> ogra_, I'll be testing that linux-raspi2 stuff this week :-)
<flexiondotorg> didrocks, Thanks.
<didrocks> yw!
<ogra_> flexiondotorg, well, i'd like to release the snappy RPi image today :) the package sits in the queue since 5 days already ... should be ripened enough to move on ;)
<flexiondotorg> ogra_, Great.
<flexiondotorg> ogra_, As you may know we make a build of Ubuntu MATE for the Pi 2.
<ogra_> (i could just pull the binary from the kernel team PPA, snappy doesnt really care, but i'd rather not to if the package moves to the archive soon anway)
<ogra_> flexiondotorg, good luck with that :)
<flexiondotorg> It is the most popular version. More downloads than all other architecture put togther.
 * ogra_ is happy he doesnt have to jump through all these hoops anymore, snappy makes HW support so much easier
<flexiondotorg> Downloaded ~1,000 times per day.
<flexiondotorg> ogra_, When 15.10 is done I really want to invest some time learning Snappy.
<apw> ogra_, hoops that are there to help maintain consistancy and sanity, those being removed is not necessarily a good thing
<ogra_> apw, well, building the device tarball from archive packages keeps that consistency and sanity somehow
<apw> ogra_, and in that case you had to jump the hoops
<ogra_> well, i was more referring to the splitting of software for the system(rootfs) and the hardware (kernel/bootloader)
<ogra_> being able to maintain and upgrade them separately makes porting really a breeze
<flexiondotorg> didrocks, Thanks for ubuntu-mate-meta.
<didrocks> flexiondotorg: yw!
<flexiondotorg> Laney, I've noticed all the ISO images, for all flavours, have grown considerably since 15.10 Beta 1.
<flexiondotorg> About 200MB to 400MB larger.
<flexiondotorg> What is the cause?
<Laney> don't know, sorry
<Laney> Compare the .manifest files and see if anything reveals itself
<flexiondotorg> Laney, I'll investigate.
<Laney> I looked at xubuntu and it seemed to be 1.1G both times
<flexiondotorg> Kubuntu was 1.3 now 1.7
<flexiondotorg> Ubuntu MATE was 1.1 and is now 1.5.
<flexiondotorg> Ubuntu GNOME was 1.1 now 1.5
<Laney> Probably best to investigate rather than check all of the flavours.
<flexiondotorg> Yep, will investigate but just illustrating there is a jump.
<flexiondotorg> Laney, something is pulling in Latex and a heaps of fonts.
<flexiondotorg> I'll find out what.
 * flexiondotorg is zsyncing, which is slow because rural shortware radio internet.
<flexiondotorg> Kubuntu, Ubuntu MATE and Ubuntu GNOME have all aquired the same fonts and latex package since Beta 1.
<flexiondotorg> Lubuntu and Xubuntu are unaffected.
<flexiondotorg> Laney, texlive-full is being pulled in by germinate for Ubuntu MATE, Ubuntu GNOME and Kubuntu. But I can't find a reason why.
<flexiondotorg> Stock Ubuntu is affected also.
<seb128> is that still an issue or was it https://launchpad.net/ubuntu/+source/ghostscript/9.16~dfsg~0-0ubuntu3 ?
<flexiondotorg> seb128, I'm looking at todays germinate log and todays daily images.
<Laney> I don't see it on the pending Ubuntu image
<Laney> which has 0ubuntu3
<Laney> try a respin?
<Laney> seb128: thanks for info
<flexiondotorg> Ubuntu MATE has no-follow-recommends enabled.
<flexiondotorg> So should never have encountered this.
<flexiondotorg> texlive-base is show is being required by every flavour using apt-show.
<flexiondotorg> OK, I'll re-spin.
<davmor2> infinity, cyphermox: Did 15.10 get the "fix" for the broadcom driver again?  I don't see it visible in driver updates on the live session like normal.  I'm running an install to double check if 3rd party drivers installs it
<cyphermox> the "fix" for broadcom?
<davmor2> cyphermox: removal of bcmwl for the free drivers that never actually work seemingly
<cyphermox> davmor2: do you remember the bug for last time? I have no idea what was changed
<davmor2> cyphermox: the issue we had to fix for 14.04 point release
<cyphermox> I'll try to reproduce it from the bug and do ~ the same thing
<davmor2> cyphermox: one second
<cyphermox> ok
<davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1481018
<ubot93> Launchpad bug 1481018 in ubuntu-drivers-common (Ubuntu Trusty) "DELL XPS 13: bcmwl-kernel-source not installed when 3rd party drivers is selected so no wifi and no ethernet port either" [High,Fix released]
<cyphermox> ok, cool
<cyphermox> I'll look at it in a bit
<davmor2> cyphermox: in additional drivers all I see is mircocode firmware for the intel cpu
<cyphermox> ok.
 * cyphermox looks
<davmor2> cyphermox: this is what I get from the live desktop trying to install it http://paste.ubuntu.com/12514642/
<cyphermox> isn't that different though? that's a network issue
<cyphermox> or do you have no network because no wifi?
<flexiondotorg> Laney, After an ISO respin Ubuntu MATE is the correct size again.
<cyphermox> davmor2: to answer your question, the fix is there already
<davmor2> cyphermox: no network because the xps only has wifi, however that has the cd enabled so in theory should install it from there if everything is working correctly
<davmor2> cyphermox: :(
<cyphermox> hm
<davmor2> cyphermox: I wonder if it isn't compatible with the latest kernel
<cyphermox> that's not what it was complaining about though
<cyphermox> can you file a new bug and include /etc/apt/sources.list from the system?
<davmor2> cyphermox: sure
<cyphermox> then try to update and try it again too
<davmor2> cyphermox: I'm going to try putting on the usb key again, I'll also double check there are no issues with hte image too
<cyphermox> seems to me like maybe the CD is not enabled, or we don't have bcmwl on the CD... at least the files look to be on the CD
<cyphermox> maybe it's not so happy when you use USB rather than a real CD?
<davmor2> cyphermox: so MD5sums match so I'll readd it to the usb pendrive
<davmor2> cyphermox: no choice xps13 only has usb ports
<davmor2> cyphermox: and it worked on the 14.04 point release
<cyphermox> ok
<cyphermox> well it didn't seem to try looking on the USB drive at all
<cyphermox> brb,
<davmor2> cyphermox: indeed and that is disturbing
<davmor2> cyphermox: right found it on the pendrive /media/davmor2/Ubuntu 15.10 amd64/pool/restricted/b/bcmwl/bcmwl-kernel-source_6.30.223.248+bdcom-0ubuntu4.1_amd64.deb so it is there so I will retry with this fresh image
<davmor2> cyphermox: and still not showing up
<flocculant> infinity: you got any idea what sort of time the images will be frozen for beta tomorrow ?
<davmor2> cyphermox: so I have a screenshot of what I see, the apt/sources.list anything else I need to drop onto usb key to copy it over here?
<infinity> flocculant: Oh, look at that, I'm doing a beta this week.  Whee.  I'll have to get my ducks in a row and sort that out today.
<flocculant> :)
<ogra_> infinity, is there a chnce i could get the rpi kernel package out of the new queue soon ?
<infinity> ogra_: It needs a proper review for potential copyright issues, etc.  I'll try to get to it today during sessions.
<ogra_> cool., thanks !
<ogra_> (i think it is the same source as -generic, just different config, not 100% sure though, rtg will know)
<rtg> ogra_, nope, it is only based on our kernel sources, but there are a bunch of patches on top,
<ogra_> ah
<infinity> ogra_: Yeah, if it was the same source, it wouldn't be a new source package.
<ogra_> indeed
<infinity> rtg: If that's based on master + patches, can it have an identical orig to master, instead of being native?
<infinity> rtg: Pretty please?
<infinity> rtg: Makes it 1000% easier to immediately see the delta without involving git.
<rtg> infinity, sure, wanna reject while I re-upload ?
<infinity> rtg: (This is how we do keystone)
<infinity> rtg: Yeahp.
<infinity> rtg: It also shouldn't need the weird large int ABI number.  I thought we fixed everywhere where those conflict and made that necessary.
<infinity> apw: ^
<infinity> Yeah, everything it produces has the flavour in the name, so no need for the weird ABI.
<apw> as long as it has its own flavour number
<infinity> (Not that it matters either.
<rtg> infinity, I didn't really study the version too closely since ppisati did the original packaging. it seemed to work.
<infinity> )
<infinity> apw: The reason for it used to be because we produced an unflavoured linux-headers-common from every flavour, and they conflicted.
<infinity> apw: But now linux-headers-flavour depends on linux-flavour-headers (which isn't confusing naming at all), so the ABI conflict is gone.
<apw> infinity, right indeed, and now its <srcpackge>-headers
<apw> infinity, that sounds wrong
<infinity> rtg: Anyhow, it works either way, and I don't really care.  But I'll reject for the lack of orig.
<apw> infinity, its not flavour, its <srcpkgname>-headers ... whcih just happens to look like the flavour
<infinity> apw: Nah, it's not wrong, just the way I described it is wrong (it's src-headers, indeed, which just happens to be linux-flavour-headers in a single-flavour source)
<apw> as it is common to all flavours in the package
<infinity> apw: Jinx.
<apw> mmmmmmmm mm mmm
 * rtg repackages with an orig tarball...
<infinity> rtg: Identical orig (hardlinking is love) to master, please.
<davmor2> infinity, cyphermox: filed it against bcmwl even though it is some other system. https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1498074
<ubot93> Launchpad bug 1498074 in bcmwl (Ubuntu) "Package is not being installed if you install from a usb pendrive created from disks" [Undecided,New]
<rtg> infinity, raspi2 is back in the NEW queue
<davmor2> infinity: cyphermox: oh interesting, the intel microcode that I have as an option it install is in the same restricted folder as the bcmwl driver
<davmor2> so now I have no idea why the bcmwl driver isn't available
<infinity> davmor2: Define "available".  apt can't find it, or ubuntu-drivers doesn't tell you you need it?
<davmor2> infinity: if I try and install it from the cli it says that it can't access the repos and ignores the cdrom (usb pendrive pretending to be the cdrom) I haven't look at what ubuntu-drivers says is there a command for that
<davmor2> infinity: sudo ubuntu-drivers list just shows intel-microcode
<infinity> davmor2: Okay, but if "apt-get instlal blah" doesn't work, that could be why ubuntu-drivers isn't showing it (since it builds the list based on the intersection of your hardware, internal blacklists, and what's in the apt cache).
<davmor2> infinity: if I do apt search bcmwl-kernel-source that appears
<infinity> davmor2: But apt-get install bcmwl-kernel-source does...?
<davmor2> http://paste.ubuntu.com/12514642/
<infinity> davmor2: apt-cache policy bcmwl-kernel-source
<davmor2> infinity: version in the repos is newer than the version on the cd
<infinity> davmor2: Okay, so that's an ISO building oops.
<infinity> davmor2: It'll solve itself (or I'll hit it with a hammer).
<davmor2> infinity: repos 0ubuntu5 and iso is 0ubuntu4.1
<infinity> davmor2: Yeah, we hit the hilarious locking bug where the ftp mirror on cdimage hasn't updated for a few days.
<infinity> davmor2: So the livefs is up-to-date, but the packages in /pool/ on the ISO are a few days out.
 * infinity fixes.
<davmor2> infinity: nice
<davmor2> infinity: so basically try again tomorrow
<infinity> Yeah.  Unless you're keen on testing sooner, I can force the issue.
<davmor2> infinity: It's 18:00 now I finish around 20:00 how long would new images take?
<infinity> davmor2: Probably faster than that, but tomorrow makes more sense.
<davmor2> infinity: iso will be my main priority for the next few days and in particular the xps 13 so I'll hit it with a big hammer tomorrow
#ubuntu-release 2015-09-22
<zequence> Hi. Ubuntu Studio ISOs have not been building for a while. I don't really know from which end to start looking. Could someone please assist?
<zequence> https://lists.ubuntu.com/archives/ubuntu-studio-devel/2015-September/006879.html
<zequence> There's the error report.
<zequence> Seems there's a problem with python-enum
<zequence> Ah, I just tried upgrading, and upgrading python-enum would remove a bunch of packages.
<zequence> For some reason it is now conflicting with python-enum34, which it wasn't before. I'll check it out
<flexiondotorg> Riddell, May I ask a favour? Please could you sponsor this upload for me? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1498340
<ubot93> Launchpad bug 1498340 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.4 bugfix release [debdiff attached]" [Undecided,New]
<zequence> Could someone move ubuntustudio-meta to the wily main archive. It's sitting in proposed, and will fix our ISO build issue. Bug 1498345
<ubot93> bug 1498345 in ubuntustudio-meta (Ubuntu) "python-enum conflict with python-enum34 causing havoc" [Critical,New] https://launchpad.net/bugs/1498345
<Laney> zequence: You need to wait for proposed-migration to do its thing
<zequence> Laney: Does that happen quickly?
<zequence> 24h is good enough for me. Don't know much about what happens after I do an upload.
<Laney> https://wiki.ubuntu.com/ProposedMigration/
<Laney> If no problems then a couple of hours, otherwise however long it takes to fix them
<zequence> Laney: Thanks :)
<davmor2> cyphermox, infinity: :( https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1498074 archive sync didn't fix it :'(  still only showing the intel-microcode,  I'll try it on macbook and see if that is the same if it is then I can open it up via ssh hopefully
<ubot93> Launchpad bug 1498074 in bcmwl (Ubuntu) "Package is not being installed if you install from a usb pendrive created from disks" [Undecided,New]
<flexiondotorg> didrocks, Do you have the time to sponsor a couple of uploads?
<didrocks> flexiondotorg: not really, better to add to the sponsoring queue I think
<flexiondotorg> didrocks, Yep, have done.
<flexiondotorg> Really wanted to squeeze these in before the next beta.
<flexiondotorg> I'll ask around :-)
<flexiondotorg> infinity, When will the beta iso image get made?
<tjaalton> could someone from the release team ACK/NAK https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279
<ubot93> Launchpad bug 1484279 in mesa (Ubuntu) "[FFe] Mesa 11.0.0" [Medium,Confirmed]
<Riddell> flexiondotorg: uploaded!
<flexiondotorg> Riddell, Thanks.
<flexiondotorg> Riddell, Do you have time for a couple more?
<Riddell> flexiondotorg: and rejected! "File ubuntu-mate-settings_15.10.4.tar.xz already exists in Primary Archive for Ubuntu, but uploaded version has different contents"
<Riddell> flexiondotorg: could do
<ogra_> didrocks, how about that linux-(meta-)raspi2 kernel now (it is actually in binary NEW now)
<flexiondotorg> Riddell, I'll check u-m-settings.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/galculator/+bug/1498439
<ubot93> Launchpad bug 1498439 in galculator (Ubuntu) "Sync galculator 2.1.4-1 (universe) from Debian unstable (main)" [Undecided,Fix released]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1498415
<ubot93> Launchpad bug 1498415 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 15.10.4 bugfix nelease [debdiff attached]" [Undecided,New]
<Riddell> flexiondotorg: how come you can't do this yourself?
<flexiondotorg> Riddell, I'm not blessed with upload priviledges.
<flexiondotorg> I'm going to apply after 15.10 is out.
<flexiondotorg> For PPU.
<Riddell> flexiondotorg: and nobody else from xubuntu is? I'm just mindful you could be a malitious hacker using my trusting nature to upload root kits
<flexiondotorg> I'm from Ubuntu MATE.
<Riddell> ah yes sorry
<flexiondotorg> We have no uploaders.
<flexiondotorg> We do most of the packaging via Debian and sync.
<flexiondotorg> We have 2 DDs for MATE in Debian who do the uploading.
<Riddell> clever
<flexiondotorg> There are essential 3 packages in Ubuntu that trasform MATE into "Ubuntu MATE".
<flexiondotorg> Riddell, Is it possible someone else already uploaded ubuntu-mate-settings?
<Riddell> flexiondotorg: yep looks like it https://launchpad.net/ubuntu/+source/ubuntu-mate-settings/15.10.4
<Riddell> bug 1498439 is also done
<ubot93> bug 1498439 in galculator (Ubuntu) "Sync galculator 2.1.4-1 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1498439
<flexiondotorg> Riddell, Thanks very much.
<Riddell> https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/15.10.4 is also uploaded
<Riddell> so you're sorted
<flexiondotorg> Riddell, Brilliant. Thanks once again for your help uploading stuff.
<flexiondotorg> Riddell, Shall I add you to the Ubuntu MATE team page ;-)
<Riddell> flexiondotorg: thanks for the offer but I expect to wind down my ubuntu involvement
<ogra_> do i sense a kubuntu-mate here ?
<ogra_> based on kde 1.2 ?
<ogra_> :)
<flexiondotorg> ogra_, Isn't that call Trinity ;-)
<ogra_> heh
<davmor2> cyphermox, infinity: so it turns out that the b43 driver is taking ownership of the card that can only be powered by the bcmwl driver D'oh.
<cyphermox> davmor2: could you get me the output of lspci -nn?
<davmor2> cyphermox: apw just asked for the same thing http://paste.ubuntu.com/12521056/
<davmor2> cyphermox: I didn't realise till after that he was in here though :)
<davmor2> cyphermox: one is the dell one is the apple mac that is working so we could see the difference
<cyphermox> yeah, I think the modalias is missing from the package
<didrocks> ogra_: did you get the FFe approved? I didn't see any bug mentioned here?
<ogra_> didrocks, well, infinity let it into the archive, thats just binary NEW processing
<cyphermox> apw: ^
<didrocks> ok, I guess it was his way to ack the FFe :p
<didrocks> ogra_: having a look then
 * ogra_ would infinity's "letting it in" take as FFe ack 
<ogra_> +grammar :P
<flexiondotorg> cyphermox, The following may be worth looking at - https://bugs.launchpad.net/ubuntu/+source/b43-fwcutter/+bug/1490212
<ubot93> Launchpad bug 1490212 in software-properties (Ubuntu) ""Modaliases" field missing from debian control file" [Undecided,New]
<davmor2> ogra_: were there fluffy bunnies killed in the process, if not then it was just infinity helping you out, you know that FFe's have to kill fluffy bunnies or they are not taken seriously enough ;)
<davmor2> ogra_: https://www.youtube.com/watch?v=6dDBAiq4RFE
<cyphermox> flexiondotorg: thanks, that helps yeah. it should be made better too
<flexiondotorg> cyphermox, Yeah, someone has put in a lot of effort to try and unpick the Broadcom stuff there.
<cyphermox> davmor2: looks like it's indeed just missing 43b1.
<davmor2> cyphermox: so is that something we can get patched up and landed then?
<cyphermox> davmor2: yes, working on it now
<tjaalton> infinity, Riddell, pitti, Laney: hey, could one of you ACK/NAK https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279 ?
<davmor2> cyphermox: \o/ you rock dude
<ubot93> Launchpad bug 1484279 in mesa (Ubuntu) "[FFe] Mesa 11.0.0" [Medium,Confirmed]
<tjaalton> hm, why is it confirmed..
<Riddell> um, another mesa update on freeze week?
<tjaalton> another?
<tjaalton> it's been on the queue for a month
<apw> cyphermox, alias missing> from which package?  from bcmwl or fwcutter
<cyphermox> bcmwl
<Riddell> I mean this happens every cycle
<cyphermox> (it seems)
<tjaalton> Riddell: because of upstream release cycles
<cyphermox> apw, I been looking at https://wireless.wiki.kernel.org/en/users/Drivers/b43 which says 43b1 would be supported by wl but not by 43?
<cyphermox> *b43
<Riddell> tjaalton: sure, but it means bugs creap in and there's no time to fix them
<tjaalton> mesa has MRE
<cyphermox> apw: so if you agree with the change, I have a package ready.
<tjaalton> first point release coming this friday
<apw> cyphermox, wel i am wondering what is getting changed :)
<cyphermox> apw: just a sec
<cyphermox> http://paste.ubuntu.com/12521200/
<Riddell> tjaalton:  on the other hand could it fix this issue? https://bugzilla.redhat.com/show_bug.cgi?id=1259443
<ubot93> redhat bug 1259443 in mesa "Add brw_meta_fast_clear crash workaround patch" [Unspecified,Closed: nextrelease]
<tjaalton> yes
<apw> cyphermox, sounds very plausible
<tjaalton> but only because of a workaround patch
<tjaalton> which is just as valid for 10.6.x
<tjaalton> hm
<tjaalton> I'll check the rh bug..
<tjaalton> the status seems weird
<Riddell> tjaalton: do the packages include the workaround patch?
<cyphermox> davmor2: before I upload something, have you tried installing it manually, and when you do that does wifi then work?
<cyphermox> (I can't remember if you confirmed that)
<apw> i believe he did, but i'll let him speak for himself
<davmor2> cyphermox: indeed it works fine now that the cd and archive are in sync I can install it and away it goes
<tjaalton> Riddell: yep. the "nextrelease" is still wrong, aiui it's not fixed upstream
<cyphermox> ok, so you got online with it?
<davmor2> cyphermox: yeap
<Riddell> tjaalton: what testing has been done on this mesa?
<tjaalton> since it's a complicated issue and needs xserver/ddx fixes too
<cyphermox> davmor2: great, thanks
<tjaalton> Riddell: hrm, looks like test reports never made to lp
<tjaalton> anyway, I'm running it on intel
<davmor2> cyphermox: I went browsing through the ubuntu.com website.  Only issue seems to be if I run sudo lsmod b43 is up and running , and if I run sudo ubuntu-drivers list it only shows the intel-microcode.  So it won't install it automagically at all
<cyphermox> err, ok
<cyphermox> can you run lspci -vnvn again then?
<Riddell> tjaalton: aye but are you running kwin and plasma :)
<tjaalton> no, but someone is
<cyphermox> (after it's installed)
<didrocks> rtg: ogra_: there are quite some lintian errors (not only warnings) on your packages. Would appreciate them to be fixed before NEWing (depends-on-essential-package-without-using-version, unversionned copyrightâ¦) and some typos (but those are not blocking) ;)
<didrocks> just run lintian *deb on your debs ;)
<tjaalton> Riddell: as mentioned on https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1492037
<ubot93> Launchpad bug 1492037 in mesa (Ubuntu) "Segmentation fault in brw_meta_fast_clear" [Critical,Triaged]
<davmor2> cyphermox: sure give me 5
<Riddell> tjaalton: groovy, approved
<tjaalton> cool, thanks!
<davmor2> cyphermox: http://paste.ubuntu.com/12521292/
<tjaalton> Riddell: do you think I should wait for the point-release and upload after beta?
<Riddell> tjaalton: uploading before beta would be better if you think it'll get comiled and in the archive in time and you don't know of obvious problems
<tjaalton> ok, sure
<cyphermox> davmor2: ok good
<ogra_> didrocks, it is a bit weird, the package is supposed to actually be based on our linux package (even using the same .orig) with just patches added on top and a RPi specific config ... i dont really get why it would be any different from our linux package
<didrocks> ogra_: maybe your linux package didn't get any cleanup for quite some time then?
<ogra_> could be
<didrocks> would be the right time to do some cleaning ;)
<ogra_> not really
 * ogra_ is already two days behind with the for-monday promised RPi image snappy :(
<ogra_> *on snappy
<didrocks> well, if we let it in and you say it's clearly already the case for the linux package, it means that it's not going to be cleaned once it's getting in
<ogra_> i dont maintain it ... i only consume it
<ogra_> so i cant promise that indeed ... we'll have to wait for adam and tim
<didrocks> yep
<rtg> didrocks, your are right, its likely time to do some house cleaning on the main linux package (from which raspi2 is descended)
 * flexiondotorg is watching this rpi2 stuff closely as well.
<infinity> tjaalton: Robert dropped your fix for LP: #1392887 when he merged xf86-input-wacom
<infinity> tjaalton: Since he doesn't seem to be online to yell at, you win. :P
<ubot93> Launchpad bug 1392887 in xf86-input-wacom-lts-utopic (Ubuntu Trusty) "serial wacom devices gone after upgrade to utopic/14.10" [Undecided,New] https://launchpad.net/bugs/1392887
<tjaalton> infinity: ah, great :)
<bdmurray> infinity: Could you have a look at that apport upload?
<infinity> bdmurray: I would, but no debdiff in the queue yet.  So, you lose.
<bdmurray> infinity: How about this? http://pastebin.ubuntu.com/12523113/
<infinity> bdmurray: I don't trust your sketchy pastes.
<bdmurray> infinity: alrighty
<infinity> bdmurray: Also, not that it matters, but I'd 's/non-distro //' in your changelog.
<infinity> bdmurray: Assuming that's apt origin, it's only accurate as far as you can map package->Packages->Release, so it's not "non-distro", but just "unknown origin".
<bdmurray> I just copied what pitti said when it was fixed in raring or whatever release it was.
<infinity> Heh.
<infinity> Alright. :)
<infinity> I do consider it a lacking dpkg feature that we don't record enough info in /var/lib/dpkg/status to track origin/uniqueness of packages post-install.
<infinity> If we recorded the *sums fields, for instance, we could reverse map to older packages and know if they're "ours".
<tjaalton> infinity: oh you meant bug 1497041, caused by attemptin to rename things in *.install..
<ubot93> bug 1497041 in xf86-input-wacom (Ubuntu) "Strange file /lib/udev/rules.d/69-wacom.rules/wacom.rules" [High,New] https://launchpad.net/bugs/1497041
<infinity> tjaalton: The bug I aimed at was "closed" by the rename fix.
<infinity> tjaalton: But yes.  The rename/directory issue is what I meant.
<tjaalton> yes, fix for the old, now reincarnated because of that
<infinity> tjaalton: FWIW, dh-exec can allow you to rename in .install files, if you'd prefer that to rules hacks.
<infinity> tjaalton: (search for dh-exec in dh_install(1))
<tjaalton> oh
<tjaalton> never seen that
<tjaalton> neat
<wxl> what's the eta on images folks?
<infinity> wxl: I'll freeze and spin some in a bit.
<infinity> wxl: At a conference right now, a bit thrown off my groove.
<wxl> thanks infinity. anything fun?
<infinity> wxl: I've spent a lot of time talking about firmware and bootloaders.  If that's "fun", then yes.
<wxl> hahahahh
<wxl> infinity: which conference is this? (don't let me keep you by the way, with idle chatter)
<infinity> wxl: Linaro Connect.
<wxl> infinity: nice. a little over my head atm, but i'm sure it's enthralling for someone in the know.
<infinity> I'm so enthralled in this current session that I might just have an enlightened nap.
<infinity> (Or, go have some hallway conversations and then find a corner to do freeze/beta things in)
<wxl> heheh
<davmor2> cyphermox: how's your fix coming along?
<cyphermox> davmor2: for bcmwl?
<davmor2> cyphermox: yeap
<cyphermox> uploaded, maybe still in proposed
<cyphermox> looks like it's waiting for armhf testing to get done :P
<cyphermox> infinity: ^ can you help?
<wxl> cyphermox: he's at linaro connect fwiw
<cyphermox> wxl: yes
<infinity> cyphermox: I can give it a nudge.
<infinity> If the wireless agrees with me.
<balloons> infinity, how's things looking for final beta? It's listed on the release as this thursday, but I've heard no rumblings about it
<wxl> balloons: he's working on it while at a conference
<infinity> balloons: What he said.  I'll get ISOs sorted over the course of the day.  If we have to release a tiny bit late, we'll do so.
<balloons> infinity, ack, ty. I felt like I remember it being pushed back, but I couldn't find any confirmation
<infinity> balloons: There was no intentional push-back, I just ended up double-booked this week and I'm trying to catch up. :P
<tjaalton> infinity: heh, dh-exec doesn't work too well with dh_install --fail-missing, since the original file is still there
<tjaalton> good idea though
<infinity> tjaalton: Ahh, yeah, I can see how they wouldn't play together.
#ubuntu-release 2015-09-23
<cyphermox> yay builds.
<flocculant> infinity: or indeed anyone who's in the know - no upgrade tests for beta 2 - missing or are we not getting those ?
<davmor2> infinity: netboot is missing from the beta 2 test run
<davmor2> jibel: ^ is that something you can add or just the landing team?
<jibel> davmor2, I'll add it
<davmor2> jibel: thanks
<pitti> what's the current status wrt. image builds? can we accept the fixed langpacks?
<jibel> pitti, first builds have been posted last night. It'd be nice to respin with latest langpacks
<pitti> i. e. if we do a respin, the langpacks and user-setup would be really worthwhile
<pitti> I don't know about unity-control-center, there's no diff
<pitti> ah, https://launchpadlibrarian.net/218625387/unity-control-center_15.04.0%2B15.10.20150915-0ubuntu1_15.04.0%2B15.10.20150923-0ubuntu1.diff.gz
<pitti> seems okay too
<davmor2> pitti: I think they might need to resping to fix  this issue with wifi driver for the xps 13 too
<davmor2> just trying it to see if it works now
<pitti> if we are having a respin, I'll accept them now so that they can build
<pitti> and if we don't have a respin, well then it doesn't matter anyway
 * pitti does, I'll take the bullets
<davmor2> yeap b43 is still taking control of the wifi driver so I don't no if it landed in the image yet so there will be a respin
<davmor2> s/no/know
<pitti> ah, thanks to whoever approved those
<Laney> me
<Laney> Seems like we get one anyway so might as well have fixes especially for user-setup
<pitti> Laney: right, I was going to accept them, but noticed they were gone; I first thought I messed up my mass-accept for langpacks
<Laney> :)
<jamespage> would anyone in the release team object if I enabled python3 and doc packages for python-pylxd?
<jibel> davmor2, ^
<davmor2> \o/
<ogra_> rtg, yo ...
<rtg> ogra_, dude
<ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ... "linux-raspi2-tools-4.2.0-1008/armhf unsatisfiable Depends: linux-raspi2-tools-common "
<ogra_> we probably want to drop the tools :)
<rtg> hmm
<ogra_> i doubt anyone in snappy will use them
<ogra_> (and i'm not sure how well suited the kernel will be for non-snappy setups)
<rtg> ogra_, yup, will do.
<flocculant> seb128: bug 1498544 - which you repurposed for new installs - was originally an upgrade bug ;)
<ubot93> bug 1498544 in user-setup (Ubuntu) "Autologin not correctly enabled on 15.10 installations" [High,Fix released] https://launchpad.net/bugs/1498544
<flocculant> what package should I report against for upgrade fails in this then?
<seb128> flocculant, depends of what's the issue. is the file mangled/change on upgrade?
<seb128> I though lightdm was supposed to understand the old format
<seb128> in which case it's a lightdm issue if it doesn't
<seb128> if something migrates the config then it's that something but I don't know what that is
<flocculant> seb128: mmm
<flocculant> not sure tbh
<seb128> well, somebody needs to do a 15.04 install, look at the config, upgrade and see if that changed
<flocculant> I did :) now I can't remember which file changed - it being different for me (xubuntu) than others
<flocculant> I'll look again after I've finished worrying about b2
<flocculant> seb128: thanks for that fix though :)
<seb128> yw!
<flocculant> will that get in when they respin?
<seb128> yes
<flocculant> ok - I'll make sure to check that out :)
<cyphermox> davmor2: were you saying that you're still having an issue with bcmwl showing up in Drivers?
<davmor2> cyphermox: indeed
<cyphermox> boo
<davmor2> cyphermox: I added a work around for now for the beta but it is marked as critical for release unless you have some brain waves on fixes.  works fine in vivid by the way so I assume we lifted a blacklist on b43 in wily again
<cyphermox> well, in wily it was matching for a whole bunch of devices from Broadcom
<cyphermox> now it's specifically targetting those that it's useful for
<cyphermox> what I changed was adding the modalias for the one in your system
<davmor2> cyphermox: I was wondering if it needed changing in b43 as well as bcmwl modules
<cyphermox> should not
<cyphermox> in the worst case, if both had the modalias they would both show in the Drivers window
<apw> we have no blacklist for the others that wl takes over for
<cyphermox> so if it's still not showing, there probably is still something wrong in ubuntu-drivers-common
<apw> the act of installing wl because it is offered disables b43 anyhow
<davmor2> apw: yeap if I install it manually we can see that happen, it just isn't doing it automagically
<cyphermox> davmor2: we'll go step by step and retrace what ubuntu-drivers does
<cyphermox> davmor2: could you please run this python code: http://paste.ubuntu.com/12531607/
<davmor2> cyphermox: give me about 30 minutes to finish up what I'm running and flash 15.10 to usb again
<cyphermox> sure
<cyphermox> ^ that will list all the modaliases on the system, from there we'll see if it's something I missed in there, or if there's something else in ubuntu-drivers that's the matter
<davmor2> cyphermox: also I got hit by https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1481798 running upgrade test from 15.04
<ubot93> Launchpad bug 1481798 in modemmanager (Ubuntu) "package:modemmanager:1.4.10-1:subprocess installed post-installation script returned error exit status 100" [Critical,Triaged]
<cyphermox> yep
<davmor2> cyphermox: I know I lead the funniest life you've ever known right ;)
<cyphermox> bah
 * cyphermox stabs modemmanager some more
 * davmor2 hands cyphermox his jackhammer
<pitti> mdeslaur: ^ FTR, this might disrupt the thing you are working on?
<mdeslaur> pitti: yes! please reject
<pitti> mdeslaur: I can't -- someone accepted them, so the version number is "burned"
<mdeslaur> ack, will bump and retest, thanks
<davmor2> cyphermox: http://paste.ubuntu.com/12531876/ hope that looks right
<davmor2> cyphermox: I just thought, the bcmwl package isn't actually installed on the system is it, so wouldn't that mean that the instruction set you gave it will have no effect on the live version?
<flocculant> seb128: I assume that as lightdm appears to mangle it - that's what I should report this against? http://paste.ubuntu.com/12531997/
<seb128> flocculant, yes
<davmor2> cyphermox: or does the system recursively scan the system for none installed packages to see if they can be used for certain pic: listings
<flocculant> seb128: ok - I'll do that now then
<davmor2> pci even
<seb128> flocculant, thanks
<flocculant> welcome ofc
<flocculant> seb128: bug 1498975
<ubot93> bug 1498975 in lightdm (Ubuntu) "Vivid to wily upgrade fails for autologin" [Undecided,New] https://launchpad.net/bugs/1498975
<seb128> flocculant, thanks
<cyphermox> davmor2: what I gave you does nothing to packages
<flocculant> seb128: I'll keep that vm about as it is if anything else is required
<seb128> flocculant, k, thank you, I emailed robert_ancell about it, so let's see
<flocculant> yep
<rtg> ogra_, uploaded raspi2 kernel and meta. both awaiting approval.
<davmor2> flocculant: seb128: there is a bug for the fact that autologin is broken in wily on the tracker I don't know if it is just upgrades but wily as a whole
<flocculant> davmor2: I did see a bug - but that was all fix released
<flocculant> and things on tracker recently - are probably me and flexiondotorg :)
<davmor2> flocculant, seb128: looks like the iso still has ubuntu6 on the system and you have fixed it in ubuntu7 of user setup
<flocculant> yea
<flocculant> but - flexiondotorg reports that he's seeing it still fail after he respun Mate
<davmor2> so if the package  is stuck in proposed it won't show via update either
<seb128> cyphermox is doing an ubiquity update to include the fixed user-setup, that was not done earlier
<flocculant> aah cool
<flocculant> I was waiting for a global respin
<ogra_> rtg, oh, weird, why do they need approval again ? i thought once granted they should just go through
<cyphermox> davmor2: I think I just found out what was wrong with ubuntu-drivers-common too
<ogra_> infinity, ?? ^
<davmor2> cyphermox: nice
<rtg> ogra_, the beta release cycle has started
<cyphermox> davmor2: can I get you a patch to apply after, or do you prefer a PPA package?
<cyphermox> oh wait, this is going to be annoying to update anyway without network.
<davmor2> cyphermox: I have a usb key
<davmor2> cyphermox: sneaker-net
<davmor2> cyphermox: package is easier than a patch, I've used patch before and had mixed results so something that is guaranteed to work is always better :)
<wxl> are we planning on releasing today, infinity ?
<ogra_> rtg, ouch, bad timing then
<apw> don't we go into soft freeze from beta anyhow as well ?
<cyphermox> seb128: flocculant: flexiondotorg: ubiquity ^
<davmor2> cyphermox: just give me a ping if you want me to look at something need to press on with testing now ;)
<flocculant> cyphermox: what do you mean by ^^ ?
<Riddell> could someone add upgrade to the beta 2 tests? it still fails ( bug 1488838 )
<ubot93> bug 1488838 in ubuntu-release-upgrader (Ubuntu) "upgrade fails on modemmanager" [High,Confirmed] https://launchpad.net/bugs/1488838
<davmor2> Riddell: it does indeed still fail I pointed cyphermox at it earlier to make his day :)
<Riddell> davmor2: I pointed him at it a month ago, does that mean I made his month?
<davmor2> Riddell: possibly, you know he isn't happy without bugs to tackle
<cyphermox> flocculant: meaning that the ubiquity package for user-setup is in the queue now. someone in the archive admin team will have to review it.
<flocculant> cyphermox: ok - just checking - I'll assume that's gone through when I see a rebuild
<cyphermox> maybe
<infinity> rtg: There was no manual approval process for raspi2, it was auto-accepted.
<rtg> infinity, huh. I received an email that said it was awaiting approval, but I see it is building now.
<rtg> ogra_, ^^
<ogra_> yeah
<infinity> rtg: Yeah, everything hits the unapproved queue, but the vast majority of uploads get accepted by a bot < 60s later (which you also got a mail about).
<flexiondotorg> cyphermox, Brilliant. I'll give it the new Ubiquity a test now.
<flexiondotorg> Ah, it's proposed.
<cyphermox> flexiondotorg: it's still in the queue
 * flexiondotorg waits.
<flexiondotorg> cyphermox, Thanks for working on that.
<flexiondotorg> cyphermox, And the modemmanager too. I ran into that just a moment ago building the Raspberry Pi 2 image.
<flexiondotorg> touch /etc/init.d/modemmanager and dpkg --configure -a sorted it ;-)
 * cyphermox is building a vivid package for it right now, to test the change with minimal fuss
 * flexiondotorg nods
<davmor2> cyphermox: hows the package for ubuntu-drivers-core coming?
<cyphermox> oh, right, that.
<cyphermox> failed tests, I either broke something or need to adjust the tests with my changes
<davmor2> 99 little bugs on a wall, 99 little bugs, take one down fix around there's 101 little bugs on the wall
<cyphermox> exactly
<flocculant> 102
<wxl> 105 now
<wxl> oops make that 159
<wxl> ummm 224!
<wxl> uhhh
<wxl> yeah.
<cyphermox> just want to make sure I'm not making it too many more with this fun hack
<cyphermox> wxl: you're running dangerously close from -19481419.
<davmor2> infinity: if you are still about upgrades are missing from the tracker
<infinity> davmor2: I have no idea how upgrades appear on the tracker, I don't do that bit.
<infinity> davmor2: stgraber or balloons might have a clue about it. :P
<stgraber> they're manually added
<infinity> stgraber: FSVO "manually" that involves a scripted loop and some API calls, I hope?
<infinity> stgraber: (ie: could add-upgrades-to-tracker be a thing in ~ubuntu-archive-tools?)
<stgraber> infinity: web ui, go to Builds, tick those you want, enter the milestone name as the version number, select the milestone in the dropdown and click add
<stgraber> infinity: doing it now
<stgraber> done
<davmor2> stgraber: thanks
<stgraber> you can select them all in one click, then just uncheck those that are lts-only
<flexiondotorg> infinity, Can I pick you brains about do-release-upgrade a sec?
<flexiondotorg> infinity, I just upgrade Ubuntu MATE 15.04 to 15.10.
<flexiondotorg> do-release-upgrade did that just fine, other than the modemmanager issue cyphermox is working on.
<flexiondotorg> However, all the packages that a new to the ubuntu-mate seeds during the 15.10 cycle and now identified as no longer a required.
<flexiondotorg> An apt-get auto-remove will remove them.
<flexiondotorg> Can you think what I have done wrong in the seeds to case this?
<flexiondotorg> I'm sure cjwatson is afk but maybe he has an suggestion too? ^^^
<infinity> flexiondotorg: Example package?
<flexiondotorg> mate-optimus
<infinity> flexiondotorg: But that sounds sort of like either ubuntu-mate-desktop wasn't kept installed, or it's not up to date with your seeds, or you're mistaken about what you think should be installed. :P
<flexiondotorg> OK, not 3 ;-)
<infinity> flexiondotorg: Or the upgrade isn't pulling in ubuntu-mate-core.
 * flexiondotorg checks if ubuntu-mate-desktop is installed.
<infinity> flexiondotorg: That package is core, not desktop.
<infinity> flexiondotorg: Is that split new?
<flexiondotorg> I've always had -core and -desktop
<flexiondotorg> But I moved a lot of stuff from -desktop to -core.
<flexiondotorg> During the 15.10 cycle.
<infinity> flexiondotorg: Well, it's not installed, if apt is trying to remove its deps.
<flexiondotorg> Yep, ubuntu-mate-core was missing from the upgraded system.
<flexiondotorg> Can I tweak the seeds to ensure ubuntu-mate-core does remain installed?
<infinity> flexiondotorg: So, check out data/DistUpgrade.cfg in ubuntu-release-upgrader
<flexiondotorg> OK
<infinity> flexiondotorg: No one taught it about mate.
<flexiondotorg> Phew, because it's the first I've heard of it :-)
<infinity> flexiondotorg: That said, in my personal opinion, if "apt-get dist-upgrade" doesn't get it mostly right, you're already fighting a losing battle.  The ensure-metas-don't-go-away quirk in the release-upgrader is a last resort fixup, not a crutch.
<infinity> flexiondotorg: But if you violently moved a bunch of packages from one meta to another, apt's not super good at resolving that.
<flexiondotorg> Aha.
<flexiondotorg> So, Ubuntu MATE is not in there.
<infinity> flexiondotorg: Right, not at all.
<flexiondotorg> Should I prepared a merge proposal?
<flexiondotorg> Or debdiff?
<infinity> flexiondotorg: So, the two metas should be added to the big list at the top, then two ini-style stanzas further down for them tha tidentify some "key mate deps" to allow us to guess if mate is meant to be there.
<infinity> flexiondotorg: debdiff works for me.
<flexiondotorg> infinity, Ok. I'll go a make a debdiff.
<flexiondotorg> infinity, Many thanks for helping me with that.
<infinity> flexiondotorg: The point of the ini-style bits is so we can "guess" if a user removed one of your packages and lost ubuntu-mate-desktop, but still has "these 7 things that probably mean it really is a MATE install", we can reinstate mate-desktop/mate-core after upgrade.
<infinity> It's not foolproof, but kinda sorta works. :P
<flexiondotorg> infinity, Go to be better than what I've just seen :-)
<davmor2> cyphermox: if you get that package sorted throw me a link in an email and I'll hit it first thing
<flexiondotorg> infinity, OK, identifying markers done. Anything else I need to add/change in there before I make a debdiff?
<flexiondotorg> OK, found blackliested packages, looks like I need ubuntu-mate-core in there.
<infinity> flexiondotorg: No idea.  I don't add flavours to the upgrader on a regular basis. ;)
<infinity> flexiondotorg: Err, why would you blacklist the package you want installed?
<infinity> flexiondotorg: Oh.  The removal blacklist. :P
<flexiondotorg> Comment reads "blakclist of packages that should nver be removed."
<infinity> flexiondotorg: You don't need that in an explicit blacklist if you already list it in MetaPkgs.
<flexiondotorg> OK
<flexiondotorg> I've done it anyway.
<infinity> flexiondotorg: Oh, see, I say that, but most of the metas are in there.  That seems entirely redundant.
 * infinity shrugs.
<infinity> This whole package is a hack, nothing in it surprises me anymore.
<flexiondotorg> infinity, You want me to bump the standards in debian/control?
<infinity> flexiondotorg: If you go through the policy upgrade checklist and/or make sure lintian doesn't have any new things to whine about, sure.
<infinity> The number shouldn't be a lie just to chase after the latest. :P
<flexiondotorg> infinity, After a standards bump to 3.9.6 lintian complians about one less thing that before.
<infinity> flexiondotorg: Handy.
<infinity> It's rather odd when you decide to hide in your hotel room to get some work done, and the maintenance staff decides that's the best time to replace your windows.
<flexiondotorg> infinity, Here you go - https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1499078
<ubot93> Launchpad bug 1499078 in ubuntu-release-upgrader (Ubuntu) "ubuntu-release-upgrader has no support for Ubuntu MATE" [Undecided,New]
<flexiondotorg> infinity, Thanks for helping.
<mdeslaur> hey SRU team, there's an update to fast-track because of a regression caused by the new python SRU in trusty
<mdeslaur> bug 1499075
<ubot93> bug 1499075 in python-botocore (Ubuntu Trusty) "python3.4.3 SRU breaks awscli" [Undecided,In progress] https://launchpad.net/bugs/1499075
<mdeslaur> broder and nelhage in #ubuntu-devel can test
<mdeslaur> that's it ^
 * mdeslaur -> away
#ubuntu-release 2015-09-24
<zhangchao> Hi, release team, Help: we want to update some packages for Wily Beta 2 of Ubuntu Kylin. package have be uploaded by aron , but needs approval from release team.
<infinity> zhangchao1: I assume the two with "kylin" in the name?
<zhangchao1> infinity: package name :ubuntu-kylin-software-center,ubuntukylin-default-settings ,ubuntukylin-wallpaper
<infinity> zhangchao1: That Z99-zip-gbk.sh is pretty sketchy shell. :P
<infinity> zhangchao1: I think what you wanted there to avoid all the crazy forks was "case $LANGUAGE in; zh_CN*) do stuff;; esac"
<zhangchao1> infinity: We want to take effect when $LANGUAGE contains zh_CN
<infinity> zhangchao1: Yes, I know.  I'm questioning the use of "echo | grep" there. :)
<infinity> zhangchao1: This would have the same effect with 90% less crazy: http://paste.ubuntu.com/12537803/
<infinity> zhangchao1: And the added bonus of being extensible more easily to other locales, if you decide zh_CH isn't the only one this should apply to.
<zhangchao1> Z99-zip-gbk.sh is  sketchy,we will fix it after beta2
<zhangchao1> yes, only zh_CH is not enough.
<infinity> zhangchao1: If you're going to commit to fixing it after the beta, I'll let it in, but do promise it'll be sorted. :P
<infinity> Not that I run kylin, but if I did, I'd be horrified reading that. ;)
<zhangchao1> infinity: Sure,we will fix that  as soon as possible after beta2.
<infinity> Alright, so I'm letting the kernel in, and those kylin bits, then respinning the world, and this should be the last spin of beta2.
<infinity> May the rest of our bugs be vaguely not critical.
<zhangchao1> infinity: ok, thank you for your help
<infinity> wxl: Sorry, I know lubuntu got marked ready, but I had to respin the world just once.  If you guys can lightly test the new ISOs to make sure they still boot and such, that would be nice.
<amjjawad> Hello infinity, any idea about this bug 1462688?
<ubot93> bug 1462688 in ubiquity (Ubuntu) "ubi-timezone failed exit code 1 error when installing UbuntuStudio Wily-15.10 32bit version" [Critical,Confirmed] https://launchpad.net/bugs/1462688
<amjjawad> infinity, for my testing, I can finish the installation normally by clicking "continue anyway" and it works. It seems some other people are having problems with that and some other can't see it. It's alive even before beta 1
<infinity> cyphermox: ^
<cyphermox> oh, that's new
<cyphermox> (well, not really, but hey)
<cyphermox> amjjawad: what timezone did you pick?
<amjjawad> hi cyphermox, I see it 'before' selecting anytime zone. And, when I choose "continue anyway", everything is fine after that and my installation did not crash.
<cyphermox> I already did some of the work to add the zone bits for Pyongyang time but it was still incomplete, and no matter what I did I couldn't reproduce the crash
<cyphermox> amjjawad: did you have a network connection when you did the install?
<cyphermox> in case that changes anything
<amjjawad> cyphermox, yes, I am on +10GMT
<amjjawad> cyphermox, testing actually on Oracle Virtualbox 5.0.2
<cyphermox> oh, but I mean, were you online, as detected by ubiquity at the beginning?
<amjjawad> cyphermox, Oracle Virtualbox will use your connection no matter what it is. So yes, I am connected to the internet or to be more accurate, the virtual machine is connected to the internet and my time zone is +10 gmt
<cyphermox> ok
<cyphermox> thanks. this might make a difference
<amjjawad> cyphermox, you're welcome. From your Q, I assume the crash will happen when the machine is offline?!
<ianorlin> cyphermox: would trying to reproduce this in a kvm vm be helpful?
<cyphermox> ianorlin: of course
<cyphermox> I tried already, couldn't find what to do to make it show up
<cyphermox> I would never get the crash, but picking the north korea timezone also wasn't completely reacting properly.
<cyphermox> amjjawad: I wonder if it might *not* happen if the machine is offline.
<cyphermox> in case it has anything to do with the codepaths when the timezone is automatically detected
<amjjawad> cyphermox, do you want me to test it while the machine is offline?
<cyphermox> up to you
<cyphermox> I'll get back to this in the morning, it's getting pretty late to dig in ubiquity :)
<amjjawad> once the new builds for Ubuntu GNOME are ready, I'll try that and see what will happen :)
<amjjawad> It's 14:23 here but I know it's totally different on the other part of the world :)
<cyphermox> yes, it's past midnight here
<cyphermox> I've been trying to fix the modemmanager upgrade bug
<amjjawad> get some rest cyphermox and thanks a lot for all your hard work :)
<cyphermox> amjjawad: ianorlin: if you manage to reproduce it, it would be great if you could add a traceback to the bug
<cyphermox> running ubiquity with --debug might help there.
<ianorlin> although think I might be one of the last people on lubuntu QA team awake at this time
<amjjawad> cyphermox, will try to remember that. Just open the Terminal and type ubiquity --debug ?
<cyphermox> yeah, that would start ubiquity, with debugging enabled
<amjjawad> cyphermox, but that means I need to use that while I choose "try without installation", correct? AFAIK, I can't use that while choosing "Install" option ..
<cyphermox> correct
<cyphermox> to use the straight install, you'd need to hit F6 and add "debug-ubiquity" on the command-line
<amjjawad> cyphermox, perfect, I'll do that and update the bug report in case I'll find anything new
<cyphermox> amjjawad: you're not in Papua New Guinea by any chance?
<cyphermox> amjjawad: ianorlin: if you manage to reproduce, I'd be interested if you could modify ./usr/lib/ubiquity/tzsetup/post-base-installer to add a 'set -x' near the top and go back/forward again in the installer to get the crash to happen again (hopefully), then add syslog to the bug report
<cyphermox> that could confirm what I think this is
<cyphermox> and on that, I'm going to bed ;)
<ianorlin> cyphermox: I can't reproduce it installing to my laptop on bare metal and I think I might be the only one still awake on the lubuntu QA team
<amjjawad> ianorlin, are you awake still?
<amjjawad> ianorlin, cyphermox turning off the network connection did the trick. I no longer see the error message and I can now select the timezone from the world map :)
<ianorlin> yes I am still awake
<flocculant> seb128: upgraded with image - if people want me to do the same with upgrade-manager then I will, but it'll not be today - most interested today in B2 for us
<seb128> flocculant, with "image"?
<seb128> from a livecd/with ubiquity you mean?
<flocculant> yeas
<seb128> oh, then it might be the same user-setup bug than the new install one
<seb128> sorry, when you said upgrade for me it was dist-upgrader/update-manager
<seb128> which is why I though it was weird
<flocculant> seb128: that's what I thought too - so I have managed to find time this morning to run through with updated wily image
<flocculant> just waiting for it to finish the upgrade now
<seb128> flocculant, thanks
<flocculant> seb128: ok - so upgrading with new livecd - autologin works
<seb128> flocculant, great, bug fixed then, thanks for testing
<flocculant> commented on bug
<flocculant> seb128: I've got to do some upgrade testing anyway - so I'll autologin test while doing the update-manager test
<seb128> thanks
<flexiondotorg> cyphermox, I've also tried to reproduce the ubi-timezone issue.
<flexiondotorg> cyphermox, People are reported the issue but I've never been able to reproduce it regardless of whether I have a connection or not.
<ianorlin> I did several installs on my laptop and virt-manger did not reproduce ubi-timezone
<flocculant> seb128: not sure re autologin - upgrade crashed with modemmanager problems
<amjjawad> flexiondotorg, hi :) still can't produce that bug?!
<flexiondotorg> amjjawad, Which bug?
<amjjawad> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1462688
<ubot93> Launchpad bug 1462688 in ubiquity (Ubuntu Wily) "ubi-timezone failed exit code 1 error when installing UbuntuStudio Wily-15.10 32bit version" [Critical,In progress]
<flexiondotorg> amjjawad, I've never encountered it.
<flexiondotorg> Not since 14.10 anyway.
<amjjawad> flexiondotorg, interesting. I wounder why :D
<amjjawad> are you testing Ubuntu MATE only?
<flexiondotorg> amjjawad, I think it might be linked to the geographical location that is detected.
<flexiondotorg> I have test Xubuntu and stock Ubuntu.
<amjjawad> flexiondotorg, I see. Could be.
<flexiondotorg> Because Xubuntu, Ubuntu and Ubuntu MATE all use lightdm and there was a regression there which is now fixed.
<flexiondotorg> I'll grab Ubuntu GNOME as try it.
<flexiondotorg> I have the time.
<amjjawad> flexiondotorg, that's so kind of you :) you might want to check the comments I posted on that bug
<flocculant> seb128:  ok so - got in, got wily, it does autologin following upgrade-manager, lightdm conf still has [SeatDefaults] rather than [Seat:*] - not sure if that needs reporting or not
<seb128> flocculant, no, it doesn't, we don't have code migrating configs, but lightdm understands the old format for compatibility reasons
<flocculant> ok cool - so it looks like green for upgrades then :)
<flocculant> at least with this issue
<flexiondotorg> Woo!
<davmor2> flocculant: not for me modemmanager still broke it I had to run dpkg --configure -a to fix the install
<davmor2> auto-login however works fine now :)
<flexiondotorg> amjjawad, I've read the bug.
<flexiondotorg> amjjawad, I can't reproduce in Ubuntu GNOME either.
<flocculant> davmor2: yea - that's what the comment at 10:58 says - the 11:05 ones are about autologin :)
<amjjawad> flexiondotorg, really weird. Thanks for the feedback
<flocculant> ftr - someone sees that timezone issue in xubuntu - I can't reproduce either
<cyphermox> flexiondotorg: I'm not surprised you can't reproduce it, I think it's very specific to what timezone you'll get from NTP or what timezone you might pick. probably just the former
<flexiondotorg> cyphermox, I've tried manually changing my time zone to that of people who reported problems.
<flexiondotorg> Still couldn't make it fail.
<cyphermox> right
<cyphermox> flexiondotorg: I think what I'll do is upload a version of ubiquity which gives me more data.
<rcj> infinity, cloud images are ready for beta 2
<wxl> thanks we're on it already infinity :) about ready to mark ready
<wxl> and ready
<infinity> wxl: I'm guessing from the complete lack of registered tests that lubuntu/ppc isn't being released?
<wxl> infinity: that's correct
<Riddell> kubuntu good to go, mparillo about if you need someone to ping, I'm wandering out
<rtg> ogra_, re-re-re-uploaded raspi2 after getting slapped by infinity for removing the tools packages.
<ogra_> rtg, tell infinity i'll slap him for slapping you after he disabled snappy builds for two days (and everyone was wondering why the things didnt land :P )
<rtg> whoa, I'm staying out of that one.
<ogra_> but instead of slapping each other we all should just have beer at the next sprint ;)
<cjwatson> https://www.youtube.com/watch?v=IhJQp-q1Y1s
<ogra_> LOL
<rtg> :)
<infinity> ogra_: Sorry about that.  Overzealous application of #
<ogra_> :)
<ogra_> no worries
<rcj> infinity, I'm going to be away for an hour or so, but cloud images are currently ready to begin publication when we get the go ahead.
<kgunn> hey guys, i've got a bit of a conundrum, so we like dual landing our projects, and we're hoping to get some hot fixes landed for OTA7
<kgunn> however got into situation where, we release a mir/u-s-c, it got promoted in vivid+o but stuck in UNAPPROVED for wily
<kgunn> and so, aiui, that prevents us from force merging what will-be-released back
<kgunn> preventing us from landing any further changes, and i have a specific critical bug fix associated with u-s-c
<kgunn> and also aiui, once wily beta is curated, u-s-c will move to proposed - can someone confirm? and provide estimate?
 * kgunn listens to crickets
<infinity> kgunn: I'll accept mir shortly, once beta2's ducks are all in a row.
<kgunn> infinity: cool, and then it'll just sit in proposed? or actually flow all the way thru ?
<infinity> kgunn: That's up to autopktesting, but it'll migrate the way it usually does, nothing special is blocking it.
<kgunn> ah, got it, thanks infinity
<infinity> rtg:
<infinity> -Vcs-Git: git://kernel.ubuntu.com/ubunt/ubuntu-wily-meta.git raspi2
<infinity> +Vcs-Git: http://kernel.ubuntu.com/git-repos/ppisati/ubuntu-RELEASE_NAME-meta.git raspi2
<infinity> rtg: ^-- unintentional?
<doko> would somebody mind if I still do the netcdf 4 transition? then I don't have to do it next cycle
<infinity> doko: netcdf 4 is already in wily.  Is it half-transitioned or something?
<doko> no, I mean 4.4
<infinity> Ahh, that makes more sense.
<rtg> infinity, ah, yeah. they came back with the revert. I'll fix it for the next upload.
<infinity> doko: The only things that jump out as being potentially scary in rdeps are vtk and gdal.  Is this transition all done in Debian already?
<doko> it's in testing
<infinity> doko: If so, and if there's some alrightish test coverage (automated or manual), seems fine to me to go for it.
<davmor2> infinity: image still seems to have wubi on it should that not be removed now?
<doko> infinity, are you able to accept #1499075 for trusty-proposed?
<infinity> davmor2: I'm not sure we ever made a formal decision on the future of wubi.exe.  Last few times it came up, it was pointed out that it's also the pretty autorun when you stick it in a Windows machine, but I'm not sure how much that matters anymore.
<infinity> davmor2: Not fixing for beta2 anyway, but we should sort out WTF we want to do there before final.
<davmor2> infinity: in windows 7 + I'm not sure it autoruns like it did in previous versions I'll have a look in windows 10 and 7 and see if I am right
<infinity> davmor2: Yeah, I think in 7+ (or maybe vista+), it just pops the "what do you want me to do with this?" dialog instead of autorunning the GUI.
<infinity> davmor2: I think.
<infinity> davmor2: Which makes the autorun argument a lot less valid.
<davmor2> infinity: yeah and that stops the autorun from actually running I will confirm though
<davmor2> infinity: hahahahahahahahaha windows 10 just says You need to format the disk in dive i: before you can use it :D
<infinity> davmor2: Brilliant.
<davmor2> infinity: that is on i386
<infinity> davmor2: It might behave slightly better with optical media, rather than a USB stick, but maybe not.
<flexiondotorg> Ugh, backlog on another logged in workstation.
<flexiondotorg> infinity, How is the status of Beta2?
<davmor2> infinity: amd 64 it just opens the EFI folder  will check cd's in a second
<infinity> davmor2: Hah.  That's a little bit insane.  Go Windows.
<infinity> flexiondotorg: Looks like everything's readyish on the tracker, just need to publish images, sort out paperwork, etc.
<davmor2> infinity: the EFI in fat though right so it knows how to open that bit
<infinity> davmor2: Right, it's not entirely unexpected behaviour, just a bit hilariously useless.
 * infinity might go hide in a hotel room to finish up this beta.
<flexiondotorg> infinity, Where are you and why do I keep seeing reference to hiding in a hotel room? ;-)
<davmor2> flexiondotorg: linaro connect iirc from the other day
<davmor2> infinity: on dvd once you force the autorun to work you don't have the menu just the installer part of wubi which we definitely don't want
<flexiondotorg> davmor2, ty
<infinity> davmor2: Right, let's pick this conversation up after beta, then, but I think removing it is probably the right thing.
<davmor2> infinity: On windows 7 I'm getting pretty much the same thing, usb pendrives except the EFI partition are no able to run, and dvd triggers the installer not the documentation and menu
<jibel> davmor2, I'd vote to remove it unless someone is motivated to take over the maintenance. Can you file a bug so we don't forget before to address this topic before the release
<jibel> -before
<davmor2> jibel: I thought there already was one let me check
<jibel> I couldn't find it
<flocculant> there was a discussion about this on the -dev m/l
<flocculant> bug 1471344 on there
<ubot93> bug 1471344 in Wubi "The wubi.exe provided on the 15.04 and 15.10 install ISOs" [Undecided,New] https://launchpad.net/bugs/1471344
<infinity> bdmurray: Didn't I reject that apport upload a day or two ago?
<infinity> bdmurray: Oh, or is this based on the security update we weren't stomping on?
<infinity> bdmurray: Indeed it is.
<jibel> flocculant, right, but I don't remember any conclusion and no one really stepped up to maintain it.
 * flocculant neither
<davmor2> jibel, infinity: https://bugs.launchpad.net/wubi/+bug/1499515
<ubot93> Launchpad bug 1499515 in Wubi "Wubi Should be removed from the iso images" [Undecided,New]
<davmor2> flocculant: thanks I couldn't find that
<flocculant> welcome - only remembered cos I saw the thread while looking for something else the other day :)
<flexiondotorg> Misses Laney doing the release because I'd be in the pub by now ;-)
<infinity> flexiondotorg: Hah.
<flexiondotorg> ;-)
<infinity> flexiondotorg: No one's stopping you from being in the pub. ;)
<flexiondotorg> No wifi in the pub.
<flexiondotorg> Rural England.
<flocculant> \o/
<davmor2> flexiondotorg: move to urban england
<wxl> i'm nervous all the flavors are ready but not ubuntu proper. um, we're not going to have another massive respin are we?
<infinity> flexiondotorg: If you want it to go faster, you could do me a favour and copypasta VividVervet/ReleaseNotes to WilyWerewolf/ReleaseNotes and edit all the numbers and delete the bits that aren't relevant. ;)
<infinity> wxl: Nah, just that no one's marked it.  I'll do so before I release.
<wxl> infinity: ok, cool. just checking. take your time on release notes and what have you then ;)
<flocculant> flexiondotorg: and if you do - could you remember that Xubuntu has nothing to do with Mate ... ;)
<flexiondotorg> flocculant, Thank you.
<flexiondotorg> Just about to eat.
<flocculant> :D
<flexiondotorg> I'll check the relnote after my roast beef :-)
<flexiondotorg> davmor2, Urban. No thank you :-)
<flexiondotorg> infinity, Seriously. I am about to eat. I'll check the notes in a sec.
<flexiondotorg> Not a sec.
<flexiondotorg> After eaating.
<davmor2> flexiondotorg: then stop grumbling about your pub :P
<flexiondotorg> I'm not grumbling.
<flexiondotorg> My house is connected to the Internet via shortwave radio.
<flexiondotorg> The pub is not.
<flexiondotorg> Perfect solitude and lots of whiskey.
<davmor2> flexiondotorg: that's kinda like me at the weekend mifi in the caravan in the middle of nowhere
<flexiondotorg> :-)
<oSoMoN> hi release team
<oSoMoN> could someone ack the webbrowser-app sync that is sitting in the unapproved queue, please?
<infinity> oSoMoN: Shortly.
<oSoMoN> infinity, thanks
<jibel> davmor2, if can you had the issues you found to https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes#Known_issues ?
<jibel> davmor2, or give me the bug # (again) I'll update the notes
<davmor2> jibel: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1498074 https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1481798 (upgrades only) https://bugs.launchpad.net/dell-sputnik/+bug/1499323 https://bugs.launchpad.net/wubi/+bug/1499515
<ubot93> Launchpad bug 1498074 in bcmwl (Ubuntu) "Package is not being installed if you install from a usb pendrive created from disks" [Critical,In progress]
<ubot93> Launchpad bug 1481798 in modemmanager (Ubuntu) "package:modemmanager:1.4.10-1:subprocess installed post-installation script returned error exit status 100" [Critical,Triaged]
<ubot93> Launchpad bug 1499323 in Release Notes for Ubuntu "EFI is wiped on wipe whole disk and install" [Undecided,New]
<ubot93> Launchpad bug 1499515 in Wubi "Wubi Should be removed from the iso images" [High,New]
<flocculant> jibel: if you're editing that still - Xubuntu notes are at https://wiki.ubuntu.com/WilyWerewolf/Beta2/Xubuntu
<jibel> flocculant, yup, I updates the links to the release notes of the flavors
<jibel> davmor2, is bug 1499323 specific to the XPS or all EFI systems?
<ubot93> bug 1499323 in Release Notes for Ubuntu "EFI is wiped on wipe whole disk and install" [Undecided,New] https://launchpad.net/bugs/1499323
<davmor2> jibel: Dell for sure, it didn't effect mac or my other laptop, but has effected my asus main pc before now
<jibel> infinity, release notes for wily created. I updated the 'known issues' but the 'new features' section is completely irrelevant for wily
<flexiondotorg> infinity, You still need those relnotes editting?
<jibel> flexiondotorg, it's there https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes , download links are wrong and new features too
<flexiondotorg> Yeah, I spotted that.
<flexiondotorg> jibel, Thanks for the link.
<flexiondotorg> Umm, OK.
<jibel> flexiondotorg, I'm fixing the download links
<flexiondotorg> jibel, Cool.
<flexiondotorg> So, it is the new features bit then,
<flexiondotorg> Tricky.
<flexiondotorg> infinity, Are these release notes intended for Beta 2? Will there be an RC?
<flexiondotorg> I'll be bck in a bit.
<flexiondotorg> Just need to eplain to the family I'm going to be absent for a bit...
<infinity> flexiondotorg: The release notes carry forward all the way to release.  We just add/remove bits as necessary.
<flexiondotorg> Back.
<flexiondotorg> jibel, You still here?
<infinity> flexiondotorg: https://help.ubuntu.com/community/VividUpgrades could use the same treatment.  Having a heck of a time even logging in over this connection.
<infinity> jibel: ^-- Do you know who has ACLs to add WilyUpgrades to help.u.c?
<infinity> davmor2: ^
<infinity> balloons: ^
<flexiondotorg> infinity, I'm going to start on the release notes now.
<flexiondotorg> I might have to trim them way back.
<infinity> flexiondotorg: My usual tact is "fix all the URLs and version references" and then "empty out the sections where everytihng is a lie now".
 * flexiondotorg purges the lies
<infinity> flexiondotorg: Don't delete sections or anything, just empty out content that's irrelevant, leaving a skeleton behind.
<infinity> flexiondotorg: I'm giving myself a hard deadline of 90m from now to finish this up, since there's a session I need to attend then.  So, if you don't mind a midnight beer, you might sneak one in. :P
<infinity> flexiondotorg: (Not that you have to be around for the release, mind you, except if you're trying to time an announcement to match mine or something)
 * flexiondotorg is doing his best to help :-)
 * flexiondotorg has wine
<jibel> infinity, I don't know and it doesn't let me in
<jibel> infinity, apparently I can edit it
<jibel> infinity, https://help.ubuntu.com/community/WilyUpgrades
<jibel> flexiondotorg, in doubt comment the content instead of deleting it
<flexiondotorg> jibel, OK.
<flexiondotorg> jibel, What comment syntax does this wiki support?
<jibel> flexiondotorg, cannot remember, I usually use the link to the help under the edit area
<infinity> jibel: Brilliant, thanks.
<flexiondotorg> jibel, infinity I have no idea if someof the stuff I'm commenting out is genuine or not.
<infinity> flexiondotorg: Meh, just wing it.  We can clean up before final.
<flexiondotorg> infinity, Nearly done.
<infinity> flexiondotorg: Mentioning the ubi-timezone crasher in known issues might be nice.  Not sure if anything else is so horribly user-face that it's worth adding.
<infinity> launchpad.net/bugs/1462688
<flexiondotorg> wilco
<infinity> flexiondotorg: Apparently, the suspected workaround is to install without a network connected.
<flexiondotorg> ANd click continue anyway
<balloons> infinity, I don't know who has perms to update help.u.c
<infinity> flexiondotorg: Yeah, evidently "just click continue" doesn't work on all flavours, hence the "don't have a network at all to avoid the crash" thing.
<infinity> balloons: Evidently, jibel does. ;)
<infinity> balloons: I might, but SSO kept timing out, so I have no idea.
<flexiondotorg> ack
<balloons> ahh
<flexiondotorg> infinity, jibel Cast an eye over this - https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes
<infinity> flexiondotorg: Indentation error in the boot/install section.
<infinity> flexiondotorg: (the usb-creator bug became a sub-clause of the previous one)
<popey> compiz not bold
<flexiondotorg> popey, Edits welcome.
<popey> kk,
 * popey edits
<flexiondotorg> popey, Please do refine the mark up.
<infinity> flexiondotorg: Generally looks fine, though.  Thanks.
<flexiondotorg> I hacked through that very quickly.
<popey> sure, np
<flexiondotorg> infinity, Least I could do.
<flexiondotorg> I owe you :-)
 * infinity waits for his case of cider in the mail.
<flexiondotorg> I may have commented out some legit stuff but I have not way of knowing for sure.
<infinity> flexiondotorg: Lots more eyes will go over it between beta and release, so we'll get it better.
<flexiondotorg> infinity, If/when I do the community round up in the future I'll have them update that as we go.
<flexiondotorg> Because we can get a decent first draft that way.
<infinity> flexiondotorg: Yeah, it would be ideal to create it on the first Alpha and go from there.
 * flexiondotorg nods
 * flexiondotorg get more wine.
 * popey stops editing
<popey> ooh, one more
<infinity> flexiondotorg: Which is more or less what we did when Ubuntu participated in Alphas, but then we stopped. :P
 * flexiondotorg refreshes
<popey> flexiondotorg: and again
<flexiondotorg> ack
<infinity> I'd still prefer talking flavours out of doing more milestones than they need, but I understand the argument that for smaller flavors, milestones are their only rallying point for cadenced testing, so it's hard to get rid of them.
<flexiondotorg> infinity, Yeah, it's tricky.
<flexiondotorg> I got some excellent feedback in alpha1/2 I missed myself.
<flexiondotorg> That is a discussion for another day.
<infinity> flexiondotorg: See, if I ran a flavour, I *think* what I'd do is let some tech lead declare "this week, our flavour looks alright, so this week's dailies, our goal is to test and drive the bugs to 0".
<flexiondotorg> Anything else I can do to help?
<infinity> flexiondotorg: Repeat process a couple of times between open and final.
<flexiondotorg> infinity, That's a nice idea. But having hard deadlines focuses the volunteers.
<flexiondotorg> So, what else?
<infinity> flexiondotorg: alphas and betas basically do that, but with the added annoyance of also releasing a "blessed" image, which I think is a mistake.  Cause then people install from that image for the next month, instead of using dailies that are probably better. :P
<infinity> flexiondotorg: I think we're basically good.  I'm polishing up the mechanical publishing bits, then I copy and waste last cycle's release accounce, and we're off.
<flexiondotorg> I'm going to drain this bottle of wine soon and my usefulness will significantly diminish ;-
<flexiondotorg> infinity, You mean the Beta 2 release announcement?
<flexiondotorg> You want to reuse?
<infinity> flexiondotorg: I always reuse them.  I'm lazy. :P
<flexiondotorg> Sorry, reuse Beta 1 annouce
<flexiondotorg> OK.
<flexiondotorg> I made some typos.
<infinity> flexiondotorg: No, no.  I reuse Beta 2 from last cycle.
<flexiondotorg> OK. Good.
<flexiondotorg> My errors are not there.
<infinity> flexiondotorg: With minor editing, of course.
<flexiondotorg> popey, Thanks for pitching in.
<popey> np
<infinity> flexiondotorg: On the topic of the evil of "blessed images" though, I'd even like to see Ubuntu proper stop doing Beta2/FinalBeta/whatever for that same reason.
<infinity> For the next month, we'll have people who insist on installing from that image and whining about the bugs, when the daily from two days from now will have those bugs fixed.
<flexiondotorg> If you don't have the late betas people won't test them.
<infinity> It's a double-edged sword, yes.
<flexiondotorg> Then you final build quality will suffer.
<flexiondotorg> I admit perhaps Alpha 1 is not so useful.
<infinity> Though most of my good bugs come from people like jibel and davmor2, who I'm pretty sure I could convince to test even without a deadline milestone.
<infinity> flexiondotorg: The point of alpha1 in early Ubuntu days was just to prove "holy crap, it builds".
<flexiondotorg> infinity, You can't rely on a few commited people.
<flexiondotorg> For example, popey for a bug in MATE.
<flexiondotorg> None of the 7 MATE developers could reproduce it.
<infinity> flexiondotorg: it used to take us that long to get from new series to debian sync/import to an image actually building.
<flexiondotorg> A quirk of hardware.
<popey> \o/
<infinity> flexiondotorg: Now, though, we tend to have images building for series+1 the day after series releases. :P
<popey> I win at oddball bug finding
<popey> where's my medal!
<flexiondotorg> So you need a spread.
<flexiondotorg> I gave them to you yesterday. Look at Samantha ;-)
<infinity> flexiondotorg: Oh, I know.  Trust me, I know the value of manual testing.  Especially by people who do weird stuff. ;)
<flexiondotorg> popey, You can't make software fool proof.
<flexiondotorg> Because fools are so ingenious ;-)
<infinity> (And by "weird stuff", I don't mean anything actually weird, just people who don't mechnically run through exact testcases on a wiki)
<flexiondotorg> infinity, Yep. Agree.
<flexiondotorg> I have 4 or 5 committed testers for Ubuntu MATE.
<flexiondotorg> They really pick away at stuff.
<flexiondotorg> They a golden.
<infinity> Historically, apw would always find some awful bug every cycle during release week, by *gasp* just using a fresh install. :P
<flexiondotorg> *They are
<flexiondotorg> I love that kind of commitment. Saves me so much time.
<flexiondotorg> infinity, I did that early this time.
<flexiondotorg> Did fresh installs of the dailies on all the hardware on Monday.
<flexiondotorg> Found loads of issues.
<infinity> Yeah.  Software is terrible.  We should stop using it.
<flexiondotorg> I have some new upload in Debian I'll be requesting a sync for soon and an update to 3 packages in Ubuntu.
<flexiondotorg> infinity, Right. Are you going to make your session?
<infinity> flexiondotorg: I've still got half an hour.  It's a short walk. :P
<flexiondotorg> OK :-)
<rcj> infinity, time for cloud images to start replication?
<infinity> rcj: You can pull the trigger anytime.
<rcj> infinity, excellent.  Thanks
<infinity> rcj: Also, yay timing.  I was typing that when you asked. :P
<rcj> infinity, I was just catching up on the channel backlog to make sure I wasn't asking a question with an obvious answer
<infinity> rcj: I just pulled the trigger on cdimage and releases, so perfect time for you to be doing the same and crippling the world. ;)
<infinity> rcj: Announce will go out in ~30m.
<rcj> infinity, excellent.  let the infrastructure melt a bit
 * flexiondotorg is standing by
 * infinity is arguing with the wiki.
<infinity> Might have to finish this from downstairs.  WiFi in the rooms seems crippled.
<Ukikie> Wiki'll win.
<infinity> Ukikie: It would seem you're right...
<infinity> flexiondotorg: Okay, I underestimated.  Mirrors are still syncing. :P
<flexiondotorg> infinity, I'm still here.
<flexiondotorg> So, the release process is running.
<flexiondotorg> Just announcement emails left and syncing to complete?
<infinity> Yeahp.
<flexiondotorg> Great.
 * flexiondotorg mashes F5 ;-)
<infinity> flexiondotorg: Alright, mail going out.
<flexiondotorg> infinity, Great
<flexiondotorg> Enjoy your conference.
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Beta 2 | Archive: feature freeze | Wily 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
#ubuntu-release 2015-09-25
<jamespage> ^^ that's only a minimal diff in the upstream codebase despite the version bump - and is needed for all of the rc's for openstack packages we're working in in debian and ubuntu
<Laney> Mirv: What investigation of these unrelated failing tests did you do before deciding to skip them?
<Mirv> Laney: they were OpenGL tests that failed on armhf only (and ran under software emulation on the builder under xvfb). if you want I could file a bug about making the skipping only on armhf.
<Mirv> but since the patch touched networking and it's not too long since the last qtbase rebuild, the appearing failure is most likely due to changes in that software OpenGL on armhf
<Laney> you consider it acceptable for this to be broken?
<Laney> did you talk to tjaalton?
<Mirv> Laney: yes, the OpenGL software emulation on armhf is hardly the most tested code path of Qt / Mesa and Qt more or less assumes hw acceleration and modern drivers (but I try to run most OpenGL tests anyhow)
<Mirv> qtbase tests are a bit hard nut for our headless software rendering builders, that's why the original QA enablement resulted in a huge patch and Debian doesn't run the tests at all
<Laney> It's a bit odd isn't it
<Mirv> no pinging of the other timo before the above
<Laney> We run the tests as long as they work - and if they don't, then we disable them
<tjaalton> pong :)
<Mirv> Laney: it's useful to run as many tests as possible, still a big amount of them, to catch clear regressions. but problematic tests with a code path that is not used in real life doesn't bring that much value.
<flocculant> infinity: just a thought re your milestone words - if flavours could start and stop builds - then we'd keep the goodness of having something people can test - but lose the 'blessed build' stigma
<jamespage> slangasek, hey - would you have time to review the dpdk package in the NEW queue for wily?
<jamespage> I also need to upload a cut-down openvswitch-switch-dpdk package to support this objective for wily, but I'm a bit blocked right now
<slangasek> jamespage: on vacation this week and driving much of today; I'll see if I can give it any useful review but stgraber is probably your best bet after all
<Laney> stgraber: someone: second opinion on doing https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442 ?
<stgraber> Laney: any ETA on the proper fix (getting network-manager fixed)?
<Laney> stgraber: awe_ apparently missed the bug assignment so is only working on it starting now-ish - which means probably not incredibly soon
<stgraber> so stupid question, but why didn't boottest find that issue and cause network-manager to be held to begin with?
<stgraber> in theory we could simply have removed the broken network-manager from proposed and be done with this
<Laney> 25/09 17:49:20 <fginther> There have been no recent boottest passes for network manager, but it's unlikely that boottest would have caught the problem as the bug prevents networking, not booting.
<stgraber> ok and what about reverting network-manager in the archive what's the problem with that?
<Laney> And then the boottests got pinned to an earlier image before this NM...
<Laney> which has now evidently expired
<Laney> The release in question seems to be 0.9.10 -> 1.0...
<stgraber> ok, fine, let's merge that then
<Laney> stgraber: I commented - slangasek said in #ubuntu-ci-eng that a product team person should sign off on it
<Laney> I don't actually know who that is apart from pmcgowan who is apparently not here today
<Laney> fginther: any clue?
<Laney> stgraber: Maybe JFDI it in a little while if nobody turns up
<Laney> I've got to EOW now, hopefully you can handle merging it
<Laney> see you
<fginther> Laney, looking
<fginther> Laney, later
<fginther> Laney, stgraber, kgunn can give a +1 on this I believe
<fginther> in pmcgowan's awayness
<slangasek> stgraber, fginther: if the boottests are all now failing because networking is broken, why wouldn't the boottest have caught the failing networking?
<infinity> flocculant: Define "start and stop".  You mean if you could disable the crontab entry?
<infinity> slangasek: Many packages are unboottestable because "mark r/w and run apt" breaks system images miserably in some cases.  Not sure if NM falls in that group, but it might.  We certainly have always had a fairly nontrivially large set of packages where we have to go to the uploader and say "so, did you test this and can you sign off on it, cause the infra can't tell me anything useful".
<slangasek> infinity: that is not what fginther was asserting
<infinity> slangasek: Which, of course, entirely defeats the point of automated testing keeping the uploader honest.
<slangasek> he asserted that this regression would not have been caught because it didn't break the boot
<infinity> slangasek: Oh, that may well be the case for NM specifically.
<infinity> slangasek: Though it doesn't make a lot of sense that if it doesn't break the boot, it then breaks the boot?
 * infinity shrugs.
<infinity> slangasek: Honestly, I see little point in running test infra for people who don't treat breakages in that infra as stop the line events.
<cyphermox> so what's this NM issue?
<fginther> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1496434
<ubot93> Launchpad bug 1496434 in network-manager (Ubuntu) "network-manager crash on boot on krillin/devel-proposed" [Critical,Confirmed]
<cyphermox> fginther: yep, I'm aware
<cyphermox> Tony said he was working on it.
<flocculant> infinity: I guess so. Imagine someone from 'flavour release team' saying stop building my flavour - we're doing a few days testing foo and bar and what to keep that image, when done - start building dailies again
<flocculant> so - no-one would get alphas or betas as such
<flocculant> then close to the end - a global one done by *you*
<infinity> flocculant: Yeah, letting you halt your dailies isn't an unreasonable request.  We could do it if/when we stop building from static cron entries (which is on a TODO, somewhere), but not really doable right now without you just poking someone who has a shell on that computer.
<flocculant> s/what/want
<flocculant> right - so was just a thought following on from your 'blessed image' last night (for me)
<flocculant> there would just be one then - at the end
<flocculant> be one global that is - RC or so
<kgunn> Laney: fginther added approval in lieu of pat
<fginther> stgraber, ^ for https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442
<fginther> kgunn, thanks
<stgraber> merged
<wxl> infinity: are the cron jobs for dailies back on?
#ubuntu-release 2015-09-26
<infinity> wxl: Not yet.
<yofel> contains upstream fixes for a crash in dolphin ^
<flocculant> if anyone who can happens to be about - can the dailies be turned on please :)
#ubuntu-release 2015-09-27
<mparillo_> Is this a valid mirror? http://se.cdimage.ubuntu.com/kubuntu/releases/15.04/release/ If so, where should I direct https://bugs.launchpad.net/bugs/1500010
<ubot93> Launchpad bug 1500010 in Kubuntu Website "15.04 Sweden download mirror URL is broken" [Undecided,New]
<tsimonq2> hey, none of the images are being built for wily automatically anymore...can someone fix that please?
<knome> heya! can somebody tell what the policy for reporting bugs for development releases is? i vaguely remember that bugs are discouraged until some time in the cycle - what might that be?
<flocculant> knome: now's a bit late :D
<infinity> knome: Eh?  There's no policy on when to report a bug, except for "when you find it".
<infinity> knome: There's never a wrong time, but earlier is always better, if you don't want to live with the bug forever. :P
<knome> infinity, i mean i recall there being some kind of policy to not file bugs against some core packages pre-alpha or something
<knome> infinity, maybe i misremember
<teward> infinity: speaking of living with bugs forever, would you care to take a peek at an electrum (bitcoin wallet) SRU (related to the removal-from-wily-and-blacklist one)
<cjwatson> knome: what you're thinking of there is that apport is generally not enabled early in the cycle to avoid lots of automatic reports from an early pre-alpha release
<cjwatson> knome: but that just concerns automatic reports, not manual ones
<knome> cjwatson, that might be it... so does it mean manual reports are always encouraged?
<cjwatson> yes
<knome> because i can see a lot of "obvious" things being reported
<knome> ok, that clears it
<knome> when in the cycle is apport enabled?
<flocculant> was late for this cycle - I'd read the changelog for it
<flocculant> vivid was just after A2
<infinity> knome: Judging when to file automated reports isn't an exact science, but yes, manual reports should always be encouraged, as long as the submitted knows how to file a bug. :P
<knome> infinity, oki. so if it isn't exact science, what's the basic guideline on when that usually happens?
#ubuntu-release 2016-09-26
-queuebot:#ubuntu-release- New binary: linux-signed-lts-vivid [amd64] (trusty-proposed/main) [3.19.0-70.78~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-40.60~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: gcalcli (yakkety-proposed/universe) [3.3.2-2 => 3.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcalcli [sync] (yakkety-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- Unapproved: vkeybd (yakkety-proposed/universe) [1:0.1.18d-2 => 1:0.1.18d-2.1] (ubuntustudio) (sync)
<slangasek> apw: it gated the kernel this time, we just overrode the gate in our haste, heh.
<tsimonq2> slangasek: any way I can help get final beta out the door?
<slangasek> tsimonq2: well, if you can tell me that the -17 ppa kernel works with a d-i-based installer... :)
<tsimonq2> slangasek: what PPA?
<slangasek> tsimonq2: the kernel team ppa
<slangasek> I don't have the link handy, sorry
<slangasek> mwhudson: accepted
-queuebot:#ubuntu-release- New: rejected docker.io [amd64] (xenial-proposed) [1.12.1-0ubuntu7~16.04]
-queuebot:#ubuntu-release- New: accepted docker.io [amd64] (xenial-proposed) [1.12.1-0ubuntu12~16.04.1]
<tsimonq2> slangasek: oh, you mean ppa:canonical-kernel-team/ppa that I've had enabled on my production system for a month now? :P
 * tsimonq2 runs
<slangasek> so what you're saying is, you're dogfooding it but found none of the critical bugs that blocked the beta ;)
<slangasek> (which is understandable, they were mostly installer-critical only)
<tsimonq2> well I wasn't looking for any bugs...
<tsimonq2> lol ok
<tsimonq2> slangasek: define "works," any specific bugs I should hunt for?
<slangasek> tsimonq2: if you can install Ubuntu Server from an image built using that kernel, it works
<tsimonq2> slangasek: you have instructions for either building a d-i image using that PPA or adding that PPA and upgrading the image handy?
<slangasek> tsimonq2: heh... nope
<tsimonq2> fun, ok, I'll mess around
<mwhudson> slangasek: thanks
<slangasek> tsimonq2: or you can wait until that kernel is in -proposed, at which point I'll probably build a PROPOSED=1 image so we can test in parallel to autopkgtest
<tsimonq2> slangasek: what would the ETA be on that?
<mwhudson> slangasek: thanks
<slangasek> tsimonq2: "Monday"
<tsimonq2> good stuff, ok
<mwhudson> slangasek: did we talk about deleting containerd from xenial-updates already?
<slangasek> uh... I don't think so
<mwhudson> slangasek: *powerpc
<mwhudson> slangasek: according to my email i got you to delete it from yakkety, but not clear if we talked about xenial-updates too ...
<slangasek> mwhudson: ok, removing
<mwhudson> slangasek: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted hplip [source] (yakkety-proposed) [3.16.7+repack0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cowdancer (yakkety-proposed/universe) [0.80ubuntu1 => 0.81] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cowdancer [sync] (yakkety-proposed) [0.81]
-queuebot:#ubuntu-release- Unapproved: cowdancer (yakkety-proposed/universe) [0.81 => 0.81ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cowdancer [source] (yakkety-proposed) [0.81ubuntu1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Beta 2] has been updated (20160921)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Beta 2] has been updated (20160921)
-queuebot:#ubuntu-release- Unapproved: ruby-sys-filesystem (yakkety-proposed/universe) [1.1.7-1ubuntu1 => 1.1.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-sys-filesystem [sync] (yakkety-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- Unapproved: ubuntuone-credentials (yakkety-proposed/universe) [15.11+16.10.20160805.2 => 15.11+16.10.20160920] (ubuntuone) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntuone-credentials [sync] (yakkety-proposed) [15.11+16.10.20160920]
-queuebot:#ubuntu-release- Unapproved: tor (yakkety-proposed/universe) [0.2.8.7-1ubuntu1 => 0.2.8.8-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tor [source] (yakkety-proposed) [0.2.8.8-1ubuntu1]
<LocutusOfBorg> good morning, cjwatson_ I don't remember how I can get PAGE_SIZE on ppc64el, I remember you told me "look at this build log", but I don't remember which package was it
<LocutusOfBorg> procenv
<LocutusOfBorg> thanks :)
<LocutusOfBorg> having a search box for irclogs.ubuntu.com would be awesome, they seems to be not completely indexed by google?
-queuebot:#ubuntu-release- Unapproved: python-markdown (yakkety-proposed/universe) [2.6.6-1 => 2.6.7-1] (edubuntu) (sync)
<mardy> pitti: hi! Can you use your magic powers on https://bileto.ubuntu.com/#/ticket/1497 ?
-queuebot:#ubuntu-release- Unapproved: blends (yakkety-proposed/universe) [0.6.93ubuntu1 => 0.6.94ubuntu1] (no packageset)
<pitti> mardy: err, I added some magic glow to it and the page is now 10% more magical
<pitti> mardy: what do you want me to do? :-)
<pitti> (tests seem alright)
-queuebot:#ubuntu-release- Unapproved: accepted blends [source] (yakkety-proposed) [0.6.94ubuntu1]
<mardy> pitti: make it 20% ;-) I just wonder if I should be quietly waiting for the UNAPPROVED packages to be approved, or if I should ping here and there :-)
<pitti> mardy: oh, that; yakkety is frozen, I cannot circumvent that
<pitti> mardy: well, *technically* I can, but infinity1 would rightfully get very angry :)
<pitti> I might even still approve them from the queue, but they still won't land in y-release until after the beta release
-queuebot:#ubuntu-release- Unapproved: python-llfuse (yakkety-proposed/universe) [1.1.1+dfsg-2 => 1.1.1+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-llfuse [sync] (yakkety-proposed) [1.1.1+dfsg-3]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-vivid [amd64] (trusty-proposed) [3.19.0-70.78~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-40.60~14.04.1]
-queuebot:#ubuntu-release- Unapproved: debian-games (yakkety-proposed/universe) [1.4ubuntu1 => 1.5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted debian-games [source] (yakkety-proposed) [1.5ubuntu1]
-queuebot:#ubuntu-release- New binary: debian-games [amd64] (yakkety-proposed/universe) [1.5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-llfuse (yakkety-proposed/universe) [1.1.1+dfsg-3 => 1.1.1+dfsg-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-llfuse [source] (yakkety-proposed) [1.1.1+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: thermald (yakkety-proposed/main) [1.5.3-3 => 1.5.3-4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: psi4 (yakkety-proposed/universe) [1:1.0~rc-3 => 1:1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted psi4 [sync] (yakkety-proposed) [1:1.0-1]
-queuebot:#ubuntu-release- Unapproved: espresso (yakkety-proposed/universe) [5.4.0+dfsg-1 => 5.4.0+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted espresso [sync] (yakkety-proposed) [5.4.0+dfsg-5]
-queuebot:#ubuntu-release- Unapproved: arc-theme (yakkety-proposed/universe) [20160605-2build1 => 20160923-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted arc-theme [sync] (yakkety-proposed) [20160923-1]
-queuebot:#ubuntu-release- Unapproved: networking-odl (yakkety-proposed/universe) [1:2.0.0+git20160906.d6c362d-0ubuntu1 => 1:2.0.1~git20160926.416a5c7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-odl [source] (yakkety-proposed) [1:2.0.1~git20160926.416a5c7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-taas (yakkety-proposed/universe) [0.0.0+git20160808.c612a729-1 => 0.0.0+git20160926.675af77-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-taas [source] (yakkety-proposed) [0.0.0+git20160926.675af77-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fityk (yakkety-proposed/universe) [1.2.1-0.1ubuntu4 => 1.2.1-0.1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fityk [source] (yakkety-proposed) [1.2.1-0.1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: console-setup (yakkety-proposed/main) [1.142ubuntu4 => 1.142ubuntu5] (core)
<dobey> hi, can someone prod unity-scopes-api and unity-scopes-shell through UNAPPROVED queue in yakkety? not sure why they got picked up there, as it seems they're still in universe
-queuebot:#ubuntu-release- Unapproved: btrfs-progs (yakkety-proposed/main) [4.7-1 => 4.7.3-1] (no packageset) (sync)
<apw> dobey, they do show up in seeded-in-ubuntu output which i beleive is what is stopping them auto accepting
<dobey> apw: right but i think they haven't been pulled in the ISO yet. the fixes in the queue are for the MIR
<pitti> dobey: I'll do a round of unapproved review now
-queuebot:#ubuntu-release- Unapproved: accepted gnome-chess [sync] (yakkety-proposed) [1:3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted quadrapassel [sync] (yakkety-proposed) [1:3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tetravex [sync] (yakkety-proposed) [1:3.22.0-1]
<dobey> pitti: ok thanks
-queuebot:#ubuntu-release- Unapproved: rejected account-plugins [sync] (yakkety-proposed) [0.13+16.10.20160831-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (yakkety-proposed) [1.142ubuntu5]
-queuebot:#ubuntu-release- Unapproved: kactivities-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<slangasek> apw, ogasawara: hi, what do we need to do to get linux 4.8.0-17.18 into yakkety-proposed ASAP?
<slangasek> apw, ogasawara: I can spin a PROPOSED=1 Ubuntu Server image for testing (assuming the rest of the archive is adequately coherent) so we can do that in parallel with the autopkgtests this time
<slangasek> we'll need linux-signed, we'll need d-i - are those staged/uploaded/todo?
<ogasawara> slangasek: yes, I've staged those in the ppa as well, so I can copy all 3 out to proposed
<ogasawara> slangasek: just wanted to make sure you were +1 before I did so
<slangasek> ogasawara: ok; +1 :)
<apw> ogasawara, there is no d-i in there
<apw> ogasawara, i can sort that out, once we can upload again
<ogasawara> apw: argh
<apw> ogasawara, and you can't copy them out ... without launchpad
<ogra_> just send USB sticks by mail
<ogasawara> apw: ass, right
<apw> but i will sort out d-i ready to go
<apw> _if_ i can get to the branch
<ogasawara> apw: I don't think you can
<ogasawara> apw: I couldn't get to our kernel git repo's earlier
<apw> *assume*lots*of*swearing*
<slangasek> apw: the "P" part of "ASAP"
<infinity> apw: I'm unconvinced that copying d-i from a PPA will dtrt (though, it probably might?), uploading to the archive after the kernel is copied seems less scary.
<apw> infinity, will do
<apw> infinity, i was assuming i would copy it sans -b though
<infinity> apw: And whoever copies linux-signed, make sure to not copy with binaries. :P
<ogasawara> copy-package --from ppa:canonical-kernel-team/ubuntu/unstable --suite yakkety --to ubuntu --to-suite yakkety-proposed -b linux linux-meta
<ogasawara> that is what I was going to run ^^
<infinity> (I know you know that, I'm less convinced about everyone else)
<apw> infinity, i have shouted that bit just recently :)
<infinity> ogasawara: That would do, and then the same for linux-signed, minus the -b
<infinity> apw: Heh.
<ogasawara> copy-package --from ppa:canonical-kernel-team/ubuntu/unstable --suite yakkety --to ubuntu --to-suite yakkety-proposed linux-signed
<ogasawara> yes, and then that for linux-signed
<rtg> is there a way to make ISO images in a PPA ? (once LP comes back up)
<infinity> rtg: No.
<rtg> infinity, how about locally ? It would sure speed testing of boot essential issues.
<infinity> rtg: Not easily.
<infinity> rtg: Though, for issues that aren't specific to "the CD", mini.iso from d-i works, and is easily built locally.
<slangasek> rtg: locally, it's step 1) create a local mirror of the Ubuntu archive, step 2) modify the mirror to inject your kernel, step 3) run debian-cd machinery; so it's going to be quicker for us to iterate through yakkety-proposed
<rtg> if I can select what kernel to build in, then that would do it
<infinity> rtg: Would it (in this case)?  I thought the issues were related to accessing the ISO filesystem, not booting.
<rtg> slangasek,  this time, yes. I'm looking out to the next cycle
<infinity> Which mini.iso certainly tests less well.
<slangasek> the blocking issues we've had have been with the alternate CDs, so yeah, mini.iso doesn't really help
<infinity> But yes, for strictly boot issues, you can do a local d-i quite easily.
<rtg> infinity, boot issues were the ones killing us on the kernel
<slangasek> rtg: that's not what was killing /us/
<infinity> rtg: Honestly, the best way to test boot issues is to have a VM kicking around that you install your kernel in and reboot...
<infinity> rtg: Installers seem a silly way to test that.
<infinity> Unless you need a lightweigh way to toss something around to boot test specific hardware, I guess.
<infinity> rtg: Anyhow, yes, you can build d-i in a PPA or locally, and it spits out both a kernel/initrd pair to use raw, and a mini.iso, just nothing as fancy as a full server ISO.
<rtg> infinity, I can live with that. I was just looking back through our config changes to see what would _really_ require an install image.
-queuebot:#ubuntu-release- Unapproved: linux (yakkety-proposed/main) [4.8.0-16.17 => 4.8.0-17.19] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (yakkety-proposed/main) [4.8.0.16.26 => 4.8.0.17.27] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (yakkety-proposed/main) [4.8.0-16.17 => 4.8.0-17.19] (core, kernel) (sync)
<ogasawara> slangasek, infinity, apw, rtg: ^^ linux, linux-meta, and linux-signed are copied out
<pitti> ooh
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu477 => 20101020ubuntu478] (core)
 * pitti accepts
<apw> pitti, hold the d-i though
<pitti> now that I actually can again :)
-queuebot:#ubuntu-release- Unapproved: accepted account-plugins [sync] (yakkety-proposed) [0.13+16.10.20160831-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted signon-plugin-oauth2 [sync] (yakkety-proposed) [0.24+16.10.20160818-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings-online-accounts [sync] (yakkety-proposed) [0.7+16.10.20160830.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (yakkety-proposed) [1.4.1+16.10.20160914-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted tali [sync] (yakkety-proposed) [1:3.22.0-1]
<pitti> apw: hold or reject?
<apw> pitti, leave it in the queue
<pitti> ack
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (yakkety-proposed) [4.8.0.17.27]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (yakkety-proposed) [4.8.0-17.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (yakkety-proposed) [4.8.0-17.19]
 * apw will handle that once the other bits make it to the right places
<pitti> apw: why, OOI? needs to wait for kernel to publish? (that should be a build-dep?)
<apw> it shoudl be, but its definatly not :)
-queuebot:#ubuntu-release- Unapproved: accepted btrfs-progs [sync] (yakkety-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted thermald [sync] (yakkety-proposed) [1.5.3-4]
-queuebot:#ubuntu-release- Unapproved: accepted vkeybd [sync] (yakkety-proposed) [1:0.1.18d-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-markdown [sync] (yakkety-proposed) [2.6.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (yakkety-proposed) [16.10.9]
-queuebot:#ubuntu-release- Unapproved: accepted signon-plugin-oauth2 [sync] (yakkety-proposed) [0.24+16.10.20160818-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected unity-scopes-api [sync] (yakkety-proposed) [1.0.7+16.10.20160921-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings-online-accounts [sync] (yakkety-proposed) [0.7+16.10.20160830.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu477 => 20101020ubuntu478] (core)
<pitti> apw: a second d-i with the same version just hit the queue; I take it I shuld kill the older one?
<apw> pitti, they are identicle, pain from the outage and us retrying
<pitti> ah, ok
<apw> wack either
<apw> (and thanks for all that)
-queuebot:#ubuntu-release- Unapproved: rejected debian-installer [source] (yakkety-proposed) [20101020ubuntu478]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-backgrounds [sync] (yakkety-proposed) [3.22.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-scopes-shell [sync] (yakkety-proposed) [0.5.8+16.10.20160921-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-scopes-api [sync] (yakkety-proposed) [1.0.7+16.10.20160921-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted atomix [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gsfonts [sync] (yakkety-proposed) [1:8.11+urwcyr1.0.7~pre44-4.3]
-queuebot:#ubuntu-release- Unapproved: accepted gpsd [sync] (yakkety-proposed) [3.16-3]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [source] (yakkety-proposed) [176+git1]
-queuebot:#ubuntu-release- Unapproved: accepted qtquickcontrols-opensource-src [sync] (yakkety-proposed) [5.6.1-3]
-queuebot:#ubuntu-release- Unapproved: rejected thermald [sync] (yakkety-proposed) [1.5.3-4]
-queuebot:#ubuntu-release- Unapproved: accepted tickcount [source] (yakkety-proposed) [0.1-0ubuntu18]
-queuebot:#ubuntu-release- Unapproved: accepted zeromq3 [sync] (yakkety-proposed) [4.1.5+git20160811+2fc86bc-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted zmqpp [sync] (yakkety-proposed) [4.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-8-g0439d8a-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ghostscript [source] (yakkety-proposed) [9.19~dfsg+1-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (yakkety-proposed) [1.1.15-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu8 => 229-4ubuntu9] (core)
<dobey> huh
<apw> dobey, ?
<dobey> apw: saw unity-scopes-api rejected, but then saw it was accepted
<dobey> apw: but ci train shows rejected still. hopefully it fixes itself soon
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.14 => 1.0.1ubuntu2.15] (core)
<apw> dobey, ubuntu2 got accepted, ubuntu1 was superceeded, which is the silo waiting for
<dobey> apw: ugh, there was a manual re-upload then?
<dobey> ah
<apw> dobey, that i don't know, there was cirtainly two versions and the newer one got accepted the previous one rejected
<dobey> yes, sil2100 did it
<dobey> thanks
<apw> ahh yes, a no-change rebuild for a transition
<slangasek> apw: so the sequence here is: linux and linux-meta publish to yakkety-proposed; linux-signed builds and publishes to yakkety-proposed; you release d-i from unapproved; it builds and publishes; and I trigger a cdimage build with PROPOSED=1 ?
<apw> slangasek, yes
<slangasek> ok
<slangasek> apw: trigger set on nusakan, ubuntu-server image build will start as soon as the new d-i hits the archive
<apw> slangasek, nice thanks
<balloons> good morning infinity. Can you review this SRU for landing into xenial? https://bugs.launchpad.net/ubuntu/+source/juju-mongodb3.2/+bug/1605976.
<ubot5> Ubuntu bug 1605976 in juju "[2.0] bump mongod to 3.2.9" [High,Triaged]
<slangasek> balloons: infinity is at Linaro Connect this week, so probably has only intermittent availability
<slangasek> (just setting expectations, not offering to do it in his stead, sorry - Final Beta takes precedence today)
<balloons> slangasek, ack ty :-) No worries, I assume it wasn't picked up because of the failing builds
<balloons> bdmurray, might you have a moment today to have a look at bug 1605976 for landing into xenial?
<ubot5> bug 1605976 in juju "[2.0] bump mongod to 3.2.9" [High,Triaged] https://launchpad.net/bugs/1605976
<bdmurray> balloons: bug 1564500 is mentioned as making it hard to do a full CI run, yet there is a comment about using your own apt mirror.  Has that been considered to test the mongod in -proposed?
<ubot5> bug 1564500 in juju "Cannot test packages in proposed or other archives" [High,Triaged] https://launchpad.net/bugs/1564500
<balloons> bdmurray, I prodded the core team for some way we could do this, hence the comment I left on the bug about using an apt mirror. To my knowledge, it has not been tried.
<bdmurray> balloons: Would it require much effort / would it be worth testing that?
<apw> linux-signed
<ChrisTownsend> Ok, now I think libertine has been completely rejected for Yakkety, but I have no idea why: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=4&queue_text=libertine
<apw> 17:10:04*           -- | Notice(queuebot): Unapproved: accepted libertine [sync] (yakkety-proposed) [1.4.1+16.10.20160914-0ubuntu1]
<apw> looks to have been accepted to me
<ChrisTownsend> apw: Why is this so hard for me to figure out??:)
<apw> (it is 18:10 for reference in my client)
<ChrisTownsend> apw: So are we blocked on something to get it out of unapproved?
<ChrisTownsend> apw: LP is very misleading on the states of packages.  I get this for unapproved: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=libertine
<balloons> bdmurray, I'm not sure an apt mirror would work, but I wanted to note it in the bug in case we needed an option before juju-core made updates to allow testing with -proposed properly. Speaking personally my thought was to make use of it if I didn't feel confident or we wanted to jump releases (like 3.2 -> 3.3 or 4). Given this is a point release, I'm satisfied with the testing done
<apw> ChrisTownsend, right that queuebot message says that became accepted in the unapproved queue, from there it should go into the archive, but as you say i do not see it in the +source page
<ChrisTownsend> apw: Ok, so I'm not totally bonkers on this:)
<bdmurray> balloons: If I were to release it, could you test it after the fact to be extra satisfied? ;-)
<balloons> bdmurray, absolutely. Part of my desire for it to go in is so we get full CI testing and field testing before juju goes to final
<balloons> the field testing bit is the bigger piece; people won't get it for real deploys until it's in. From a CI perspective, I expect no surprises. In the field, I also don't expect any surprises to be fair; instead I'm rather hoping to see the promised improvements
<bdmurray> balloons: okay, done
<cjwatson> libertine> That's not within the usual scope of "misleading", though ...
<cjwatson> +source isn't affected by publishing
<cjwatson> I mean, not in terms of existing at all
<ChrisTownsend> cjwatson: Well, I meant what LP was telling me conflicted with what apw was telling me.  I guess it would have been more accurate to say, "this makes no sense to me." :)
<ChrisTownsend> All I know is that libertine is not updated in the Yakkety archive I have no idea why.
<cjwatson> ChrisTownsend: Right, just saying that this isn't a routine thing.  Still trying to work it out.
<cjwatson> I don't know why queuebot said what it did.
<ChrisTownsend> cjwatson: Ok, thanks for your help.
<cjwatson> Oh, I found an OOPS
<cjwatson> "Proxy Error" from the librarian
<cjwatson> signon-plugin-oauth2 and ubuntu-system-settings-online-accounts were similarly affected
<cjwatson> But it looks like they were re-copied
<cjwatson> ChrisTownsend: Can you try just republishing (not rebuilding) libertine?
<cjwatson> from bileto
<ChrisTownsend> cjwatson: I'll get someone with permission too since there are packaging changes.
<ChrisTownsend> *to
<cjwatson> The OOPSes were all around 16:11-16:13 UTC, which is a bit after the network outage ended
<cjwatson> Mysterious
<nacc> would this also be affecting, e.g., my uploads to pacemaker, gsfonts, tickcount ? That are all in 'done', and i got an e-mail, but i don't see them published in -proposed
<nacc> i'm also willing to attribute it to my own misunderstanding(s)
<cjwatson> nacc: That's just the publisher being a bit backlogged/slow, I imagine
<cjwatson> nacc: https://launchpad.net/ubuntu/+source/pacemaker/+publishinghistory looks OK
<nacc> cjwatson: ah ok, thanks!
<nacc> cjwatson: yep, you're right
<ChrisTownsend> cjwatson: I'm asking if anyone on #ubuntu-ci-eng can help.  My go-to guy is out right now:)
<slangasek> ChrisTownsend: generally the people in this channel will have permission, if you want to just post the link (for a "republish" it's trivial)
<ChrisTownsend> slangasek: Ok, here's the link: https://bileto.ubuntu.com/log/1947/publish/  The package is already in the overlay, so I'm not sure what this will do.
<slangasek> ChrisTownsend: if it breaks, we can let robru know the button isn't idempotent :)
<ChrisTownsend> slangasek: lol, ok, works for me:)
<dobey> i don't think republishing will help
<ChrisTownsend> dobey: On #ubuntu-release, they think so.
<slangasek> dobey: libertine didn't make it to the Ubuntu archive, so it ought to
<slangasek> (unless the publish button is not idempotent, in which case that is a bug)
<slangasek> anyway, button has been pushed
<robru> slangasek: ChrisTownsend: publication will skip any packages if the version number isn't higher than destination. Rebuilding & republishing a ticket after it gets stuck in proposed is an officially supported workflow
<dobey> hmm, ok
<slangasek> robru: it should not be rebuilt, this was a launchpad copying failure only
<dobey> yeah, republishing shouldn't make things worse anyway
<ChrisTownsend> lol, I thought I was on a different channel when I said that
<ChrisTownsend> Hopefully it will work.
<ChrisTownsend> slangasek: Thanks
<ChrisTownsend> cjwatson: And thanks to you too
<robru> slangasek: well then republishing will safely only publish things that didn't already publish
<dobey> slangasek: ah ok, if it was just lp going bonkers earlier, then yeah that should hopefully get it resynced and hopefully it can be accepted
<slangasek> robru: good, that's what I like to hear :)
<ChrisTownsend> It was on Sept. 22 that this occured.
<cjwatson> No
<cjwatson> The initial copy request was then, but it was held in a queue and only attempted-to-be-accepted earlier today
<ChrisTownsend> cjwatson: Ah, ok, that makes sense.
<slangasek> mterry: there's a stack of Fix Committed MIRs listed under (unsubscribed) on http://people.canonical.com/~ubuntu-archive/component-mismatches; can you help sort some of these subscribers out?
<slangasek> mterry: (I can subscribe teams as necessary if the correct subscriber is known)
<slangasek> e.g. https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1552860
<ubot5> Ubuntu bug 1552860 in qtsystems-opensource-src (Ubuntu) "[MIR] qtsystems-opensource-src" [Undecided,Fix committed]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (yakkety-proposed) [0.96.24.7]
-queuebot:#ubuntu-release- Unapproved: libertine (yakkety-proposed/main) [1.4+16.10.20160908-0ubuntu1 => 1.4.1+16.10.20160914-0ubuntu1] (no packageset) (sync)
<robru> slangasek: there's your copy
<mterry> slangasek: OK here're my guesses: indicator-transfer gets dx-packages (like other indicators).  location-service, zeromq3, and network-manager-openvpn get desktop-packages (they have desktop-bugs instead -- this is my fault for confusing those two during MIRs I suppose).  unity-notifications gets unity-ui-team.  qtsystems-opensource-src gets ubuntu-sdk-bugs.
<slangasek> robru: yup :)
<slangasek> mterry: are these "guesses" that you're willing to put those teams on the hook for? :)
<mterry> slangasek: I haven't talked to the teams, but they are all reasonable picks with similar packages under their belts
<mterry> The only one I'm even a little iffy on is the last sdk one
<mterry> But it makes sense to me...
<slangasek> mterry: ok.  subscribing, and if someone balks we can sort it out later
<slangasek> mterry: thanks :)
<mterry> yw, my bad in the first place for most  :)
<tsimonq2> slangasek: how's "Monday" coming along? ;)
<slangasek> tsimonq2: kernel publication to -proposed is in progress; apw needs to upload debian-installer once that's finished; then we will build an ubuntu-server test image (not a release candidate) against proposed.
<tsimonq2> awesome!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-17.19] (core, kernel)
<tsimonq2> slangasek: *slides Lubuntu hat on* are we getting a respin of alternate images then?
<slangasek> tsimonq2: we will, but I was going to stick with ubuntu-server for testing
<tsimonq2> ok, good stuff
<tsimonq2> (right acheronuk? :P)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-17.19]
<tsimonq2> slangasek: I assume that's what is coming in now? ^^^^^
<acheronuk> tsimonq2: cosas buenas
<slangasek> tsimonq2: still working its way through, yes
<tsimonq2> acheronuk: XD
<tsimonq2> slangasek: awesome, if you shoot me a ping when the Ubuntu Server testing images are ready, I'll help test :)
<wxl> we respinning lubuntu alternates too slangasek ?
<infinity> wxl: Once this is proven to work for server, I assume that's the plan.
<wxl> infinity: k cool, keep me up to date, thx :)
-queuebot:#ubuntu-release- Unapproved: python-heatclient (yakkety-proposed/main) [1.4.0-0ubuntu1 => 1.5.0-0ubuntu1] (openstack, ubuntu-server)
<slangasek> apw: I see linux-signed-image-4.8.0-17-generic 4.8.0-17.19 published now, if you want to upload d-i
<doko> slangasek, infinity: why is migration to release pocket still blocked, when the package is built in proposed?
<slangasek> doko: we're in beta freeze, if that's what you mean
<doko> right, but afaicr we never stop migration of already built and tested packages ...
<doko> stopped even
<slangasek> the freeze is rather indiscriminate
<slangasek> my opinion is that we should never have both an archive freeze and a p-m freeze, we should pick one or the other
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0~rc2-0ubuntu1]
<slangasek> but that's not current practice
<doko> so whoever accepted ldb and libunwind should accept the binary builds too, and the binaries built using these
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu478]
<slangasek> oh right, that wasn't "upload d-i", that was "hey dummy AA, you should accept it from unapproved now" - sorry
<doko> sorry, I don't understand ...
<slangasek> doko: that's me responding to the message from queuebot, and me telling apw earlier to upload a package that already was uploaded
<doko> ahh
<nacc> heh
<doko> slangasek: so what's the way forward with these binaries wailting in -proposed?
<slangasek> doko: I guess I'm not sure what you're talking about.  I don't see any binary builds held anywhere for ldb or libunwind, and this is not part of the explanation on people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libunwind
<apw> slangasek: d-i accepted
<slangasek> apw: thanks ;)
<doko> ldb (2:1.1.26-1ubuntu3 to 2:1.1.26-1ubuntu5)
<doko> Maintainer: Ubuntu Developers
<doko> 4 days old
<doko> autopkgtest for samba/2:4.4.5+dfsg-2ubuntu3: amd64: Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass
<doko> Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
<doko> Not considered
<slangasek> ok, that has nothing to do with "binary" packages being blocked
<infinity> doko: Yes, freezes have always stopped binaries that are on images from migrating.
<infinity> s/binaries/packages/
<infinity> This is nothing new.  What's new is that this beta has been a bit of a cluster#$%@!.
<doko> even after the source was accepted into -proposed?
<infinity> Yes...
<infinity> We build from the release pocket.
<slangasek> yes, see my comment above about having both an archive freeze and a p-m freeze
<infinity> Accepting to proposed doesn't affect images.  Promoting does.
<coreycb> infinity, can you reject python-heatclient from the yakkety queue?  we don't need that version.
<infinity> slangasek: As for the double-freeze, we can discuss the impact on velocity and such some time, but we've been doing the "hard freeze from final beta to GA" for a couple of years now, and I'm a big fan.  Honestly, if we had the manpower to handle the reviews, I'd be in hard freeze all year.
<infinity> coreycb: Done.
<coreycb> infinity, thanks
-queuebot:#ubuntu-release- Unapproved: rejected python-heatclient [source] (yakkety-proposed) [1.5.0-0ubuntu1]
<slangasek> infinity: hard freeze, vs. double hard freeze; twice the effort, minimal additional benefit
<infinity> slangasek: Well, the "double" freeze is only during the RC-building process, to gate what is and isn't on the images, while the archive freeze is to review and gate the archive, including post-milestone state.
<infinity> slangasek: They serve very different purposes.
<doko> it's quiet unfortunate that binaries we had in -proposed for a long time, and were used to build other packages, won't migrate before the release
<doko> but anyway, that's server stuff, I shouldn't care about
<infinity> doko: If they were beta-critical, no one indicated such.  They'll move long before final release.
<doko> apw: ^^^ just in case you build your kernel in the release pocket, or in the later release: the libunwind fix isn't in the release pocket, and probably won't be there
<slangasek> doko: er, nobody said it won't be there for release
<apw> doko, yep aware of libunwind, i am sure we are not building against it yet, least of our problems (tm)
-queuebot:#ubuntu-release- Unapproved: python-swiftclient (yakkety-proposed/main) [1:3.0.0-3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
<doko> slangasek: well, I asked for the route forward ...
<slangasek> doko: wait for us to be done with beta
<doko> ok
-queuebot:#ubuntu-release- Unapproved: dolfin (yakkety-proposed/universe) [2016.1.0-3 => 2016.1.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dolfin [sync] (yakkety-proposed) [2016.1.0-5]
-queuebot:#ubuntu-release- Unapproved: python-os-client-config (yakkety-proposed/main) [1.18.0-0ubuntu3 => 1.21.1-0ubuntu1] (openstack, ubuntu-server)
<doko> slangasek: ahh, so beta is not yet released? sorry was offline for three days
<slangasek> doko: right, we ran into kernel problems
-queuebot:#ubuntu-release- Unapproved: mozjs (yakkety-proposed/universe) [1.8.5-1.0.0+dfsg-4.5 => 1.8.5-1.0.0+dfsg-5] (mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: moka-icon-theme (yakkety-proposed/universe) [5.3.2-1 => 5.3.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted moka-icon-theme [sync] (yakkety-proposed) [5.3.2-2]
-queuebot:#ubuntu-release- Unapproved: gnote (yakkety-proposed/universe) [3.20.1-1 => 3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: partimage (yakkety-proposed/universe) [0.6.9-3~build1 => 0.6.9-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted partimage [sync] (yakkety-proposed) [0.6.9-3]
-queuebot:#ubuntu-release- Unapproved: z3 (yakkety-proposed/universe) [4.4.1-0.2 => 4.4.1-0.3] (no packageset) (sync)
<ogasawara> slangasek: apw notes that d-i should be published now...so I think we're ready for you to hit the button for the images
-queuebot:#ubuntu-release- Unapproved: accepted z3 [sync] (yakkety-proposed) [4.4.1-0.3]
<slangasek> ogasawara: I'm set up to auto-run the image build as soon as d-i is visible from nusakan
<slangasek> (there's "published" and then there's "published")
<ogasawara> heh, ok :)
-queuebot:#ubuntu-release- Unapproved: maxima (yakkety-proposed/universe) [5.38.0-3build1 => 5.38.0-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted maxima [source] (yakkety-proposed) [5.38.0-3build2]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Beta 2] has been updated (20101020ubuntu478)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Beta 2] has been updated (20101020ubuntu478)
<slangasek> apw, ogasawara: image build has begun
<ogasawara> slangasek: sweet, thanks.  eta ~1hr?
<slangasek> ogasawara: probably 45m
<ogasawara> slangasek: even better, thanks
-queuebot:#ubuntu-release- Unapproved: accepted brasero [source] (yakkety-proposed) [3.12.1-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (yakkety-proposed) [1.4.1+16.10.20160914-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnote [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted mozjs [sync] (yakkety-proposed) [1.8.5-1.0.0+dfsg-5]
<pitti> slangasek: image builds already? doesn't 4.8.0-17 need to land in y-release first?
<pitti> or do we have some magic to build images with selected -proposed packages?
-queuebot:#ubuntu-release- Unapproved: hol88 (yakkety-proposed/universe) [2.02.19940316-31build1 => 2.02.19940316-31build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hol88 [source] (yakkety-proposed) [2.02.19940316-31build2]
<santa_> slangasek: hello, I have re-checked the kio issue more calmly and it seems it's indeed an ABI break, this is a possible solution https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kio/commit/?id=4728eb39ef470dca1f2536719ea69c50fe989c19
<slangasek> pitti: I'm trying a build with PROPOSED=1; this should at least be enough to smoke test the kernel, *if* it manages to build at all
<pitti> ah, bold :)
<slangasek> santa_: looks sane to me
<tsimonq2> \\o//
<slangasek> pitti: it either builds or it doesn't; either way, no time lost
<pitti> slangasek: right, I just thought these would already be "the" beta candiates
 * pitti bids good night
<tsimonq2> o/ pitti
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160926)
<slangasek> apw, ogasawara, jgrimm, powersj: ^^
<jgrimm> slangasek, \o/
-queuebot:#ubuntu-release- Unapproved: acl2 (yakkety-proposed/universe) [7.2dfsg-2build1 => 7.2dfsg-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted acl2 [source] (yakkety-proposed) [7.2dfsg-2build2]
<ogasawara> slangasek: wheee, will tell the team to start testing.  thanks!
<wxl> still only working on server right now, correct?
<slangasek> wxl: yes
<slangasek> this is a smoketest only
<wxl> kk thx slangasek
<powersj> slangasek, this is looking a lot better :)
<tsimonq2> slangasek: is the image done somewhere or is it still spinning up?
<slangasek> tsimonq2: it's up, see queuebot above - the 20160926 ubuntu-server image is the smoketest image
<tsimonq2> slangasek: I'll smoketest in a min, currently getting a decent response to the email that just popped up in ubuntu-devel-discuss ;)
<ogasawara> slangasek: testing is showing much more promising this time around
<slangasek> ogasawara: coolio. it also looks like it's passed the automated smoketest on amd64, I don't know if i386 has failed or is still pending ( powersj ?)
<powersj> slangasek, i386 just finished
<slangasek> excellent
<slangasek> and we have some positive test results coming in on autopkgtest, which is an improvement over "this kernel makes the testbed disappear"
<tsimonq2> we have autopkgtests for the kernel?!?
<tsimonq2> huh
<tsimonq2> cool! :D
<slangasek> apw, ogasawara: so I'm good with dropping the blocking bugs and respinning again as soon as the kernel hits yakkety
<slangasek> tsimonq2: we get quite extensive testing via autopkgtest, when we aren't skipping it in our haste
<smb> slangasek, I am trying the s390 KVM install but I think this has a problem due to pulling most things from the archive. IOW it boots but after ssh into the installer it mentions to find no matching kernel modules which usually ends with no dasd
<ogasawara> slangasek: +1
<slangasek> smb: the things are in the archive to be pulled, but I think you have to twiddle the boot options to get it to use -proposed... I don't remember the option name, sorry
<smb> hm lets see
<sergiusens> is http://people.canonical.com/~ubuntu-archive/pending-sru.html stuck?
<cjwatson> looks like it, let me prod with flamethrower
<smb> slangasek, found the twiddle. testing...
<cjwatson> done, should unstick next time it feels like running
<cjwatson> which should be soon enough as it's cronned for twice an hour
<tsimonq2> rtg: I just saw bug 1627875, are you testing using the server ISO slangasek just spun up?
<ubot5> bug 1627875 in linux (Ubuntu Yakkety) "Yakkety server Beta install fails in a virtual client with UEFI bios" [Undecided,Confirmed] https://launchpad.net/bugs/1627875
<tsimonq2> rtg: I'm using virt-manager to test with 1 GB of RAM and 1 CPU core
<rtg> tsimonq2, I am
<tsimonq2> ok
<tsimonq2> rtg: it fails to boot, but could you be more specific? and how did you do a UEFI BIOS, I want to learn how to do that ;)
<rtg> tsimonq2, I'll add instructions into the bug, gimme a couple mins
<tsimonq2> ok no problem rtg
<rtg> tsimonq2, updated
<tsimonq2> thanks rtg
<mwhudson> slangasek: would you be ok with the fixed (hopefully) docker autopkgtest going straight to xenial or would you want to see it succeed in yakkety first?
<tsimonq2> slangasek: Yakkety amd64 Ubuntu Server image with BIOS is good to go
 * tsimonq2 tries to reproduce rtg's bug
<apw> tsimonq2, is that a secure boot setup?  is that the shim 0.9 issue with vms and efi ?
<tsimonq2> the host system is BIOS
<rtg> tsimonq2, apw tells me there is a known bug with shim in a VM
<tsimonq2> gah 3 letter usernames, I mixed y'all up
<tsimonq2> I'm not sure what SHIM is
<rtg> tsimonq2, it is part of the boot loader stack that is installed to support UEFI
<rtg> tsimonq2, I've just verified that -17.19 boot in Xenial (UEFI), so taht squarly points at a shim problem in Yakkety
<tsimonq2> I can confirm your bug rtg
<rtg> tsimonq2, confirm taht it won't boot ?
<tsimonq2> correct
<rtg> tsimonq2, ok
<apw> cyphermox, ^
<apw> i am pretty sure there is intended to be release note about the shim thing, but i do not know the bug number to confirm
<tsimonq2> http://img.ctrlv.in/img/16/09/27/57e9aae61a86d.png <- that's the screen that I'm getting
<tsimonq2> powersj: good call re bug 1627875
<ubot5> bug 1627875 in linux (Ubuntu Yakkety) "Yakkety server Beta install fails in a virtual client with UEFI bios" [Critical,Confirmed] https://launchpad.net/bugs/1627875
<tsimonq2> shouldn't it be marked as also affecting shim then?
<powersj> what is the other bug #? We can then figure out if we should dup
<tsimonq2> good question
<powersj> Is this it? bug 1624096
<ubot5> bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,In progress] https://launchpad.net/bugs/1624096
<cyphermox> correct
<tsimonq2> I think so
<tsimonq2> so bug 1627875 should be marked as a dup of bug 1624096 then ?
<ubot5> bug 1627875 in linux (Ubuntu Yakkety) "Yakkety server Beta install fails in a virtual client with UEFI bios" [Critical,Confirmed] https://launchpad.net/bugs/1627875
<ubot5> bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,In progress] https://launchpad.net/bugs/1624096
<slangasek> mwhudson: autopkgtest in parallel to {xenial,yakkety}-proposed is fine with me
<mwhudson> slangasek: ok
-queuebot:#ubuntu-release- Unapproved: docker.io (yakkety-proposed/universe) [1.12.1-0ubuntu12 => 1.12.1-0ubuntu13] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (yakkety-proposed) [1.12.1-0ubuntu13]
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.1-0ubuntu12~16.04.1 => 1.12.1-0ubuntu13~16.04.1] (no packageset)
<mwhudson> slangasek: can i get a quick approve for that one?
<slangasek> mwhudson: looking now
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.1-0ubuntu13~16.04.1]
<slangasek> mwhudson: ^^
<mwhudson> slangasek: thanks!
<mwhudson> now i wait for the publisher, britney, autopkgtest ...
-queuebot:#ubuntu-release- Unapproved: libecap (yakkety-proposed/main) [1.0.1-3ubuntu3 => 1.0.1-3ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libpam-radius-auth (yakkety-proposed/main) [1.3.17-0ubuntu4 => 1.3.17-0ubuntu5] (ubuntu-server)
<mwhudson> slangasek: is there some record for how many times "Please test proposed package" has been posted to the same bug?
<slangasek> mwhudson: no idea :)
<mwhudson> i guess it's probably more than 3
 * nacc still appreciates when bugproxy gets asked to test
<mwhudson> yeah
<lynorian> that makes more sense than someone coming up to a confrence booth and asking if bugproxy is attending
<nacc> heh
<nacc> why did bugproxy remove all those tags from LP: #1602243?
<ubot5> Launchpad bug 1602243 in Ubuntu on IBM z Systems "[16.10 FEAT] Upgrade Docker to newest version 1.12" [Medium,Fix committed] https://launchpad.net/bugs/1602243
<mwhudson> uh yeah that makes no sense
 * mwhudson puts verification-needed back at least
<nacc> yeah
-queuebot:#ubuntu-release- Unapproved: dia-shapes (yakkety-proposed/universe) [0.6.0-2 => 0.6.0-3] (edubuntu) (sync)
#ubuntu-release 2016-09-27
-queuebot:#ubuntu-release- Unapproved: zivot (yakkety-proposed/universe) [20013101-3build2 => 20013101-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted zivot [sync] (yakkety-proposed) [20013101-3.1]
<slangasek> apw, wxl, tsimonq2: hint added to let the kernel in to release, server and lubuntu alternate ISOs will trigger as soon as the publishing is done, so that's still roughly 1.5h away
<tsimonq2> slangasek: thank you :)
-queuebot:#ubuntu-release- Unapproved: meld (yakkety-proposed/universe) [3.16.2-1 => 3.16.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meld [sync] (yakkety-proposed) [3.16.3-1]
-queuebot:#ubuntu-release- Unapproved: metar (yakkety-proposed/universe) [20061030.1-2.1 => 20061030.1-2.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted metar [sync] (yakkety-proposed) [20061030.1-2.2]
<wxl> slangasek: cool. release tomorrow hopefully then?
<slangasek> wxl: that seems like a realistic target
<wxl> slangasek: alright, cool. thx!
<slangasek> I don't trust myself to push all the buttons for the release still tonight
-queuebot:#ubuntu-release- Unapproved: ccd2iso (yakkety-proposed/universe) [0.3-4 => 0.3-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ccd2iso [sync] (yakkety-proposed) [0.3-5]
<lynorian> is it useful to test if this problem happens on a yakkety host with yakkety guest?
<tsimonq2> slangasek ^^^^
<cyphermox> lynorian: tsimonq2: what problem?
<tsimonq2> cyphermox: bug 1624096
<ubot5> bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,In progress] https://launchpad.net/bugs/1624096
<tsimonq2> hi btw ;)
<cyphermox> no point in further testing this
<cyphermox> it's definitely *not* going to be fixed for the beta.
<tsimonq2> well Lubuntu alternates need the testing, even though it might not be fixed for the beta
<cyphermox> ok
<cyphermox> well, don't know if it was a shim issue that was breaking lubuntu alt
<tsimonq2> good point
<cyphermox> I know the shim thing is not even a "might not", it's a "definitely impossible to be fixed for the beta", since we're waiting on a third-party for digital signatures before it can make it in the archive at all, and then needs a grub update to go with it
<cyphermox> but I'm running a quick test on kubuntu now, I can have a look at lubuntu after if there's something I can fix tonight in time for a respin
<valorie> nice!
<cyphermox> wallpaper looks pretty cool
<cyphermox> also, yay me, ubiquity didn't crash
<valorie> :-)
<cyphermox> that means yay me, the issue I'm seeing is not ubiquity and not NetworkManager.
<cyphermox> (so I still have no idea what is wrong but at least my workaround will work)
<slangasek> tsimonq2: lubuntu alt will need retesting because it's getting the new kernel; the previous build only has the 4.4 kernel which isn't our beta kernel
<cyphermox> so we're "just" waiting for the image to finish building for now
<tsimonq2> slangasek: already sent to lubuntu-devel@l.u.c, we've got that covered :(
<tsimonq2> *:)
<tsimonq2> thanks though
<cyphermox> slangasek: I don't really love this but my solution to ubiquity crashing in NM for the gtk UI is to run ubiquity in sudo
<cyphermox> ubiquity would already try to re-execute itself with pkexec anyway, but somehow this doesn't seem to work correctly anymore
<cyphermox> in other words, there is *still* a problem somewhere there, but I haven't been able to find what it is
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160927)
 * ogasawara starts testing
<valorie> wooooooo
<tsimonq2> ^
 * tsimonq2 grabs an image and joins the party
<tsimonq2> ogasawara: I'm grabbing amd64, I assume you'll mark the tests that you're doing as "In Progress" ?
<ogasawara> tsimonq2: oh, where do I mark them in progress?
<tsimonq2> ogasawara: iso.qa.ubuntu.com
<tsimonq2> ogasawara: log in, then you can submit an "In Progress" result
<ogasawara> tsimonq2: is that the "Subscribe" button?
<tsimonq2> no
<tsimonq2> ogasawara: have you used this before?
<ogasawara> tsimonq2: yes, we've been submitting our test results here, but I've never done the "In Progress" bit
<tsimonq2> ogasawara: go to submit the test as you usually would do, there's an "In Progress" radio box there
<tsimonq2> ogasawara: just submit a blank "In Progress" so work isn't duplicated
<ogasawara> ah, thanks
<tsimonq2> no problem :)
<tsimonq2> CD1 missing some packages needed by debootstrap
<tsimonq2> make: *** [/srv/cdimage.ubuntu.com/scratch/lubuntu/yakkety/daily/tmp/yakkety-powerpc/packages-stamp] Error 1
<tsimonq2> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<tsimonq2> slangasek: ping, ^^
<tsimonq2> slangasek: that's on http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/yakkety/daily-20160927.log
<tsimonq2> ogasawara: what test are you doing atm?
<tsimonq2> ogasawara: I'm starting http://iso.qa.ubuntu.com/qatracker/milestones/367/builds/132013/testcases/1337/results
<ogasawara> tsimonq2: I'm still trying to download this damn thing
<ogasawara> tsimonq2: but was planning to start with amd64
<tsimonq2> ok
<tsimonq2> then you might want to do one of the LVM ones
<ogasawara> tsimonq2: ack, will do
<tsimonq2> awesome :)
<ogasawara> tsimonq2: and I've got 2 guys on my team also helping test
<tsimonq2> ogasawara: where are they at?
<ogasawara> tsimonq2: so they are also divide and conquering amd64 and i386, I've asked them to mark those in progress
<tsimonq2> ok cool
<tsimonq2> ogasawara: in the meantime I'll be doing some homework, school in the morning ;)
<ogasawara> tsimonq2: they're starting with i386
<tsimonq2> ok cool
<tsimonq2> that works :)
<tsimonq2> ogasawara: out of curiosity, you on the server team? what do you do? :)
<ogasawara> tsimonq2: I manage the kernel team
<tsimonq2> oh nice :)
<tsimonq2> ogasawara: within the next hour or two I'll try to do as many amd64 testcases as possible to make sure that we don't fail on an edge case
<ogasawara> tsimonq2: perfect, thanks!
<tsimonq2> ogasawara: taking a peek at your Launchpad page I see that your tz is PDT, I'm CDT, I plan to be to bed by 11
<tsimonq2> ogasawara: and judging by how fast that test just went, I'll be able to get through a few of them ;)
<ogasawara> tsimonq2: I'll stay up as late as I have to to get these tested
<tsimonq2> ogasawara: good deal, I'll let you know when I head to bed
<tsimonq2> ogasawara: done with the default test, moving on to Optional
<ogasawara> tsimonq2: ack, I'm mid flight with both the lvm test cases
<tsimonq2> ok cool :)
<tsimonq2> ogasawara: do you think optional tests are a dealbreaker? do you need those done as well?
<ogasawara> tsimonq2: not a dealbreaker imo, but I'll leave the final call to slangasek
<tsimonq2> ok
<ogasawara> tsimonq2: my guys and I are trying to grab some of the optional ones regardless
<tsimonq2> nice ok
<tsimonq2> ogasawara: I did amd64 bind9 and I'm doing amd64 preseed now
<tsimonq2> or it's going on it's own rather :P
-queuebot:#ubuntu-release- Unapproved: gnome-characters (yakkety-proposed/universe) [3.21.91.1-1 => 3.22.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-mahjongg (yakkety-proposed/main) [1:3.21.90-1 => 1:3.22.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-sudoku (yakkety-proposed/main) [1:3.21.90-1 => 1:3.22.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gssdp (yakkety-proposed/universe) [0.14.16-2 => 1.0.0-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gupnp (yakkety-proposed/universe) [0.99.0-1 => 1.0.0-1] (kubuntu) (sync)
<tsimonq2> ogasawara: I'm finishing these three up then going to bed
<ogasawara> tsimonq2: thanks
<tsimonq2> no problem at all, have a good evening and sorry I couldn't help with the rest ogasawara :)
<ogasawara> tsimonq2: you were very helpful, I appreciate it
<tsimonq2> ogasawara: any time, don't be afraid to ping if you need help testing or whatevr :)
<tsimonq2> *whatever
<slangasek> hrm, so the lubuntu alt images didn't build :/
<slangasek> retrying now
-queuebot:#ubuntu-release- Unapproved: libgdata (yakkety-proposed/main) [0.17.5-1 => 0.17.6-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: glib-networking (yakkety-proposed/main) [2.49.90-1 => 2.50.0-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: tracker (yakkety-proposed/main) [1.9.2-0ubuntu1 => 1.10.0-1ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: grilo (yakkety-proposed/main) [0.3.2-1 => 0.3.2-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (yakkety-proposed/universe) [1.45.4-2build1 => 1.46.0-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-contacts (yakkety-proposed/universe) [3.20.0-1ubuntu2 => 3.22.1-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ncap (yakkety-proposed/universe) [1.9.2-2.1 => 1.9.2-2.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ncap [sync] (yakkety-proposed) [1.9.2-2.2]
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (yakkety-proposed/main) [3.20.3-1 => 3.20.4-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: humanity-icon-theme (yakkety-proposed/main) [0.6.10 => 0.6.11] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rygel (yakkety-proposed/universe) [0.30.3-1 => 0.32.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (yakkety-proposed/main) [3.21.90-2ubuntu1 => 3.22.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: network-manager (yakkety-proposed/main) [1.2.2-0ubuntu10 => 1.2.4-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: clamtk (yakkety-proposed/universe) [5.21-1 => 5.22-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clamtk [sync] (yakkety-proposed) [5.22-1]
-queuebot:#ubuntu-release- Unapproved: totem (yakkety-proposed/main) [3.21.91-0ubuntu2 => 3.22.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: thumbnailer (yakkety-proposed/universe) [2.4+16.10.20160825-0ubuntu1 => 2.4+16.10.20160926.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accerciser (yakkety-proposed/universe) [3.14.0-1build1 => 3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: licensecheck (yakkety-proposed/main) [3.0.18-1 => 3.0.24-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (trusty-backports/main) [4.0.2~ubuntu14.04.1 => 4.0.5~ubuntu14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (trusty-backports) [4.0.5~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu9]
<pitti> cyphermox: initramfs-tools+multipath-tools mystery solved, tests pass; (details in bug 1627933)
<ubot5> bug 1627933 in initramfs-tools (Ubuntu) "initramfs-tools 0.125ubuntu4 (ip-config â dhclient) breaks multipath-tools tests" [High,Invalid] https://launchpad.net/bugs/1627933
<michi> pitti: ping
<michi> pitti: Could you sign off on silo 1991? Mirv is happy with it, and itâs stuck in the unapproved queue for yakkety.
<LocutusOfBorg> can anybody please accept licensecheck?
<LocutusOfBorg> I want to see it migrate
<Mirv> what michi means is approving thumbnailer from yakkety UNAPPROVED queue
<michi> Yep, sorry if I wasnât clear
<apw> LocutusOfBorg, is that all bug fixes ?
<LocutusOfBorg> apw, the tool is not gaining new features since some time :) http://paste.ubuntu.com/23240130/
<LocutusOfBorg> I would say so, just bug fixes and documentation/testsuite fixes
<apw> LocutusOfBorg, ack thanks
<LocutusOfBorg> thanks to you
-queuebot:#ubuntu-release- Unapproved: accepted thumbnailer [sync] (yakkety-proposed) [2.4+16.10.20160926.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted licensecheck [sync] (yakkety-proposed) [3.0.24-1]
<LocutusOfBorg> please remove licensecheck block, and run its testsuite against license-reconcile/proposed version (that will build in half an hour)
-queuebot:#ubuntu-release- Unapproved: accepted accerciser [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-mahjongg [sync] (yakkety-proposed) [1:3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-sudoku [sync] (yakkety-proposed) [1:3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (yakkety-proposed) [1.2.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted totem [source] (yakkety-proposed) [3.22.0-0ubuntu1]
<pitti> michi: hm, I don't see it in https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (yakkety-proposed) [3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rygel [sync] (yakkety-proposed) [0.32.0-1]
<pitti> ah, I suppose apw beat me to it
<michi> pitti: It just moved out of there into the proposed pocket.
<michi> I donât know who did that, but it looks like itâs all good now, thanks!
<apw> pitti, sorry that was me ... i meant to come and say it was done, and someone asked me a question ...
<pitti> apw: no need to be sorry, thansk
 * pitti is doing some queue stuff too
-queuebot:#ubuntu-release- Unapproved: cmake (xenial-proposed/main) [3.5.1-1ubuntu2 => 3.5.1-1ubuntu3] (core)
<LocutusOfBorg> pitti, ^^ this cmake is easy, trivial fix and regex fix for the libarchive from backports :)
-queuebot:#ubuntu-release- Unapproved: network-manager (xenial-proposed/main) [1.2.2-0ubuntu0.16.04.1 => 1.2.2-0ubuntu0.16.04.2] (kubuntu, ubuntu-desktop)
<pitti> LocutusOfBorg: ack, doing a round of SRUs
<LocutusOfBorg> thanks, :D
<Laney> apw: got 2 minutes to take a look at merging https://code.launchpad.net/~laney/ubuntu-archive-tools/cm-show-fix-released perchance?
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.1.3-0ubuntu4.2]
 * Laney spreads the pings out a bit
-queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (xenial-proposed) [8.1.1-2ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (xenial-proposed) [3.20.1+git20160923.1.0c571f1-0ubuntu1~xenial1]
<apw> Laney, and why am i wanting to add those ?
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (xenial-proposed) [1:6.1.0-0ubuntu1]
<apw> oh i could read the changelog :)
<Laney> there are some things waiting now that are re-promotions
<Laney> but the report doesn't make that very obvious
<Laney> http://people.canonical.com/~ubuntu-archive/~laney/ubuntu.svg <- that's the result
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.15]
-queuebot:#ubuntu-release- Unapproved: accepted cmake [source] (xenial-proposed) [3.5.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (yakkety-proposed) [3.20.1+git20160923.2.7374bdc-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted humanity-icon-theme [source] (yakkety-proposed) [0.6.11]
<Laney> are we accepting stuff for the beta or just proposed?
-queuebot:#ubuntu-release- Unapproved: accepted glib-networking [sync] (yakkety-proposed) [2.50.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted grilo [sync] (yakkety-proposed) [0.3.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted dia-shapes [sync] (yakkety-proposed) [0.6.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted gupnp [sync] (yakkety-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gssdp [sync] (yakkety-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (yakkety-proposed) [1.46.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kio [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwidgetsaddons [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivities-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted threadweaver [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwayland [source] (yakkety-proposed) [4:5.26.0-0ubuntu1]
<pitti> Laney: just -proposed, still frozen
<Laney> unblocks exist though
<pitti> Laney: stuff for beta-2 still needs to get a manual unblock
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (yakkety-proposed) [3.20.1+git20160923.1.0c571f1-0ubuntu1]
<pitti> well, *I* only accept stuff for post-beta, nothing there semeed urgent
<Laney> one example is gnome-software there fixes a crash on startup on i386
<pitti> AFAIUI, queue is frozen for general post-beta FF/sanity review
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (yakkety-proposed) [49.0+build4-0ubuntu1]
<pitti> and propagation is frozen for beta-2 prep
-queuebot:#ubuntu-release- Unapproved: accepted libgdata [source] (yakkety-proposed) [0.17.6-1ubuntu1]
<pitti> (and infinity actively asked apw and me to do reviews)
-queuebot:#ubuntu-release- Unapproved: accepted tracker [source] (yakkety-proposed) [1.10.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-contacts [source] (yakkety-proposed) [3.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (yakkety-proposed) [3.20.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libecap [source] (yakkety-proposed) [1.0.1-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted libpam-radius-auth [source] (yakkety-proposed) [1.3.17-0ubuntu5]
<apw> pitti, same nothing beta2 critical
<apw> pitti, and i concur on the state and request to review
-queuebot:#ubuntu-release- Unapproved: location-service (yakkety-proposed/main) [3.0.0+16.10.20160811-0ubuntu1 => 3.0.0+16.10.20160912-0ubuntu1] (no packageset) (sync)
<Laney> I know about the two freezes; was just wondering if stuff could be unblocked onto the beta or if it is tighly locked down
-queuebot:#ubuntu-release- Unapproved: biometryd (yakkety-proposed/universe) [0.0.1+16.10.20160628-0ubuntu4 => 0.0.1+16.10.20160922.3-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been updated (20160927.2)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Beta 2] has been updated (20160927.2)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been updated (20160927.2)
-queuebot:#ubuntu-release- Unapproved: xen (yakkety-proposed/main) [4.6.0-1ubuntu5 => 4.7.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<pitti> meh, this is like whack-a-rat :)
<apw> pitti, indeed :
<apw> :)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.2-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.41-0ubuntu2 => 1.0.42-0ubuntu1] (no packageset)
<LocutusOfBorg> can I know why licensecheck is in main? I don't find a MIR
<LocutusOfBorg> devscripts
<LocutusOfBorg> :(
<Laney> Probably because it was split out of devscripts so it was considered that it didn't need one
<LocutusOfBorg> the problem is that the new version has 3 new perl dependencies
<LocutusOfBorg> :(
<LocutusOfBorg> my effort in seeing it migrate is probably wasted
-queuebot:#ubuntu-release- New sync: mcloud (yakkety-proposed/primary) [1.0.0+16.10.20160927.3-0ubuntu1]
<apw> Laney, looks good to em
<Laney> â¥
-queuebot:#ubuntu-release- Unapproved: glib2.0 (yakkety-proposed/main) [2.49.6-1 => 2.50.0-1] (core) (sync)
-queuebot:#ubuntu-release- New source: nplan (xenial-proposed/primary) [0.12~16.04]
<pitti> morphis, apw: ^ remaining item for netplan/xenial; this has the snap support hack (note that it is in NEW, not UNAPPROVED)
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [sync] (yakkety-proposed) [2.50.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (yakkety-proposed) [1.0.42-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted biometryd [sync] (yakkety-proposed) [0.0.1+16.10.20160922.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted location-service [sync] (yakkety-proposed) [3.0.0+16.10.20160912-0ubuntu1]
<zyga> RAOF: hello, I'm trying to get an SRU of snap-confine out, I see that there are four bugs that need verification
<zyga> RAOF: what can I do to make the process move forward?
<apw> zyga, well the bugs need verification by someone who knows how to do that ... can you mobilise people to do that ?
-queuebot:#ubuntu-release- Unapproved: python-tidylib (yakkety-proposed/universe) [0.2.4~dfsg-4 => 0.3.0~dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-tidylib [sync] (yakkety-proposed) [0.3.0~dfsg-1]
<zyga> apw: I see, can anyone verify bugs?
<apw> zyga, yes, and the 4th one you verified in the first proposed upload by the looks of it ...
<apw> which was superceeded by this latest one
<zyga> apw: "this latest one" being? 1.0.38-0ubuntu0.16.04.10?
<apw> zyga, yes, the latest in xenial-proposed
<zyga> OK
<zyga> so I need to get the remaining bugs verified, update the tags and poke the release team again?
-queuebot:#ubuntu-release- Unapproved: gnome-getting-started-docs (yakkety-proposed/universe) [3.20.0-1ubuntu2 => 3.22.0-1ubuntu1] (ubuntugnome)
<apw> zyga, that is the quickest way to get it out yes
<apw> zyga, all but the ptmx one looks to be easily testible in any install, that one might only be verifiable properly on the hardware, but if we can confirm the profile as installed with the new package has the relevant lines it would likley be ok if we cannot get the original reporter to wake up
<zyga> ok
<apw> but do try and wake them up ... it seems while since the bug was filed
<zyga> yep, I will
-queuebot:#ubuntu-release- Unapproved: qqwing (yakkety-proposed/main) [1.3.4-1 => 1.3.4-1.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: openbmap-logger (yakkety-proposed/universe) [0.4.0-6 => 0.4.0-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openbmap-logger [sync] (yakkety-proposed) [0.4.0-7]
-queuebot:#ubuntu-release- Unapproved: gtkimageview (yakkety-proposed/universe) [1.6.4+dfsg-1 => 1.6.4+dfsg-1.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: commons-pool2 (yakkety-proposed/universe) [2.4.2-1 => 2.4.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maria (yakkety-proposed/universe) [1.3.5-4build2 => 1.3.5-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: easymock (yakkety-proposed/universe) [3.3.1+ds-3 => 3.3.1+ds-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted commons-pool2 [sync] (yakkety-proposed) [2.4.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted maria [source] (yakkety-proposed) [1.3.5-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted easymock [sync] (yakkety-proposed) [3.3.1+ds-4]
-queuebot:#ubuntu-release- Unapproved: libproxool-java (yakkety-proposed/universe) [0.9.1-8 => 0.9.1-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libproxool-java [sync] (yakkety-proposed) [0.9.1-9]
-queuebot:#ubuntu-release- Unapproved: enigma (yakkety-proposed/universe) [1.20-dfsg.1-2build2 => 1.20-dfsg.1-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted enigma [sync] (yakkety-proposed) [1.20-dfsg.1-2.1]
-queuebot:#ubuntu-release- Unapproved: xarchiver (yakkety-proposed/universe) [1:0.5.4-4 => 1:0.5.4-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xarchiver [sync] (yakkety-proposed) [1:0.5.4-5]
<mdeslaur> cjwatson, infinity, wgrant : can we stop the publisher (emergency)
-queuebot:#ubuntu-release- Unapproved: dico (yakkety-proposed/universe) [2.2-9build2 => 2.3-1] (no packageset) (sync)
<cjwatson> mdeslaur: done
-queuebot:#ubuntu-release- Unapproved: accepted dico [sync] (yakkety-proposed) [2.3-1]
<rcj> slangasek, infinity: cloud-images are ready for beta.  When the release announcement draft is up I would add that our download location is http://cloud-images.ubuntu.com/daily/server/yakkety/ and the beta build is 20160927 (or later as we only keep the last 5 or so)
-queuebot:#ubuntu-release- Unapproved: geary (yakkety-proposed/universe) [0.11.1-1ubuntu1 => 0.11.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted geary [source] (yakkety-proposed) [0.11.2-1ubuntu1]
<cjwatson> (publisher restarted)
-queuebot:#ubuntu-release- Unapproved: media-hub (yakkety-proposed/main) [4.6.0+16.10.20160826-0ubuntu1 => 4.6.0+16.10.20160909-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mediaplayer-app (yakkety-proposed/universe) [0.20.5+16.10.20160921-0ubuntu1 => 0.20.5+16.10.20160922-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mediaplayer-app [sync] (yakkety-proposed) [0.20.5+16.10.20160922-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: aodh (xenial-proposed/universe) [2.0.4-0ubuntu1 => 2.0.5-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New: rejected nplan [source] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New source: nplan (xenial-proposed/primary) [0.12~16.04]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu1 => 0.6.5.8-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: valadoc (yakkety-proposed/universe) [0.23.2~git20150422-3.1 => 0.30.0~git20160518-1~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted valadoc [source] (yakkety-proposed) [0.30.0~git20160518-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted nplan [source] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New binary: nplan [i386] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [ppc64el] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vmware-nsx (xenial-proposed/universe) [8.0.0-0ubuntu0.16.04.2 => 8.0.0-0ubuntu0.16.04.3] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [amd64] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [arm64] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [armhf] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [s390x] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New binary: nplan [powerpc] (xenial-proposed/none) [0.12~16.04] (no packageset)
-queuebot:#ubuntu-release- New: accepted nplan [amd64] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [armhf] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [powerpc] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [s390x] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [arm64] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [ppc64el] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- New: accepted nplan [i386] (xenial-proposed) [0.12~16.04]
-queuebot:#ubuntu-release- Unapproved: cinder (xenial-proposed/main) [2:8.1.0-0ubuntu1 => 2:8.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (xenial-proposed/main) [2:8.0.0-0ubuntu1 => 2:8.2.0-0ubuntu1] (openstack, ubuntu-server)
<sergiusens> apw hey, mind helping me out with releasing snapcraft/xenial-proposed in snapcraft/xenial-updates?
 * apw looks
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (xenial-proposed/main) [1:8.0.0-0ubuntu1 => 1:8.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (xenial-proposed/main) [2:8.1.2-0ubuntu1 => 2:8.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (xenial-proposed/main) [2:9.1.0-0ubuntu1 => 2:9.2.0-0ubuntu1] (openstack, ubuntu-server)
<apw> sergiusens, looks ok ...
<sergiusens> thanks!
<apw> i wish all testing was documented as well as that
<ogra_> apw, just make sergiusens maintain all packages ... fixed :)
<sergiusens> lol ogra_, the documentation is all elopio; bt we try to have traceability everywhere to know where things went wrong if they do go wrong
<ogra_> :)
<sergiusens> you have to always plan for things to go wrong ;-)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.4 => 2.408.5] (desktop-core)
<Laney> snapcraft doesn't have to wait for 7 days?
<apw> Laney, nope, it has an exception
<Laney> indeed
<apw> Laney, it is documented at the bottom of the linked exceptions thing in the bug
<Laney> https://wiki.ubuntu.com/SnapcraftUpdates
<Laney> lucky them
<apw> thats the one ... yeah i was supprised it was completely waved
<apw> but it did also appear to have been rather well tested in this case
<apw> slangasek, i am seeing an issue in the lubuntu images which looks like a seeds issue
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.1.2-0ubuntu1 => 2:8.2.0-0ubuntu1] (openstack, ubuntu-server)
<gQuigs> so the 'wine' binary package was dropped from the new wine1.8 build (https://bugs.launchpad.net/ubuntu/+source/wine1.6/+bug/1558480)
<ubot5> Ubuntu bug 1558480 in wine1.6 (Ubuntu) "[FFe] Transition from src:wine1.6 to src:wine from Debian" [High,Fix released]
<gQuigs> will the old 'wine' package get cleaned up on it's own or should I request it explicitly like with wine-gecko
-queuebot:#ubuntu-release- Unapproved: libgksu (yakkety-proposed/universe) [2.0.13~pre1-8ubuntu1 => 2.0.13~pre1-9ubuntu1] (edubuntu)
<slangasek> apw: howso?
<pitti> apw: crap, forgot to backport the NM test fix after the isc-dhcp change in bug 1609898; I uploaded a follow-up NM, if you could review it? (it's simple, I just don't want the tests to keep failing)
<ubot5> bug 1609898 in network-manager (Ubuntu Trusty) "dhclient incorrectly assumes a /64 ipv6 prefix" [Undecided,Triaged] https://launchpad.net/bugs/1609898
<apw> slangasek, just filing a bug on the error it throws
-queuebot:#ubuntu-release- Unapproved: network-manager (xenial-proposed/main) [1.2.2-0ubuntu0.16.04.2 => 1.2.2-0ubuntu0.16.04.3] (kubuntu, ubuntu-desktop)
<apw> slangasek,
<apw> lubuntu beta2 install fails with: "lubuntu-core : Depends: xserver-xorg-input-all but it is not going to be installed"
<apw> any idea what one files that against?
<pitti> start with lubuntu-meta?
<apw> bug: #1628133
<ubot5> bug 1628133 in lubuntu-meta (Ubuntu) "lubuntu beta2 install fails with: "lubuntu-core : Depends: xserver-xorg-input-all but it is not going to be installed"" [Undecided,New] https://launchpad.net/bugs/1628133
<apw> iso tracker updated also
-queuebot:#ubuntu-release- Unapproved: ironic (xenial-proposed/universe) [1:5.1.0-0ubuntu1 => 1:5.1.2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.2-0ubuntu0.16.04.3]
-queuebot:#ubuntu-release- Unapproved: python-django (yakkety-proposed/main) [1.8.7-1ubuntu7 => 1.8.7-1ubuntu8] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted debian-games [amd64] (yakkety-proposed) [1.5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kjsembed (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sahara (xenial-proposed/universe) [1:4.0.0-1ubuntu1 => 1:4.1.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.1 => 2.0.873+git0.3b4b4500-14ubuntu3.2] (ubuntu-desktop, ubuntu-server)
<ChrisTownsend> Hi! Will packages stuck in yakkety-proposed due to the freeze be handled "automatically" or do we explicitly have to ask to get them promoted?
<zyga> RAOF: hello, I've verified all the bugs associated with the current SRU of snap-confine
<apw> zyga, for xenial ?
<zyga> apw: yes
<Laney> ChrisTownsend: They will be taken care of
<ChrisTownsend> Laney: k, thanks
<apw> zyga, once that clears there is a queued snap-confine in the queue is that still relevant or is a replacement coming
<zyga> apw: I think we'll get .42 which contains a tiny fix on top of .41
<zyga> apw: AFAIK mvo uploaded something today, let me look
<apw> zyga, should i reject the queued entry in deferance to that then
<zyga> apw: yes please
<zyga> apw: I'll work on sponsoring the .42 one
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu12 => 0.6.5.6-0ubuntu13] (no packageset)
<apw> zyga, done
<zyga> thank you
-queuebot:#ubuntu-release- Unapproved: rejected snap-confine [source] (xenial-proposed) [1.0.41-0ubuntu2~16.04.1]
<lamont> coudl someone kindly reject open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.1 => 2.0.873+git0.3b4b4500-14ubuntu3.2] (ubuntu-desktop, ubuntu-server)
<lamont> thanks
<lamont> slangasek: `^^ ?
 * apw looks
<apw> lamont, slangasek done
<lamont> ta
<lamont> apw: I had not realized you had such power
-queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu2]
<slangasek> mdeslaur: looks like this is the relevant log: http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-04-26-16.00.log.html
-queuebot:#ubuntu-release- New sync: networking-sfc (yakkety-proposed/primary) [2.0.1~git20160926.27f311e-1]
<slangasek> mdeslaur: so http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py is buggy, according to that log, and we need to include all supported seeds to get proper metadata; but it's not clear to me that you're consuming the output of this
<mdeslaur> slangasek: ah, right, it's not the seeds themselves that are problematic. I see.
<mdeslaur> slangasek: ok, I'll revisit...not sure why I thought I had to wait
<mdeslaur> slangasek: thanks
<slangasek> mdeslaur: ok cheers :)
-queuebot:#ubuntu-release- Unapproved: gce-utils (yakkety-proposed/partner) [1.3.3-0ubuntu5 => 1.3.3-0ubuntu6] (no packageset)
<slangasek> apw: ugh; xserver-xorg-input-all is my fault, I thought xserver-xorg-input-vmmouse was only a Recommends rather than a Depends and I removed it because dropped in Debian. fixing
<rcj> slangasek, Can you approve ^ gce-utils and get it into partner for yakkety?
<slangasek> rcj: not until after beta is sorted
<Odd_Bloke> slangasek: Because you don't have cycles, or because you more generally don't want it landing before beta?
<slangasek> Odd_Bloke: the former
<slangasek> apw, wxl_: xorg 1:7.7+13ubuntu4 uploaded, lubuntu alternate images will be retriggered automatically once it publishes
-queuebot:#ubuntu-release- Unapproved: accepted xorg [source] (yakkety-proposed) [1:7.7+13ubuntu4]
-queuebot:#ubuntu-release- Unapproved: binutils (yakkety-proposed/main) [2.27-8ubuntu1 => 2.27-8ubuntu2] (core)
<lamont> slangasek: to make sure, one of the yakkety-proposed things is the whole overlayroot= kernel param going away (so it's not just maas/ipv6 that's hurting, it's all of maas)
<lamont> slangasek: acocordingly, I'm likely to be focusing on that after lunch, and may want to smash cloud-initramfs-tools into yakkety sooner than later
<doko> pitti, slangasek: licencecheck dependencies were again demoted :-(
<slangasek> doko: yeah, I noticed. Sure as hell wasn't me :)
<slangasek> lamont: "one of the yakkety-proposed things"> sorry, I'm not sure I got the start of this conversation (netsplit?)
<wxl> netsplits are exceptional today
<lamont> slangasek: nah, I just didn't give it to you...
<wxl> DoS :( https://twitter.com/freenodestaff/status/780813276733210629
<lamont> maas/ipv6 has several packages in-flight (1621515 1621507) which are also the focus of that xenial-sru fun
<lamont> slangasek: one other change (which isn't either of those bugs, dunno what number it is) was the cloud-initramfs-tools change you accepted into  yakkety-proposed on Sat
<lamont> that change should be discussed with smoser to make sure whether or not that's a blocker for cloud images
<lamont> slangasek: and with that, I'll drop it at the feet of you, Odd_Bloke and smoser (who isn't in this channel, it seems)
-queuebot:#ubuntu-release- Unapproved: accepted gce-utils [source] (yakkety-proposed) [1.3.3-0ubuntu6]
<slangasek> Laney: it appears no one has marked Ubuntu Desktop 'ready' on http://iso.qa.ubuntu.com/qatracker/milestones/367/builds; who can make that call?
<slangasek> ogasawara__, jgrimm: where did we get to on testing of Ubuntu Server on power?  I see there are no test results for them on the tracker yet
<Odd_Bloke> slangasek: Is there somewhere we should be adding words for the beta email?
<slangasek> acheronuk: and it looks like we still need someone to make the call on the Kubuntu images being ready for beta release
<slangasek> Odd_Bloke: I've pinged infinity about a draft but he's at conference this week.  If someone were to create a wiki page for the email draft and stick their words in it, I would be happy to take it from there
<acheronuk> slangasek: not me, but I will pass that on
<slangasek> valorie: ^^
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been disabled
<ogasawara__> slangasek: unfortunately my team doesn't have access to powerpc kit.  jgrimm does your team?  and for ppc64el, our machine is tied down with some testing for a xenial respin, so we're blocked there.
<jgrimm> slangasek, ogasawara__: yes, getting someone on this right now
<ogasawara__> jgrimm: thank you!
-queuebot:#ubuntu-release- Unapproved: classic-theme-restorer (yakkety-proposed/universe) [1.5.6-1 => 1.5.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted classic-theme-restorer [sync] (yakkety-proposed) [1.5.7-1]
<jgrimm> ogasawara__, slangasek:   nacc is on it as powersj is at a sprint this week
<valorie> slangasek: I can't seem to raise yofel, but our beta image is well-tested
<slangasek> valorie: I can do the marking on the tracker, if someone can vouch that it's ready
<valorie> gulp
<valorie> I'll vouch
<slangasek> ok :)
<valorie> thank you
<acheronuk> and from me ^^
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Beta 2] has been marked as ready
<wxl> exactly
<wxl> oops wrong channel
<wxl> slangasek: so alternates are currently disabled? we're giving up?
<slangasek> wxl: the current images are known bad (my fault) and a respin is pending
<slangasek> but waits for new xorg package to propagate
<wxl> slangasek: i understand that but i just got a notice that the alternates were disabled. i assume you're just trying to keep people from wasting tests on them?
<slangasek> wxl: yes
<wxl> slangasek: k cool, thx :)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-taskbar (yakkety-proposed/universe) [52.0-1 => 52.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-taskbar [sync] (yakkety-proposed) [52.0-3]
-queuebot:#ubuntu-release- Unapproved: jing-trang (yakkety-proposed/universe) [20131210+dfsg+1-5 => 20131210+dfsg+1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jing-trang [sync] (yakkety-proposed) [20131210+dfsg+1-6]
<nacc> slangasek: jgrimm: looks like ppc64el passes fine with the default case, in a VM. Marked as such on qa tracker
<jgrimm> nacc, thanks
-queuebot:#ubuntu-release- Unapproved: libopenraw (yakkety-proposed/universe) [0.0.9-3.9 => 0.0.9-3.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libopenraw [sync] (yakkety-proposed) [0.0.9-3.10]
-queuebot:#ubuntu-release- Unapproved: fastqc (yakkety-proposed/universe) [0.11.5+dfsg-3 => 0.11.5+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fastqc [sync] (yakkety-proposed) [0.11.5+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: gtkballs (yakkety-proposed/universe) [3.1.5-10 => 3.1.5-11] (no packageset) (sync)
<slangasek> nacc: do you have time to test powerpc also? (should also be doable in a vm)
-queuebot:#ubuntu-release- Unapproved: accepted gtkballs [sync] (yakkety-proposed) [3.1.5-11]
-queuebot:#ubuntu-release- Unapproved: krb5-auth-dialog (yakkety-proposed/universe) [3.20.0-1 => 3.20.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted krb5-auth-dialog [sync] (yakkety-proposed) [3.20.0-2]
-queuebot:#ubuntu-release- Unapproved: kpcli (yakkety-proposed/universe) [3.1-2 => 3.1-3] (no packageset) (sync)
<smoser> anyone able to ack https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1493188
<ubot5> Ubuntu bug 1493188 in cloud-utils (Ubuntu Xenial) ""overlayfs" no longer exists" [Medium,Confirmed]
<pitti> doko: this time it wasn't me
<doko> ta, but it still seems to happen ...
-queuebot:#ubuntu-release- Unapproved: accepted libtorrent-rasterbar [sync] (yakkety-proposed) [1.1.0-3]
-queuebot:#ubuntu-release- Unapproved: libffi (yakkety-proposed/main) [3.2.1-4 => 3.2.1-6] (core) (sync)
<valorie> wonderful release team, I wanted to seed the beta2 torrents, but so far am not seeing them on http://torrent.ubuntu.com:6969/
<slangasek> valorie: I haven't started staging any of the beta2 stuff, still waiting for everything to be marked ready
<slangasek> which currently means ubuntu server, xubuntu, and lubuntu (which will take longer because the images aren't yet built)
<valorie> ok
<valorie> I'll chill then
<valorie> thanks for all your hard work and I hope you get some sleep after this past week's intensity
<flocculant> slangasek: hi - as intimated last week at the start of beta 2 - we are not releasing this beta
<nacc> slangasek: yes i can
<flocculant> slangasek: mostly because of bug 1622303
<ubot5> bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resumes to black screen" [Critical,Confirmed] https://launchpad.net/bugs/1622303
<slangasek> flocculant: ah, you consider that bug severe enough to not release the beta at all?
<flocculant> yep
<slangasek> ok, gotcha - thanks
<flocculant> slangasek: you know what people are like - install something like final beta and not read anything about it ;)
<slangasek> and, normally "no beta" would mean "no release", but in this case it's clear that the community has done the testing and found a showstopper that's currently out of your control
<slangasek> not that you're just skipping to skip ;)
<flocculant> :)
-queuebot:#ubuntu-release- Unapproved: crash (yakkety-proposed/main) [7.1.5-1ubuntu1 => 7.1.5-1ubuntu2] (core)
<flocculant> at least we found one for you while fiddling about too :)
<flocculant> slangasek: also we've been patiently waiting for final beta to finish before we talk to people in -release about what we can do
<flocculant> *we* mostly being bluesabre :p
<slangasek> flocculant: well, you should probably bypass the release team and talk directly with the lightdm devs
<flocculant> slangasek: currently because we don't know what's likely to happen - and not much time, we've been looking at not using light-locker
<flocculant> but - the ins and outs I'm not proficient enough to really discuss that
-queuebot:#ubuntu-release- Unapproved: openstack-trove (xenial-proposed/universe) [1:5.1.0-0ubuntu1 => 1:5.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1 => 0.27ubuntu1.1] (edubuntu, ubuntu-server)
<tsimonq2> flocculant: "oh, we're only participating in the final beta"
 * tsimonq2 runs
<tsimonq2> :P
<flocculant> tsimonq2: yes - we did - it fails - we're not releasing - seems pretty sensible to us
<tsimonq2> flocculant: I know, I was joking ;)
<tsimonq2> flocculant: it's logical
<lamont> dear archive masters... Can I have cloud-initramfs-tools in xenial-proposed pls?
<nacc> slangasek: hrm, you wouldn't happen to have a reference command-line, do you? virt-manager is having quite a bit of trouble setting up any such guest, so I think i'll have to use qemu directly (afaict)
<lamont> nacc: what are you trying to get it to do?
<nacc> lamont: trying to help test the powerpc iso (server)
<lamont> oh.  yeah, that'd be ENOCLUE for me
<nacc> lamont: i was able to test the ppc64le iso using virt-manager
<nacc> and iirc, i should be able to do powerpc, but it might ... take some fiddling with options :)
<nacc> slangasek: ok, i got some help from smoser -- and it seems like something might be wrong on the powerpc isos, i'm not able to get hte installer to see the cdrom in a guest
<slangasek> pitti: ppc64el and armhf autopkgtests unhappy?  I see we have quite the queue
<nacc> slangasek: i just tested 16.04 daily and it works fine
<tsimonq2> slangasek: what are we waiting on now?
<slangasek> nacc: right, so it's still affected by the sort of problem we're dealing with from the 4.8 kernel reorg.  Please file a bug on linux, and we'll omit the powerpc image from the beta
<wxl> tsimonq2: images
<tsimonq2> wxl: Lubuntu Alternate? that's disabled in iso.qa.ubuntu.com...
<wxl> tsimonq2: it's disabled so no one wastes their time testing. read lubuntu-devel :)
<tsimonq2> oh sorry Steve
<slangasek> yes, and autopkgtest results didn't come through timely for the new xorg build so I'm now pushing xorg through in parallel to kicking the autopkgtest runners
<tsimonq2> ok
<slangasek> (I think we can safely assume that a one-line packaging change to one of the xorg metapackages on amd64 and i386 will not have regressed systemd on armhf or ppc64el :P)
<nacc> slangasek: ok, will do, thanks
<slangasek> hmmmm ppc64el seems to be genuinely behind rather than dead
<slangasek> so no kicking after all, just staring
<slangasek> but xorg hinted through all the same, which means ETA 1.5-2h for lubuntu alternate images tsimonq2 wxl
<wxl> thx slangasek
<tsimonq2> ok thank you slangasek
<nacc> slangasek: LP: #1628284 and tagged in the isoqa
<ubot5> Launchpad bug 1628284 in linux (Ubuntu) "yakkety: daily powerpc server ISO fails to find cdrom during install in a VM" [Undecided,New] https://launchpad.net/bugs/1628284
<tsimonq2> slangasek: in the meantime, Ubuntu Server seems well tested, so idk who is the contact for that (or if you want to do it yourself) but it looks to me like it's good to go
<slangasek> tsimonq2: yes, I'm flipping the switch on those right now (except powerpc which is a dud)
<tsimonq2> ok thank you slangasek
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: vte2.91 (yakkety-proposed/main) [0.44.2-1ubuntu2 => 0.44.2-1ubuntu3] (ubuntu-desktop)
<nacc> slangasek: thanks!
<slangasek> stgraber: where do I set the default milestone for the iso tracker, so that publish-image-set DTRT?
<stgraber> slangasek: ~/.isotracker.conf
<slangasek> heh
<slangasek> so it is
<pitti> â« pgrep -af runner/autopkgtest.*ppc64|wc -l
<pitti> 20
<pitti> slangasek: ^ running at full steam, we just have a loooot of requests
<slangasek> pitti: yup, seems so
<pitti> slangasek: two Qts last night again, plus lots in unapproved that got acked this morning
<slangasek> pitti: does this mean ppc64el is underpowered compared with x86+s390x?
<pitti> slangasek: certainly less power than x86; we have 56 parallel slots for i386+amd64 combined, and ppc64el instances boot significantly slower
<pitti> it spends like a minute or two in OF
<slangasek> right
<infinity> pitti: Err, it does what not?
<infinity> pitti: OF should be a blink of an eye.
<slangasek> wxl, tsimonq2: just got notification that xorg has been accepted into yakkety, so confirming my earlier estimation of the timeline
<infinity> s/not/now/
<tsimonq2> slangasek: awesome!!! :D
<infinity> pitti: IME, ppc64 VMs boot much faster than x86, not the other way around, so maybe we're doing something very wrong in scalingstack.
<pitti> infinity: well, I know that reboots take ages, unlike on x86 where it's like 10s
<infinity> pitti: There is a grub bug that makes it sit around asking for a key for 5 or 10s if you're not at the console.  But hardly any 2m delays.  And OF itself is pretty much instant and then gone.
<nacc> yeah, something sounds off there
<infinity> pitti: If you have console access to one of those, I'd be quite interested to know what it appears to be doing, or where the delay appears to be.
<slangasek> pitti: perhaps it's shutdown rather than boot?
<infinity> Shutdown of an ephemeral image should be just cutting the power.
<infinity> Oh, I guess not for autopkgtest, where you install and reboot.
<pitti> ah, indeed it's more like 30s these days
<slangasek> maybe it needs kbd 1.15.5-1ubuntu5 from xenial-proposed :)
<pitti> I suppose I mixed it up with arm64 then
<pitti> where I do see a massive wait/delay at boot
<infinity> pitti: Even 30s is dog slow, so I'd love to debug a bit some time.
<infinity> (And we really should fix that grub bug, which is a good chunk of that time, I bet)
<tsimonq2> heyo release team. *after beta is shipped* it would be good to get eyes on these: bug 1615437 bug 1626332 , even though Lubuntu doesn't ship PowerPC for non-LTS releases, it might affect server as well.
<ubot5> bug 1615437 in ubiquity (Ubuntu) "Lubuntu 'entire disk installation' doesn't find yaboot (16.10, ppc)" [Undecided,Confirmed] https://launchpad.net/bugs/1615437
<ubot5> bug 1626332 in linux (Ubuntu) "Ubuntu MATE 16.10 fails to boot with linux-image-4.8.0-11-generic kernel on PowerMac G5 7,3" [Undecided,Confirmed] https://launchpad.net/bugs/1626332
 * tsimonq2 wants beta shipped if you couldn't tell ;)
<wxl> bro, chillax. :)
<tsimonq2> oh, and I forgot, MATE too ;)
<tsimonq2> wxl: about what? :P
<bdmurray> cjwatson, infinity: does wily still need to be supported?
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu4 => 0.125ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.2 => 0.122ubuntu8.3] (core)
<infinity> bdmurray: No.
<infinity> bdmurray: Oh, do you mean "set to supported in the UI" or actually supported?
<slangasek> the first :)
<infinity> bdmurray: I got sidetracked while working on an archive cleaning script that needs to be run before the former happens.
<infinity> Well, doesn't "need" to, but it'd save a ton of space.
<valorie> wily eof: July 28, 2016
<infinity> Maybe I'll finish that off tonight.  Feeling antisocial.
<infinity> tsimonq2: I can have a look on the weekend, but without a PMac, I might need a victim^Wtester to walk through things.
<cyphermox> infinity: I volunteer.
<slangasek> (.oO "as tribute")
<infinity> cyphermox: Your G5 is happy enough to abuse now?  Yay.
<tsimonq2> infinity: that's what I lack. Thank you.
<cyphermox> I have a powered-off pmac laying under the desk
<cyphermox> infinity: I managed to install MATE on it, so things should "work"
<infinity> cyphermox: Kay.  Hit me up outside work hours and we'll play.  If we can make everything work on my Powerstation, your G5, and a SLOF VM, I call it good.
<cyphermox> well, just ping me whenever you're ready, in the meantime I'll do a new install to make sure it hasn't rotted to death yet
<bdmurray> infinity: I also meant in the meta-release files
<infinity> bdmurray: Absolutely shouldn't be supported in meta-release.
<infinity> bdmurray: Consider the LP state an oops of the same type as vivid.  For all external purposes, V and W are unsupported.
<infinity> (V is more complicated, but from the community distro POV, it's dead)
<bdmurray> infinity: I do but thought cjwatson mentioned sometthing about some servers in the DC and some RT I've forgotten
<infinity> bdmurray: He was mistaken.  Ish.
<infinity> bdmurray: Some arm64 kit is running wily kernels, but the kernel team isn't supporting them regardless of the LP state, so it's a moot point.  If we need new kernels before upgrading to xenial, we can build in a PPA.
<bdmurray> Okay
<wxl> hey i've got a G5 PowerMac if you guys want
<wxl> someone's gotta pay shipping for the beast tho
<infinity> wxl: Which generation?
<infinity> wxl: I'd be interested in the last and shiniest (need to look up the model number), but nothing earlier.
<infinity> wxl: Oh, wait, which continent are you on?
<wxl> infinity: it's an A1047. i'm in the US.
<tsimonq2> hm I wonder where I can get one
<wxl> i've got some G4s but i doubt you want those :)
<tsimonq2> why not?
<infinity> wxl: A1047 covers a bunch of models.  I'm looking for 7,2, 7,3, 11,2... Those numbers.
<infinity> (Personally, I'm after an 11,2, which is hard to find)
<wxl> infinity: bah, it doesn't say on the outside
<infinity> wxl: Do you know the CPU specs?
<wxl> no
<wxl> i'll boot it sometime for you
<infinity> Heh.  Kay.
<slangasek> lubuntu alternate images didn't spin on their own because epoch + grep fail (grr), but we should still manage to keep the original ETA
<tsimonq2> argh ok cool slangasek
-queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu1 => 4.3.0+nmu1ubuntu2] (core)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been updated (20160927.5)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Beta 2] has been updated (20160927.5)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been updated (20160927.5)
<slangasek> rcj, gaughen, Odd_Bloke: https://wiki.ubuntu.com/YakketyYak/Beta2/ReleaseAnnouncement created with a pointer to http://cloud-images.ubuntu.com/daily/server/yakkety/, please season to taste
<gaughen> slangasek, I don't like it too salty, but I like it spicy!
<slangasek> gaughen: http://weebls-stuff.com/toons/hot-tamales-animated-music-video-mrweebl/
<sarnold> it'd be nice if zeromq3 could move through the update_excuses; zmqpp went through yesterday with a versioned build dependency upon zeromq3 that's stuck in proposed. As it stands, zmqpp will FTBFS if built against what's in the archive.
<sarnold> (the zmqpp package was compiled in a ppa with the newer zeromq3 package, and slid in to the archive sideways like..)
<gaughen> great slangasek now I have that stuck in my head. I deserved that though.
<slangasek> sarnold: AIUI there is a legit regression in pyzmq that sil2100 needs to fix in order to get the autopkgtests passing; and the fact that this came from a ppa doesn't affect how it was built, we always build against -proposed. So this is normal churn and will be sorted for release
<sarnold> slangasek: aha, nice.
<sarnold> slangasek: for myself, it'd be nice to have it sorted out sooner than later, because my review tooling goes way better if I can build it locally; but I at least don't have to be a hardass about "FTBFS means we can't support it"  :)
<sarnold> thanks slangasek :)
-queuebot:#ubuntu-release- Unapproved: xfsdump (yakkety-proposed/main) [3.1.6+nmu1 => 3.1.6+nmu1build1] (core)
<slangasek> tsimonq2, wxl: right, lubuntu alternate have just posted
<wxl> slangasek: yep, saw. emailed our team and started downloading
<slangasek> ok
<slangasek> "just" posted, I guess you have 20 minutes lead on me ;)
<wxl> well apparently
<wxl> so did queuebot
<wxl> 1602 -queuebot:#lubuntu-devel- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been updated (20160927.5)
<slangasek> yup!
<tsimonq2> downloading myself
<tsimonq2> slangasek: this is what y'all are waiting for then? ;)
<slangasek> wxl: also, it appears https://wiki.ubuntu.com/YakketyYak/Beta2/Lubuntu is a dead link
<slangasek> as is https://wiki.ubuntu.com/YakketyYak/Beta2/UbuntuKylin
<wxl> tsimonq2: i thought you took care of the release notes?
<slangasek> and https://wiki.ubuntu.com/YakketyYak/ReleaseNotes/Beta2/UbuntuStudio
<wxl> sakrecoer: your beta2 notes don't seem to be in the canonical place
<wxl> i don't think i've ever seen one of the release managers of kylin here so you should try email on that slangasek
<slangasek> ah https://wiki.ubuntu.com/YakketyYak/Beta2/UbuntuStudio exists so I'll point there instead
<wxl> sakrecoer: nevermind :)
<tsimonq2> wxl: not dead any more ;)
<valorie> all those links are dead until we create the pages, correct?
 * valorie started the Kubuntu one
<tsimonq2> valorie: correct
<wxl> thx tsimonq2
<tsimonq2> np wxl
<slangasek> ypwong: hi, I noticed you had a hand in editing of https://wiki.ubuntu.com/YakketyYak/Beta1/UbuntuKylin - will you also be creating https://wiki.ubuntu.com/YakketyYak/Beta2/UbuntuKylin ?
<slangasek> ypwong: (release delayed from last week but finally getting there, we're just a couple hours from being in a position to send out the announcement mail)
<wxl> booting
<tsimonq2> wxl: you marking as in progress on the tracker so work isn't duplicated? ;)
<wxl> yes yes i'm getting there
<tsimonq2> (cause if you mean booting after installation we might have duplicated work if you're doing amd64)
<wxl> i'm on i386
<tsimonq2> oh cool
<tsimonq2> ok
<wxl> ugh chrome crashed on me
-queuebot:#ubuntu-release- Unapproved: twm (yakkety-proposed/universe) [1:1.0.9-1ubuntu1 => 1:1.0.9-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted twm [source] (yakkety-proposed) [1:1.0.9-1ubuntu2]
<cyphermox> slangasek: if you're still around, could you please review initramfs-tools's in xenial and yakkety?
#ubuntu-release 2016-09-28
<slangasek> cyphermox: let's see
<slangasek> cyphermox: I don't want to review the shell code; you've tested this?
<slangasek> cyphermox: there's still a 'ROUNDTTT' outer loop here, isn't there?  Do we not care that DEVICE= is modified after the first loop?
<slangasek> of course, the ROUNDTTT variable isn't being used in the dhclient case, either
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (yakkety-proposed/main) [3.20.2-1ubuntu3 => 3.20.2-1ubuntu4] (ubuntu-desktop)
<cyphermox> well, it could be if things are failing, but then DEVICE will be reset too.
<cyphermox> I tested it here for both xenial and yakkety with rootfs on iscsi
<slangasek> cyphermox: ah indeed, it does reset on the next loop
<slangasek> ok lgtm
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: brltty (yakkety-proposed/main) [5.4-0ubuntu3 => 5.4-0ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (yakkety-proposed/main) [0.29-0ubuntu3 => 0.29-0ubuntu4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: witty (yakkety-proposed/universe) [3.3.5+dfsg-1ubuntu1 => 3.3.5+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted witty [source] (yakkety-proposed) [3.3.5+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: netatalk (yakkety-proposed/universe) [2.2.5-1 => 2.2.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted netatalk [source] (yakkety-proposed) [2.2.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160922-0ubuntu1 => 0.1.1+16.10.20160926.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20160926.1-0ubuntu1]
-queuebot:#ubuntu-release- New source: ubuntu-terminal-app (yakkety-proposed/primary) [0.7.216]
<slangasek> wxl: your guided install test still in progress on i386?
<wxl> slangasek: yeah. just got home. had to go to a shindig while it was still running
<slangasek> wxl: ok.  I think that's the only outstanding test at the moment; once that's done, assuming success are you happy for us to publish?
<wxl> slangasek: probably. if there's something wrong with the notes, it should be minor and readily resolved
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [ppc64el] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [amd64] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [armhf] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [arm64] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [i386] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-1 => 10.2.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-2]
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [s390x] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libfilezilla (yakkety-proposed/universe) [0.6.1-1 => 0.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-schema (yakkety-proposed/universe) [0.6.2-1 => 0.6.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libfilezilla [sync] (yakkety-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- Unapproved: lbfgsb (yakkety-proposed/universe) [3.0+dfsg.2-1 => 3.0+dfsg.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-schema [sync] (yakkety-proposed) [0.6.5-1]
-queuebot:#ubuntu-release- Unapproved: netqmail (yakkety-proposed/universe) [1.06-5 => 1.06-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcypher-parser (yakkety-proposed/universe) [0.5.1-1 => 0.5.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lbfgsb [sync] (yakkety-proposed) [3.0+dfsg.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted netqmail [sync] (yakkety-proposed) [1.06-6]
-queuebot:#ubuntu-release- Unapproved: accepted libcypher-parser [sync] (yakkety-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src-gles (yakkety-proposed/universe) [5.6.1-7ubuntu1~2 => 5.6.1-7ubuntu2~1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (yakkety-proposed/main) [5.6.1-7ubuntu1~2 => 5.6.1-7ubuntu2~1] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src-gles [sync] (yakkety-proposed) [5.6.1-7ubuntu2~1]
-queuebot:#ubuntu-release- Unapproved: sofia-sip (yakkety-proposed/universe) [1.12.11+20110422.1-2ubuntu1 => 1.12.11+20110422.1-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sofia-sip [sync] (yakkety-proposed) [1.12.11+20110422.1-2.1]
-queuebot:#ubuntu-release- Unapproved: evolution-rss (yakkety-proposed/universe) [0.3.95-5ubuntu1 => 0.3.95-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-rss [sync] (yakkety-proposed) [0.3.95-6]
* slangasek changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1, Yakkety final beta2 | Archive: feature freeze, final beta freeze | Yakkety Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<flocculant> slangasek: I bet you're glad to have said that :)
<flocculant> thanks
<slangasek> yep, bedtime now ;)
-queuebot:#ubuntu-release- Unapproved: doona (yakkety-proposed/universe) [0.7+git20131211-1 => 1.0+git20160212-1] (no packageset) (sync)
<flocculant> sleep the sleep of the righteous :)
-queuebot:#ubuntu-release- Unapproved: accepted doona [sync] (yakkety-proposed) [1.0+git20160212-1]
-queuebot:#ubuntu-release- Unapproved: arp-scan (yakkety-proposed/universe) [1.8.1-2ubuntu1 => 1.9-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted arp-scan [sync] (yakkety-proposed) [1.9-1]
-queuebot:#ubuntu-release- New binary: kactivities-kf5 [powerpc] (yakkety-proposed/universe) [5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: filezilla (yakkety-proposed/universe) [3.20.0-1ubuntu2 => 3.21.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted filezilla [source] (yakkety-proposed) [3.21.0-2ubuntu1]
-queuebot:#ubuntu-release- Builds: 34 entries have been added, updated or disabled
<pitti> slangasek: congrats!
<pitti> slangasek: I *knew* there was something fishy when nothing came up last Wednesday :/
<acheronuk> can someone accept kjsembed in the queue? that is a blocker on plasma desktop bugfix updates building on armhf
 * acheronuk cheers for beta release. good job
<flocculant> pitti: running out of time here before work, but when you did http://changelogs.ubuntu.com/changelogs/pool/universe/x/xubuntu-default-settings/xubuntu-default-settings_16.10.1/changelog did something similar happen to Ubuntu - ref the bugs on https://lists.ubuntu.com/archives/ubuntu-release/2016-September/003908.html
<flocculant> because if I go back to before that change - locking works and so does the guest session
<flocculant> bbl
<pitti> slangasek: will you deal with dropping the beta-2 block hints, or want me to?
<pitti> flocculant: will have a look
<flocculant> pitti: thanks :)
<jamespage> hi release team - I synced a NEW package from debian experimental yesterday - networking-sfc - needed for the new version of vmware-nsx which is compat with openstack newton
<jamespage> if it could be accepted that would unblock my upload for vmware-nsx
<jamespage> cheers
<jamespage> cpaelzer, ovs 2.6.0 is released
 * jamespage works that now
-queuebot:#ubuntu-release- Unapproved: networking-ovn (yakkety-proposed/universe) [1.0.0~rc1-0ubuntu1 => 1.0.0~rc2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (yakkety-proposed) [1.0.0~rc2-0ubuntu1]
<cpaelzer> thanks jamespage
-queuebot:#ubuntu-release- Unapproved: ifstat (yakkety-proposed/universe) [1.1-8build1 => 1.1-8.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ifstat [sync] (yakkety-proposed) [1.1-8.1]
<pitti> Laney: I suppose slangasek went straight to a well-deserved sleep after sending the announcement; do you know a reason to not unblock?
-queuebot:#ubuntu-release- New: accepted networking-sfc [sync] (yakkety-proposed) [2.0.1~git20160926.27f311e-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [sync] (yakkety-proposed) [0.3-1]
<pitti> jamespage: done
<jamespage> pitti, thanks!
<Laney> pitti: I don't; we would normally do that at the same time as releasing (or when it becomes clear there will be no more respins)
<pitti> jamespage: it'll hit binNEW again, so if I forget, please prod me again
<jamespage> willdo
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [amd64] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [armhf] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [powerpc] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [s390x] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [arm64] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [ppc64el] (yakkety-proposed) [5.26.0-0ubuntu1]
<Laney> I forgot exactly when we put a full britney block in though
-queuebot:#ubuntu-release- New: accepted kactivities-kf5 [i386] (yakkety-proposed) [5.26.0-0ubuntu1]
<Laney> Might be worth doing some archaeology to find out when we did that last cycle (I think later on)
<pitti> Laney: ok; there's a metric ton of stuff that's ready, and it woudl help to clean up to figure out what's wrong with the rest of it
<pitti> imestamp: Thu 2016-08-25 23:05:47 +0100
<Laney> timestamp: Tue 2016-04-19 21:31:30 +0100
<Laney> message: Add block for xenial final
<pitti> message:
<pitti>   Drop beta 1 freeze
<Laney> ok
<pitti> Thursday evening, that sounds pretty much like "after release"
<Laney> i'll do it
<pitti> Laney: cheers
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [ppc64el] (yakkety-proposed/none) [0.3-1] (no packageset)
<Laney> As long as we can take the blame together. :P
 * pitti looks at the rest of NEW
<Laney> (done)
<pitti> Laney: I'll take the bullet :)
<Laney> I want to finish up gnome-keyring/upstart/unity-lens-applications and then will take a blast through the queue
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [amd64] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [i386] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [sync] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted mcloud [sync] (yakkety-proposed) [1.0.0+16.10.20160927.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [arm64] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: networking-sfc [amd64] (yakkety-proposed/none) [2.0.1~git20160926.27f311e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [armhf] (yakkety-proposed/none) [0.3-1] (no packageset)
<pitti> flocculant: looks like that bug already has the necessary apparmor profile update?
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [ppc64el] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [i386] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [amd64] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [arm64] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [armhf] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [s390x] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [amd64] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [armhf] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [ppc64el] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [s390x] (yakkety-proposed/none) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [arm64] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [s390x] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [i386] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [powerpc] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [powerpc] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: qtwebchannel-opensource-src [powerpc] (yakkety-proposed/universe) [5.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [amd64] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [armhf] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [powerpc] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [s390x] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [arm64] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [ppc64el] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted qtwebchannel-opensource-src [i386] (yakkety-proposed) [5.6.1-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [source] (yakkety-proposed) [0.7.216]
<pitti> jamespage: meh, new python2 packages? without a py3 one?
<pitti> (sfc-networking)
<jamespage> pitti, its a constraint due to the fact that neutron is not quite there yet with py3
<jamespage> next cycle there is a cross project objective to get to py3
<jamespage> so it might actually happen...
-queuebot:#ubuntu-release- New: accepted networking-sfc [amd64] (yakkety-proposed) [2.0.1~git20160926.27f311e-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-getting-started-docs [source] (yakkety-proposed) [3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gtkimageview [sync] (yakkety-proposed) [1.6.4+dfsg-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted qqwing [sync] (yakkety-proposed) [1.3.4-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted media-hub [sync] (yakkety-proposed) [4.6.0+16.10.20160909-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [ppc64el] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [amd64] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [i386] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (yakkety-proposed) [1.8.7-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted eigen3 [source] (yakkety-proposed) [3.3~beta2-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted murano [sync] (yakkety-proposed) [1:3.0.0~rc1-1]
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [arm64] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [s390x] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (yakkety-proposed) [7.1.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (yakkety-proposed) [0.29-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (yakkety-proposed) [5.6.1-7ubuntu2~1]
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [armhf] (yakkety-proposed/none) [0.7.216] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted brltty [source] (yakkety-proposed) [5.4-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (yakkety-proposed) [3.20.2-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted xfsdump [source] (yakkety-proposed) [3.1.6+nmu1build1]
-queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kjsembed [source] (yakkety-proposed) [5.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (yakkety-proposed) [0.44.2-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libffi [sync] (yakkety-proposed) [3.2.1-6]
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (yakkety-proposed/universe) [3.22.0-1ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [powerpc] (yakkety-proposed/none) [0.7.216] (no packageset)
<xnox> Laney, wasn't the freeze meant to stay on until the release?!
<pitti> xnox: unapproved yes
<pitti> xnox: but not the migration blocks
<xnox> ah, that.
<Laney> Be calm
<Laney> :)
<xnox> pitti, so we don't need to "contact #ubuntu-release" to unblock every tiny package from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html right?
<pitti> correct
<xnox> cool.
<pitti> we review stuff between upload and accepting into -proposed (i. e. in unapproved)
-queuebot:#ubuntu-release- Unapproved: rejected libgksu [source] (yakkety-proposed) [2.0.13~pre1-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libgksu (yakkety-proposed/universe) [2.0.13~pre1-8ubuntu1 => 2.0.13~pre1-9ubuntu1] (edubuntu)
<flocculant> pitti: yes - but if I use newest xubuntu default settings, that apparmor update and light locker - we are hit with bug 1622303
<ubot5> bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resumes to black screen" [Critical,Confirmed] https://launchpad.net/bugs/1622303
<flocculant> so still not right here
-queuebot:#ubuntu-release- Unapproved: libdbusmenu (xenial-proposed/main) [12.10.3+16.04.20160223.1-0ubuntu1 => 16.04.1+16.04.20160927-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libdbusmenu (yakkety-proposed/main) [12.10.3+16.04.20160223.1-0ubuntu1 => 16.04.1+16.10.20160927.2-0ubuntu1] (ubuntu-desktop) (sync)
<bluesabre> flocculant, pitti, the only change to xubuntu-default-settings (between working and broken locking) was the migration to the systemd user session, https://launchpad.net/ubuntu/yakkety/+source/xubuntu-default-settings/+changelog
<bluesabre> flocculant, pitti, for the sake of simplicity, is it a release requirement for yakkety that all desktop sessions by moved over to the systemd units, or would it be fine if we were to roll back those changes (since they seem to be not fully compatible for xfce/light-locker)?
<pitti> bluesabre: it's fine to roll back; we specifically did the transition in a way to not have a lockstep
<pitti> bluesabre: you can confirm that it's working by changing the Exec= line back to the previous value
<bluesabre> pitti, thanks, will check that out
<pitti> -Exec=startxfce4
<pitti> +Exec=/usr/share/xfce4/scripts/run-systemd-session xubuntu-session.target
<pitti> i. e. revert that
<pitti> if that works, there is a bug in the systemd migration
<pitti> if not, something else changed
<pitti> bluesabre: my suspicion is that this is actually fallout from moving from session to user bus
<pitti> as the unit itself is quite simple -- the entire session runs in one unit, it's not split up
<pitti> (yet)
<bluesabre> pitti, yes, only making that changes restores the previous locking behavior (everything works)
<pitti> bluesabre: ok, thanks (and sorry for not noticing)
<pitti> bluesabre: so I guess upload that change for now to take the pressure off?
<bluesabre> pitti, no problem. We'll go ahead and make these changes for yak, is there anything else you'd like me to investigate or should we save it for z now?
<pitti> bluesabre: I'll try to get around to debugging it properly, but upstart will stay around for y anyway, so this isn't urgent
<pitti> try before y, I mean
<Ukikie> bluesabre: Look at -session too.
<bluesabre> pitti, great, thanks
<bluesabre> Ukikie, already on it :)
<pitti> bluesabre: thank you!
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (yakkety-proposed/universe) [16.10.1 => 16.10.2] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15.2ubuntu1 => 2.16] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.15.2+16.10.3 => 2.16+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (yakkety-proposed/main) [2.12.5-1 => 2.14.0-1] (kubuntu, ubuntu-desktop) (sync)
<jbicha> tracking bug for webkit2gtk is bug 1625897
<ubot5> bug 1625897 in webkit2gtk (Ubuntu) "Update webkitgtk to 2.14.0 in yakkety" [Wishlist,New] https://launchpad.net/bugs/1625897
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (yakkety-proposed/universe) [16.10.4 => 16.10.5] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: jmock (yakkety-proposed/universe) [1.2.0-3 => 1.2.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jmock [sync] (yakkety-proposed) [1.2.0-4]
 * apw has a look at the snapds
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20160908-0ubuntu1 => 16.10+16.10.20160926-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-lens-applications (yakkety-proposed/main) [7.1.0+16.10.20160602-0ubuntu1 => 7.1.0+16.10.20160927-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: vinagre (yakkety-proposed/universe) [3.18.2-1build1 => 3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: libgnomekbd (yakkety-proposed/main) [3.6.0-1ubuntu2 => 3.22.0.1-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.16+16.10]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.5 => 20101020ubuntu451.6] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-session (yakkety-proposed/main) [3.20.2-1ubuntu3 => 3.20.2-1ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu31 => 1.13.2-0ubuntu32] (core)
<Laney> pitti: ^- those two would be best reviewed by you for sanity
<flocculant> pitti: thanks for looking at that earlier - I can now not panic :)
-queuebot:#ubuntu-release- Unapproved: indicator-appmenu (yakkety-proposed/main) [15.02.0+16.04.20151104-0ubuntu1 => 15.02.0+16.10.20160927-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New sync: python-tenacity (yakkety-proposed/primary) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~b2+dfsg1-1 => 4.0.0~rc1+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0~rc1+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libgksu [source] (yakkety-proposed) [2.0.13~pre1-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libdbusmenu [sync] (yakkety-proposed) [16.04.1+16.10.20160927.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20160926-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-lens-applications [sync] (yakkety-proposed) [7.1.0+16.10.20160927-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-appmenu [sync] (yakkety-proposed) [15.02.0+16.10.20160927-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vinagre [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libgnomekbd [sync] (yakkety-proposed) [3.22.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (yakkety-proposed) [16.10.5]
<pitti> Laney: instead of copying the whole loop, would you mind just using state=active,failed?
<Laney> pitti: The action is different in each case
<pitti> Laney: oh, reset-failed vs. stop
<Laney> reset-fail
<Laney> yes :)
<pitti> Laney: I still don't understand how this can actually happen -- stopping the target shold stop all the units too
<pitti> due to the PartOf=; units can be failed afterwards, but not running
<Laney> It's in the case when the session crashes, so things don't get stopped
<Laney> Most things go to failed because they are connected to X, but not things like unity-gtk-module
<Laney> guess that it's mostly oneshot jobs
<pitti> Laney: my intention for this was to use restart; so "stop" and "start" separately should do that?
<pitti> Laney: but independently of the "how", good catch!
<Laney> I tried stop actually, but I think it didn't stop everything
<Laney> can't remember the details off the top of my head
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (yakkety-proposed) [16.10.2]
<pitti> Laney: ok; this is just optimization, so nevermind
<Laney> pitti: Okay - we can obviously fix that if it turns out to work
 * pitti presses da button
<Laney> I wonder if I was getting confused with the gnome-session part of the fix
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (yakkety-proposed) [3.20.2-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted upstart [source] (yakkety-proposed) [1.13.2-0ubuntu32]
<Laney> If I tried "stop", but gnome-session was killing the session - so I thought that "stop" didn't work
<Laney> and only later on realised what the real issue was
 * Laney shrugs
<Laney> thanks for reviewing!
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (yakkety-proposed) [2.27-8ubuntu2]
-queuebot:#ubuntu-release- Unapproved: openvswitch (yakkety-proposed/main) [2.6.0~git20160912.dc61b4e-0ubuntu4 => 2.6.0-0ubuntu1] (ubuntu-server)
<jamespage> ^^ that openvswitch update switches from snapshot from git -> final release of 2.6.0
<jamespage> its a bit diff because it also includes the autotools generated as part of the upstream release process for the tarball
<jamespage> bit/big
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.1 => 5.5.1+dfsg-16ubuntu7.2] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: anjuta (yakkety-proposed/universe) [2:3.20.0-1 => 2:3.22.0-1~ubuntu1] (desktop-extra)
<slashd> hi SRU team, can you please nominate LP: #1607920 affecting Xenial and Yakkety release ?
<ubot5> Launchpad bug 1607920 in zfs-linux (Ubuntu) "zfs services fail on firstboot if zfs-utils is integrated into the deployment image" [Medium,In progress] https://launchpad.net/bugs/1607920
<slashd> arges_ ^
<arges_> slashd: sure
<slashd> arges_ thanks
<slashd> arges thanks
-queuebot:#ubuntu-release- Unapproved: pysparse (yakkety-proposed/universe) [1.1-2 => 1.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pysparse [sync] (yakkety-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: libpam-mount (yakkety-proposed/main) [2.14-1.1 => 2.14-2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: twisted (yakkety-proposed/main) [16.4.0-2 => 16.4.1-1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu14 => 4.3.3-5ubuntu15] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.11.90.20160927-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [sync] (yakkety-proposed) [2.14-2]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (yakkety-proposed) [4.3.3-5ubuntu15]
-queuebot:#ubuntu-release- Unapproved: siege (yakkety-proposed/main) [4.0.2-1 => 4.0.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted siege [source] (yakkety-proposed) [4.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (yakkety-proposed) [3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [amd64] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [armhf] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [powerpc] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [s390x] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted python-tenacity [sync] (yakkety-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [i386] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [arm64] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [ppc64el] (yakkety-proposed) [0.7.216]
-queuebot:#ubuntu-release- New binary: python-tenacity [amd64] (yakkety-proposed/none) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-tenacity [amd64] (yakkety-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit-gles (yakkety-proposed/universe) [1.3.2085+16.10.20160915 => 1.3.2104+16.10.20160919.3] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-toolkit (yakkety-proposed/main) [1.3.2085+16.10.20160915 => 1.3.2104+16.10.20160919.3] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit-gles [sync] (yakkety-proposed) [1.3.2104+16.10.20160919.3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-ui-toolkit [sync] (yakkety-proposed) [1.3.2104+16.10.20160919.3]
-queuebot:#ubuntu-release- Unapproved: vmware-nsx (yakkety-proposed/universe) [8.0.0-2ubuntu2 => 9.0.0~git20160927.64c87d2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [source] (yakkety-proposed) [9.0.0~git20160927.64c87d2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gallery-app (yakkety-proposed/universe) [0.0.67+16.10.20160609.1-0ubuntu1 => 0.0.67+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gallery-app [sync] (yakkety-proposed) [0.0.67+16.10.20160921-0ubuntu1]
<slashd> hi SRU team and/or arges, can you also please nominate LP: #1452202 affecting Trusty, Xenial and Yakkety release ?
<ubot5> Launchpad bug 1452202 in netcfg (Ubuntu) "ubuntu preseed install fails to set a hostname" [Medium,In progress] https://launchpad.net/bugs/1452202
-queuebot:#ubuntu-release- Unapproved: libpam-mount (yakkety-proposed/main) [2.14-2 => 2.14-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [source] (yakkety-proposed) [2.14-2ubuntu1]
<arges> slashd: ok
<slashd> arges, thanks again ;)
-queuebot:#ubuntu-release- Unapproved: spl-linux (yakkety-proposed/universe) [0.6.5.8-0ubuntu1 => 0.6.5.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spl-linux [sync] (yakkety-proposed) [0.6.5.8-2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (yakkety-proposed/universe) [0.4+16.10.20160916-0ubuntu1 => 0.4+16.10.20160927-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-novaclient (xenial-proposed/main) [2:3.3.1-2 => 2:3.3.1-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: firefox (yakkety-proposed/main) [49.0+build4-0ubuntu1 => 49.0+build4-0ubuntu2] (kubuntu, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (xenial-proposed) [2:9.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (xenial-proposed) [2.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (xenial-proposed) [2:8.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (xenial-proposed) [1:5.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (xenial-proposed) [1:8.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (xenial-proposed) [2:8.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (xenial-proposed) [1:5.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (xenial-proposed) [1:4.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (yakkety-proposed) [49.0+build4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-novaclient [source] (xenial-proposed) [2:3.3.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (yakkety-proposed/main) [1.49.1-2ubuntu1 => 1.50.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gri (yakkety-proposed/universe) [2.12.23-9build4 => 2.12.23-9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gri [source] (yakkety-proposed) [2.12.23-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-6 (yakkety-proposed/main) [6.2.0-3ubuntu15 => 6.2.0-5ubuntu11] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted anjuta [source] (yakkety-proposed) [2:3.22.0-1~ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [source] (yakkety-proposed) [1.50.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (yakkety-proposed) [6.2.0-5ubuntu11]
-queuebot:#ubuntu-release- New sync: python-os-api-ref (yakkety-proposed/primary) [0.3.0+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: murano-agent (yakkety-proposed/universe) [1:3.0.0~b2-1 => 1:3.0.0~rc1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted murano-agent [sync] (yakkety-proposed) [1:3.0.0~rc1-1]
<pitti> apw: I'm sure you won't mind reviewing an 830 kB patch for an SRU, right?
 * pitti runs away really really fast
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [sync] (yakkety-proposed) [0.4+16.10.20160927-0ubuntu1]
<jgrimm> can openipmi in xenial migrate now? excuses says blocked on freeze (otherwise looks like it is verification-done)
<jgrimm> nacc^^ fyi
<slangasek> jgrimm: "blocked on freeze" is status quo for everything in SRU, we don't use proposed-migration to migrate those packages (yet).  The status on http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that bug #1311888 is not marked as verification-done
<ubot5> bug 1311888 in openipmi (Ubuntu Xenial) ""pkg-config --libs OpenIPMIpthread" fails" [Undecided,Fix committed] https://launchpad.net/bugs/1311888
<jgrimm> oh, that's a different bug i was looking at.  i'll sort
<jgrimm> slangasek, thanks, i was only looking at 1596474
<nacc> jgrimm: ack, it's on my list to go verify that one
<jgrimm> thanks nacc
<slangasek> I love that component-mismatches randomly reports different reverse-dependencies for platform-api in -proposed vs. devel
<wxl> slangasek: hey thanks for all the hard work yesterday/this week. glad to have the release finally done!
<slangasek> wxl: me too ;)  you're welcome
<slangasek> sorry I kneecapped the lubuntu image with that xserver-xorg-input-vmmouse removal
<wxl> and gee KernelFreeze is right around the corner, thank God!
<slangasek> (really sorry, since we could've been done 8 hours earlier if I hadn't ;)
<wxl> yeah well, stuff happens. at least the solution was fairly obvious
<wxl> slangasek: am i right to remember that we usually have final images the monday before release?
<slangasek> wxl: I believe the checklist says to start preparing these images 1 week before release; I can't say what's been typical for image availability recently
<doko> slangasek: will the release be delayed by a week?
<wxl> oh that's an interesting question
<slangasek> doko: no plans to do so
<wxl> argh where does that checklist live again slangasek ?
<wxl> slangasek: https://wiki.ubuntu.com/ReleaseProcess seems to suggest release-3
<wxl> slangasek: oh no i'm reading it wrong. release-6
-queuebot:#ubuntu-release- Unapproved: python3.5 (yakkety-proposed/main) [3.5.2-4ubuntu3 => 3.5.2-6] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.0~rc1-0ubuntu1 => 1:7.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu6 => 2.1.0-1ubuntu7] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.173 => 3.174] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0~rc1-0ubuntu1 => 3:10.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu13]
<slangasek> xnox: it seems that component-mismatches ignores Built-Using until the package is actually promoted, at which point it becomes "rescued", which unfortunately leaves these deps invisible from the high-level overview until the MIR is done.  Do you think that's fixable?
-queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.1.0-0ubuntu4 => 1:6.2.0-0ubuntu1] (openstack)
<tsimonq2> I thought main packages could have universe deps now?
<cjwatson> build-deps, not runtime deps
-queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0~rc1-0ubuntu1 => 2:10.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0~rc1-0ubuntu2 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.16]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (yakkety-proposed/main) [1:9.0.0~rc1-0ubuntu1 => 1:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (yakkety-proposed/universe) [2:9.0.0~rc1-0ubuntu1 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (yakkety-proposed/main) [2:9.0.0~rc1-0ubuntu1 => 2:9.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (yakkety-proposed/universe) [1:6.0.0~rc1-0ubuntu1 => 1:6.0.0~rc2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (yakkety-proposed) [1:6.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.9.0-0ubuntu1 => 2.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-core-meta (yakkety-proposed/universe) [0.6.14build1 => 0.6.15] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-core-meta [source] (yakkety-proposed) [0.6.15]
-queuebot:#ubuntu-release- Unapproved: python-swiftclient (yakkety-proposed/main) [1:3.0.0-3 => 1:3.1.0-1] (openstack, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-core-meta (yakkety-proposed/universe) [0.6.14build1 => 0.6.16] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-core-meta [source] (yakkety-proposed) [0.6.16]
<xnox> slangasek, i don't believe component-mismatches has any inteligence wrt built-using at the moment. At the time I looked at it, I did minimal work needed to generate britney excuse & generate seeds that roughly look correct.
<xnox> so in components missmatches, you want graph to generate extra edges for the built-using packages, and etc. i guess?
<xnox> (together with MIR links generated)
<slangasek> xnox: yeah basically :)
<xnox> ok. added a google keep post it note about this irc chat log
<infinity> xnox: Why would c-m need to understand built-using?  Nothing should end up in built-using without being a build-dep, and c-m already understands build-deps.
<infinity> (Or are we saying that if it's in built-using, it needs to be in the same component?)
<infinity> I guess that makes some sense.
<infinity> So, yeah.  I guess we didn't need built-using to be processed before reorg and now do.  Derp.  Ignore me.
<sakrecoer> wxl, slangasek: regarding the url for beta2 release notes of ubuntu studio: the link is wrong here: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes we used the same model for the url as everyone else...
<sakrecoer> oh, wait, i wasn't logged in :) i thought it was immutable..
<sakrecoer> i'll fix it then :)
-queuebot:#ubuntu-release- Unapproved: python-django (xenial-proposed/main) [1.8.7-1ubuntu5.2 => 1.8.7-1ubuntu5.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pollinate (precise-proposed/main) [4.21-0ubuntu1~12.04 => 4.23-0ubuntu1~12.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.21-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.21-0ubuntu1~16.04 => 4.23-0ubuntu1~16.04] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-41.61] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu1 => 1.0.42-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-41.61]
<slangasek> sakrecoer: thanks for fixing!  I link checked the email, since those really are immutable; the ones in the release notes were copy-paste from previous series
<valorie> ubuntu-release team: thanks so much for your work on the beta
<wxl> three cheers for release team
<wxl> hip hip
<wxl> horray
<wxl> hip hip
<wxl> horray
<wxl> hip hip
<wxl> horray!
<valorie> I hope we (the kubuntu team) can get the rest of our stuff into the final with your help
<valorie> hurray!
<wxl> valorie: in other words, prepare for many incoming requests? XD
<valorie> most are in -proposed I think
<valorie> but applications got freezed out
<wxl> yeah
<valorie> most of frameworks made it in
<wxl> well that's the most important stuff
<valorie> I hope the rest are migrating
<valorie> plasma seems to have made it
<wxl> i'd expect more changes in applications than in frameworks or plasma, tho. no?
<valorie> some if not most of apps is just bugfixes which would be really nice to have
<valorie> most of the work over the past year or so has been porting them to frameworks
<valorie> bugfixes are always wanted!
<wxl> neat
<wxl> i should upgrade from trusty/plasma4 one of these days
<valorie> lol
<wxl> i actually need to pull out my home and start from scratch, though. i tried using multiarch to migrate from i386 to amd64 and it's really a pain to deal with the packages. a fresh start would be much preferred
<valorie> ya think?
<wxl> that said, it's not even worth using the backports :/
 * valorie has been running yakkety since it opened for business
<valorie> on my production laptop
<wxl> at work i run what everyone else runs. i'm starting to rethink that idea tho XD
-queuebot:#ubuntu-release- Unapproved: rejected snap-confine [source] (yakkety-proposed) [1.0.42-0ubuntu2]
<wxl> due to TLS requirements, we're going to need to go 64 bit everywhere within the next year though, so everyone's going to get new machines/builds
<wxl> so they'll invariably end up with plasma5
<wxl> i'm not 100% sure i'm sold on the black and white icons, but hey, that's what Windows 10 is doing, so... ;)
<valorie> \o/
<valorie> everything is adjustable
<wxl> yes yes i know
<wxl> but i'm disinclined to mess with graphics stuff too much. you know me, i'm a cli guy mostly. in fact, though i type this to you through konsole, it's only one window cuz i got tmux ;)
<valorie> lol
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-41.61~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-41.61~14.04.1]
-queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.3 => 2.10.95-0ubuntu2.4] (core)
-queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu1 => 1.0.42-0ubuntu3] (no packageset)
<jdstrand> stgraber: fyi ^
<stgraber> looking at it and apparmor now
<stgraber> oh, apparmor was xenial, so not what I thought it was :)
<jdstrand> stgraber: no, not apparmor, snap-confine
<jdstrand> stgraber: I mean, tyhicks would probably appreciate a look at apparmor, but I was pointing at snap-confine :)
<tyhicks> stgraber: not what you thought it was but that apparmor upload is just a simple delta on top of the existing apparmor in -proposed to fix some regression test failures
<stgraber> accepted snap-confine, looking at apparmor for xenial now (different tool)
-queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (yakkety-proposed) [1.0.42-0ubuntu3]
<tyhicks> thanks
<jdstrand> stgraber: thanks!
<stgraber> apparmor accepted
<tyhicks> stgraber: thank you
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: singular (yakkety-proposed/universe) [4.0.3-p1+ds-3build2 => 4.0.3-p1+ds-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted singular [source] (yakkety-proposed) [4.0.3-p1+ds-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mako (yakkety-proposed/main) [1.0.4+ds1-1 => 1.0.4+ds1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: seabios (yakkety-proposed/main) [1.8.2-1ubuntu1 => 1.8.2-1ubuntu2] (ubuntu-server)
#ubuntu-release 2016-09-29
-queuebot:#ubuntu-release- Unapproved: accepted seabios [source] (yakkety-proposed) [1.8.2-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mako [source] (yakkety-proposed) [1.0.4+ds1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-dictionary (yakkety-proposed/universe) [3.20.0-2 => 3.20.0-3] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (yakkety-proposed/universe) [1.46.0-0ubuntu1 => 1.46.0-1] (desktop-extra, mozilla, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-5 (yakkety-proposed/main) [5.4.1-2ubuntu1 => 5.4.1-2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (yakkety-proposed) [5.4.1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-dictionary [sync] (yakkety-proposed) [3.20.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (yakkety-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- Unapproved: gce-utils (xenial-proposed/partner) [1.3.3-0ubuntu5~16.04.0 => 1.3.3-0ubuntu5~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kimwitu (yakkety-proposed/universe) [4.6.1-7.1ubuntu1 => 4.6.1-7.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kimwitu [sync] (yakkety-proposed) [4.6.1-7.2]
-queuebot:#ubuntu-release- Unapproved: open-invaders (yakkety-proposed/universe) [0.3-4.1ubuntu1 => 0.3-4.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted open-invaders [sync] (yakkety-proposed) [0.3-4.3]
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.2-0ubuntu1 => 2.3-0ubuntu1] (edubuntu, ubuntu-server)
<stgraber> FFe for ^ is https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1618159
<ubot5> Ubuntu bug 1618159 in lxd (Ubuntu) "[FFe] Feature Exception for LXD in Ubuntu 16.10" [Wishlist,Triaged]
 * sakrecoer echos wxl with a large delay and some acoustic modulation : 'hiophop hurray for release team 
<sakrecoer> hiphop even, and coffe cup saluts!
-queuebot:#ubuntu-release- Unapproved: linaro-image-tools (yakkety-proposed/universe) [2014.11-1 => 2016.05-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linaro-image-tools [sync] (yakkety-proposed) [2016.05-1]
-queuebot:#ubuntu-release- Unapproved: apparmor (yakkety-proposed/main) [2.10.95-4ubuntu4 => 2.10.95-4ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (yakkety-proposed) [2.10.95-4ubuntu5]
-queuebot:#ubuntu-release- Unapproved: diffoscope (yakkety-proposed/universe) [60 => 61] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted diffoscope [sync] (yakkety-proposed) [61]
-queuebot:#ubuntu-release- Unapproved: blender (yakkety-proposed/universe) [2.77.a+dfsg0-8 => 2.77.a+dfsg0-9] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-7 => 231-7ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: libqalculate (yakkety-proposed/universe) [0.9.7-9.1build2 => 0.9.7-9.1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.5]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.4 => 2.408.5] (desktop-core)
<handsome_feng> Hi, Laney, Seb128, Good morning! Sorry to disturb you again. I have update my new wizard package, Could you please have a look? The link is: https://bugs.launchpad.net/ubuntukylin/+bug/1609207 , Thank you !
<ubot5> Ubuntu bug 1609207 in Ubuntu Kylin "[needs-packaging] ubuntu-kylin-wizard" [High,Triaged]
<smb> pitti, has the beta gone out far enough that I could ask people to approve the xen ffe upload I did or should that still wait?
-queuebot:#ubuntu-release- Unapproved: owncloud-client (yakkety-proposed/universe) [2.1.1+dfsg-1ubuntu2 => 2.2.2+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [sync] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New binary: owncloud-client [ppc64el] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: owncloud-client [i386] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
<tjaalton> I've synced new owncloud-client ^, fixes 1628838 that I've verified
-queuebot:#ubuntu-release- New binary: owncloud-client [amd64] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
<tjaalton> bug 1628838
<ubot5> bug 1628838 in owncloud-client (Ubuntu) "No indicator seen on unity" [Undecided,New] https://launchpad.net/bugs/1628838
-queuebot:#ubuntu-release- New binary: owncloud-client [s390x] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
<LocutusOfBorg> sigh, systemd with a security update stuck in unapproved
<LocutusOfBorg> and the same security upload is already in the archive for ubuntu stable releases
<Laney> Hardly worth sighing about. It's more critical to get security fixes out to releases that are actually stable, and someone will look at the yakkety queue quite soon.
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (yakkety-proposed) [2.14.0-1]
<LocutusOfBorg> this is true, but fixing the development release and then stable isn't a better workflow?
<LocutusOfBorg> I mean, SRU works that way AFAIK
<LocutusOfBorg> I would have expected security pocket to avoid unapproved queue
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (yakkety-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xen [source] (yakkety-proposed) [4.7.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [sync] (yakkety-proposed) [16.4.1-1]
-queuebot:#ubuntu-release- Unapproved: linux-wlan-ng (yakkety-proposed/universe) [0.2.9+dfsg-5 => 0.2.9+dfsg-6] (lubuntu) (sync)
<LocutusOfBorg> oh, no security pocket for yakkety nvm
-queuebot:#ubuntu-release- New binary: owncloud-client [powerpc] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
<Mirv> do you think bug #1432741 is ok or not, probably quite clear "yeah it's safe" or "waaay too late".
<ubot5> bug 1432741 in libsdl1.2 (Ubuntu) "[FFe] sdl1.2 needs mir support patch" [Medium,In progress] https://launchpad.net/bugs/1432741
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [sync] (yakkety-proposed) [3.5.2-6]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.174]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-7ubuntu1]
-queuebot:#ubuntu-release- New binary: owncloud-client [arm64] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xen [arm64] (yakkety-proposed/main) [4.7.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: xen [i386] (yakkety-proposed/main) [4.7.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<LocutusOfBorg> Mirv, for sure I'm not authoritative, but I sponsored the same work for libsdl2 a few times for the same person, without troubles
-queuebot:#ubuntu-release- New binary: xen [amd64] (yakkety-proposed/main) [4.7.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: xen [armhf] (yakkety-proposed/main) [4.7.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: owncloud-client [armhf] (yakkety-proposed/universe) [2.2.2+dfsg-1] (no packageset)
<Mirv> LocutusOfBorg: yeah, I just raised it here since the FFe has been waiting since Monday so if it's wanted in the earlier the better
<Mirv> LocutusOfBorg: brandon's work is pretty solid, yes
 * LocutusOfBorg is doing some dak command on coccia, to see how libsdl1.2 is deprecated
<LocutusOfBorg> lots of stuff
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gtkhash (yakkety-proposed/universe) [0.7.0-3 => 0.7.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (yakkety-proposed) [1:6.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gtkhash [source] (yakkety-proposed) [0.7.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nautilus-python (yakkety-proposed/universe) [1.1-4 => 1.1-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nautilus-python [source] (yakkety-proposed) [1.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-os-client-config [source] (yakkety-proposed) [1.21.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-swiftclient [source] (yakkety-proposed) [1:3.1.0-0ubuntu1]
<Laney> coreycb: Oops, I typed the wrong reason for rejecting python-swiftclient. I meant to say that I'll sync it instead.
-queuebot:#ubuntu-release- Unapproved: python-swiftclient (yakkety-proposed/main) [1:3.0.0-3 => 1:3.1.0-1] (openstack, ubuntu-server) (sync)
<Laney> oho, you already did
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-swiftclient [sync] (yakkety-proposed) [1:3.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (yakkety-proposed) [1:9.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (yakkety-proposed) [2:9.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-swiftclient [sync] (yakkety-proposed) [1:3.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.0.0~rc2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (yakkety-proposed) [2.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: address-book-app (yakkety-proposed/universe) [0.2+16.10.20160920-0ubuntu1 => 0.2+16.10.20160929-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings-components (yakkety-proposed/main) [0.9+16.10.20160909-0ubuntu1 => 0.9+16.10.20160927-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted address-book-app [sync] (yakkety-proposed) [0.2+16.10.20160929-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings-components [sync] (yakkety-proposed) [0.9+16.10.20160927-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [amd64] (yakkety-proposed) [4.7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [armhf] (yakkety-proposed) [4.7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [arm64] (yakkety-proposed) [4.7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [i386] (yakkety-proposed) [4.7.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted blender [sync] (yakkety-proposed) [2.77.a+dfsg0-9]
-queuebot:#ubuntu-release- Unapproved: accepted libqalculate [source] (yakkety-proposed) [0.9.7-9.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: totem-pl-parser (yakkety-proposed/main) [3.10.6-4ubuntu2 => 3.10.7-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted linux-wlan-ng [sync] (yakkety-proposed) [0.2.9+dfsg-6]
-queuebot:#ubuntu-release- Unapproved: accepted totem-pl-parser [source] (yakkety-proposed) [3.10.7-1ubuntu1]
-queuebot:#ubuntu-release- New sync: python-adal (yakkety-proposed/primary) [0.4.1-2]
-queuebot:#ubuntu-release- New sync: python-applicationinsights (yakkety-proposed/primary) [0.10.0-2]
-queuebot:#ubuntu-release- New sync: python-msrest (yakkety-proposed/primary) [0.4.4-1]
-queuebot:#ubuntu-release- New sync: ruby-timeliness (yakkety-proposed/primary) [0.3.8-1]
-queuebot:#ubuntu-release- New sync: vagrant-azure (yakkety-proposed/primary) [2.0.0~pre1-2]
-queuebot:#ubuntu-release- New sync: ruby-haikunator (yakkety-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- New sync: ruby-ms-rest (yakkety-proposed/primary) [0.5.0-1]
<pitti> smb: yes; also, the beta freeze is completely independent of approving FFEs
<smb> pitti, thinks for letting it in. I was just trying to avoid more work for the builders and stuff while we already cause so much work with the one-kernel-a-day project ;)
<smb> thanks I mean
<pitti> smb: I actually didn't let it in, but yw :) (I'm on systemd.conf today to Sat, not much time for work)
<smb> oh well then thanks to whomever :)
<Laney> pitti: good timing with the celebrity bug :-)
<pitti> heh
<pitti> I thought most people considered systemd in and by itself as a local DoS already :-P
<smb> Sure! Been there, got the t-shirt (literally) :)
-queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0~rc2-0ubuntu1 => 2:10.0.0~rc2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.0~rc2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0~rc2-0ubuntu1 => 2:9.0.0~rc3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.0.0~rc3-0ubuntu1]
-queuebot:#ubuntu-release- New sync: python-azure (yakkety-proposed/primary) [2.0.0~rc6+dfsg-2]
-queuebot:#ubuntu-release- New sync: python-azure-storage (yakkety-proposed/primary) [0.33.0-1]
-queuebot:#ubuntu-release- New sync: python-msrestazure (yakkety-proposed/primary) [0.4.3-1]
-queuebot:#ubuntu-release- New sync: ruby-ms-rest-azure (yakkety-proposed/primary) [0.5.0-1]
-queuebot:#ubuntu-release- New sync: ruby-azure-sdk (yakkety-proposed/primary) [0.6.0-1]
-queuebot:#ubuntu-release- Unapproved: pyzmq (yakkety-proposed/universe) [15.2.0-1fakesync1 => 15.2.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pyzmq [source] (yakkety-proposed) [15.2.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (yakkety-proposed/universe) [3.20.3-2ubuntu2 => 3.22.0-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: ubuntu-app-launch (yakkety-proposed/main) [0.9+16.10.20160913.1-0ubuntu1 => 0.9+16.10.20160928-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: hw-detect (yakkety-proposed/main) [1.117ubuntu2 => 1.117ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: simple-scan (yakkety-proposed/main) [3.22.0.1-0ubuntu1 => 3.22.0.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: hw-detect (xenial-proposed/main) [1.117ubuntu2 => 1.117ubuntu2.1] (core)
<lamont> cyphermox: around ?
<cyphermox> lamont: yep
<cyphermox> what's up?
<lamont> 1621615, 1621507 <-- I figure we both need to agree on those, I'm +1 on verfied=true.  1628306 I think is all yours, yes?
<lamont> in my fantasy world, I'd like to see those hit -updates today
<cyphermox> cloud-init hasn't been in proposed for 7 days..
<lamont> ah, is that the other criteria?
<cyphermox> seems the same applies to the other SRUs
<cyphermox> usually, yes. I suppose you may be able to convince SRU team members otherwise
<lamont> almost certainly, given the uploads were friday/sat and maybe a touch on monday (8306)
<lamont> apw: who do I need to convince? :D
-queuebot:#ubuntu-release- Unapproved: empathy (yakkety-proposed/universe) [3.12.12-2ubuntu1 => 3.12.12-3ubuntu1] (ubuntugnome)
<lamont> cyphermox: otoh, I'm inclined to work on my maas bug that's at least partially to blame for yakkety issues, before I go on from there
<cyphermox> well, SRUs aren't my call given that I'm not on the SRU team. I will however verify ...306 now so it's fine to migrate when it's time
<cyphermox> is that maas bug something I should be looking at?
-queuebot:#ubuntu-release- Unapproved: gnome-keyring (yakkety-proposed/main) [3.20.0-2ubuntu2 => 3.20.0-2ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted owncloud-client [amd64] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [armhf] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [powerpc] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [s390x] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [arm64] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [ppc64el] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted owncloud-client [i386] (yakkety-proposed) [2.2.2+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: pciutils (yakkety-proposed/main) [1:3.3.1-1.1ubuntu3 => 1:3.3.1-1.1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (yakkety-proposed/main) [3.21.91-0ubuntu1 => 3.22.0-1ubuntu1] (ubuntu-desktop)
<lamont> cyphermox: the maas bug is all us, related to queries coming from IPs that we should accept, but don't, because we don't think they belong to the client.  At least I htink that's what's going on as I dig into it
-queuebot:#ubuntu-release- Unapproved: gitg (yakkety-proposed/universe) [3.20.1-1 => 3.20.3-0ubuntu1] (no packageset)
<cyphermox> ok
-queuebot:#ubuntu-release- Unapproved: accepted gitg [source] (yakkety-proposed) [3.20.3-0ubuntu1]
<dobey> hi, can someone poke ubuntu-app-launch through unapproved queue please? :)
<lamont> cyphermox: so yeah, I guess the big question is, are you +1 on all the 1621{507,615} packages being marked as verified too?
<cyphermox> yep
<lamont> cool.  I'll finish myh verification runs today, and mark them
<lamont> apw or someone: please kick cloud-initramfs-tools 0.27ubuntu1.1 and 0.29ubuntu1.1 into -proposed (x and y)
-queuebot:#ubuntu-release- Unapproved: python-gabbi (yakkety-proposed/universe) [1.12.0-2 => 1.24.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-gabbi [sync] (yakkety-proposed) [1.24.0-1]
-queuebot:#ubuntu-release- Unapproved: mediaplayer-app (yakkety-proposed/universe) [0.20.5+16.10.20160922-0ubuntu1 => 0.20.5+16.10.20160928-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mediaplayer-app [sync] (yakkety-proposed) [0.20.5+16.10.20160928-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-pbr (yakkety-proposed/main) [1.10.0-0ubuntu1 => 1.10.0-0ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu2 => 0.6.5.8-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tzdata (yakkety-proposed/main) [2016f-1 => 2016g-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (yakkety-proposed) [2016g-1]
<rcj> slangasek, Could you approve my upload of gce-utils for xenial-proposed partner?
-queuebot:#ubuntu-release- Unapproved: python-pylxd (yakkety-proposed/main) [2.1.0-0ubuntu1 => 2.1.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tzdata (precise-proposed/main) [2016f-0ubuntu0.12.04 => 2016g-0ubuntu0.12.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2016f-0ubuntu0.16.04 => 2016g-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2016f-0ubuntu0.14.04 => 2016g-0ubuntu0.14.04] (core)
-queuebot:#ubuntu-release- New source: squashfuse (xenial-proposed/primary) [0.1.100-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: smbldap-tools (yakkety-proposed/universe) [0.9.9-1ubuntu2 => 0.9.9-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted smbldap-tools [source] (yakkety-proposed) [0.9.9-1ubuntu3]
<coreycb> hello, can an archive admin please accept python-os-api-ref from the yakkety new queue?  this is a required build-depend for openstack packages.
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2016g-0ubuntu0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2016g-0ubuntu0.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (precise-proposed) [2016g-0ubuntu0.12.04]
<dobey> hmm
-queuebot:#ubuntu-release- Unapproved: alsa-tools (yakkety-proposed/universe) [1.1.0-1 => 1.1.0-2] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: amide (yakkety-proposed/universe) [1.0.5-6build2 => 1.0.5-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted amide [sync] (yakkety-proposed) [1.0.5-7]
-queuebot:#ubuntu-release- Unapproved: audiolink (yakkety-proposed/universe) [0.05-1.2 => 0.05-2] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: python-k8sclient (yakkety-proposed/primary) [0.3.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted audiolink [sync] (yakkety-proposed) [0.05-2]
-queuebot:#ubuntu-release- Unapproved: berkeley-express (yakkety-proposed/universe) [1.5.1-2build2 => 1.5.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted berkeley-express [sync] (yakkety-proposed) [1.5.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (yakkety-proposed) [3.22.0-1ubuntu1]
<slangasek> coreycb: python-os-api-ref accepted.  will this also be a runtime dep?  (will it need an MIR?)
<slangasek> rcj: looking
<rcj> slangasek, thank you
-queuebot:#ubuntu-release- New: accepted python-os-api-ref [sync] (yakkety-proposed) [0.3.0+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-app-launch [sync] (yakkety-proposed) [0.9+16.10.20160928-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (yakkety-proposed) [1.117ubuntu3]
<coreycb> slangasek, thanks. I think it's just a build-depend so shouldn't need an MIR.
<coreycb> ddellav, ^
<ddellav> coreycb ack
<slangasek> rcj: why is this gce-utils_1.3.3-0ubuntu5~16.04.1 instead of gce-utils_1.3.3-0ubuntu6~16.04.0?
-queuebot:#ubuntu-release- New binary: python-os-api-ref [amd64] (yakkety-proposed/universe) [0.3.0+dfsg1-1] (no packageset)
<rcj> slangasek, it shouldn't be, I'll correct it.
-queuebot:#ubuntu-release- Unapproved: rejected gce-utils [source] (xenial-proposed) [1.3.3-0ubuntu5~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gce-utils (xenial-proposed/partner) [1.3.3-0ubuntu5~16.04.0 => 1.3.3-0ubuntu6~16.04.0] (no packageset)
<rcj> slangasek, I have fixed that and re-uploaded.  Sorry.
<slangasek> rcj: no prob
<santa_> good evening
<santa_> I have some questions about the freezes, release management and such in ubuntu (I'm still not familiar with ubuntu's release management)
<santa_> so I would like to ask about the status of our kubuntu's packaging
<santa_> we have for instance kde frameworks 5.26 (composed by many packages) stuck in proposed
<slangasek> rcj: and accepted
<rcj> slangasek, thank you
<slangasek> santa_: what do you mean by "stuck in proposed"?
-queuebot:#ubuntu-release- Unapproved: accepted gce-utils [source] (xenial-proposed) [1.3.3-0ubuntu6~16.04.0]
<santa_> slangasek: meaning they are in proposed but not in the main archive if I'm not mistaken
<slangasek> santa_: yes, but what do you mean by "stuck"
<slangasek> packages migrate from -proposed when they meet all the consistency requirements
<slangasek> there was a beta milestone freeze holding packages out of the release, but that is now cleared
<santa_> slangasek: so if we get them "blessed" by britney they will migrate
<santa_> right?
<santa_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<slangasek> when the package has passed its autopkgtests, and it can be migrated to the release without regressing archive installability
<santa_> â I'm asking because I see here a problem which we may need to address
<santa_> ok, so it's still feasible to get fw 5.26 and plasma 5.7.5 in yakety
<santa_> what about apps 16.04.3? would be feasible, at this point, to get them in yakkety?
<slangasek> what problem are you referring to? that's a very long page
<slangasek> I believe apps should also be feasible
<acheronuk> apps = 203 package upload
<slangasek> there is unfortunately an autopkgtest backlog right now on armhf (http://autopkgtest.ubuntu.com/running) so it's not guaranteed
<slangasek> but fortunately the apps don't trigger quite so many autopkgtests beyond their own
<santa_> slangasek: e-c-m 5.26 (part of kde frameworks and already in -proposed) is triggering some build failures on some apps
<santa_> so we could patch 5.26 with a very very ugly workaround to get things migrated
<slangasek> santa_: no abbreviations, please, I have no idea what 'e-c-m' is
<santa_> slangasek: sorry, extra-cmake-modules
<slangasek> extra-cmake-modules itself is failing its own autopkgtest
<santa_> so it's either patching frameworks 5.26, or uploading apps 16.04.3
<acheronuk> plus there is a more general issue of failing tests with kde frameworks and plasma. you addressed that with yofl last time round as shown in this paste: http://paste.ubuntu.com/23250241/
<slangasek> I see that, at least
<slangasek> acheronuk: last time, it was "we're in transition, please override all of these failing tests because they're meaningless"
<acheronuk> or maybe with infinity
<slangasek> that's not the answer for release
<slangasek> santa_: I think it's clear that you should be uploading the apps, not patching the frameworks
<tsimonq2> yes please!!! /me is happy with that
<acheronuk> if we can find an uploader
<tsimonq2> slangasek: when apps migrate to release would the respective proposed migration pages be updated?
<tsimonq2> I assume yes?
<slangasek> tsimonq2: which pages are you referring to?
<acheronuk> uploader found :)
<tsimonq2> slangasek: Proposed Migration excuses page, the pretty one
<santa_> slangasek: ok, we will work on fixes apps 16.04.3, so they won't fail against latest extra-cmake-modules and work with the sponsor. thank you for your time, advice and patience
<slangasek> tsimonq2: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html tracks packages in -proposed that have yet to migrate; if they migrate, that page is updated
<slangasek> santa_: cheers
<tsimonq2> slangasek: nvm, stupid/obvious question
<tsimonq2> and we have an uploader too ;)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (xenial-proposed) [3.20.1+git20160923.2.7374bdc-0ubuntu1~xenial1]
-queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [source] (xenial-proposed) [8.0.0-0ubuntu0.16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (xenial-proposed) [1.8.7-1ubuntu5.3]
<bdmurray> sil2100: re livecd-rootfs SRU are the changes in Yakkety?
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (xenial-proposed) [1.117ubuntu2.1]
<bdmurray> kirkland: your pollinate SRU makes reference to a private bug which we don't really allow.
<bdmurray> nacc: ^^
<nacc> bdmurray: ack, what's the best way to go about that? can you reject and i can re-upload w/o the bug references?
<nacc> bdmurray: very sorry for that -- the header bug is the public version, i should have scrubbed the changelog more actively
<bdmurray> nacc: No problem, yes I can reject them.
<nacc> bdmurray: ok, and for rejected SRUs, since they were not publisehd, i can reupload with the same version and a corrected changelog? or should i bump the suffix version for consistency? Also, it does appare the yakkety changelog refers to an internal bug
<bdmurray> nacc: Yes, reupload with same version.  I think the private bug reference is less important for the development release.
<nacc> bdmurray: ack, will do that asap, thanks!
-queuebot:#ubuntu-release- Unapproved: rejected pollinate [source] (xenial-proposed) [4.23-0ubuntu1~16.04]
-queuebot:#ubuntu-release- Unapproved: rejected pollinate [source] (precise-proposed) [4.23-0ubuntu1~12.04]
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (yakkety-proposed/universe) [3.22.0-1ubuntu1 => 3.22.0-1ubuntu2] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: rejected pollinate [source] (trusty-proposed) [4.23-0ubuntu1~14.04]
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu1 => 2.3-0ubuntu2] (edubuntu, ubuntu-server)
<sil2100> bdmurray: yes, as per the SRU bug, there is one change that's not in yakkety but the reason for that is that it wouldn't work there
<sil2100> As we don't support arm64 clicks for anything else than xenial
<stgraber> ^ trivial fix for cases where LXD isn't running (as discovered by lamont)
<lamont> \o/
 * lamont the explorer
-queuebot:#ubuntu-release- Unapproved: pollinate (precise-proposed/main) [4.21-0ubuntu1~12.04 => 4.23-0ubuntu1~12.04] (no packageset)
<nacc> bdmurray: should be fixed now, thanks!
<stgraber> lamont: one of those rare people who tests stuff with -proposed enabled :)
-queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.21-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04] (no packageset)
<stgraber> I'm sure we'd have had a bunch more people run into problems pretty quick had that hit the release pocket :)
<lamont> stgraber: only because I need like 5 packages from -proposed to actually verify said fixes
<lamont> in an initramfs.
<lamont> FML
<bdmurray> sil2100: Could you update the bug tasks to reflect that?  There is no xenial one and the default task in In Progress.
<stgraber> :)
-queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.21-0ubuntu1~16.04 => 4.23-0ubuntu1~16.04] (ubuntu-server)
<sil2100> Oh
<sil2100> bdmurray: right, sorry about that, let me do that quick
<bdmurray> sil2100: no problem
<sil2100> bdmurray: ok, nominated to xenial, set the main one to Fix Released
<sil2100> Thanks for looking into this!
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-8-g0439d8a-0ubuntu1 => 0.7.8-11-g02f6c4b-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: smbldap-tools (trusty-proposed/universe) [0.9.9-1ubuntu1.14.04.1 => 0.9.9-1ubuntu1.14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: smbldap-tools (xenial-proposed/universe) [0.9.9-1ubuntu1.16.04.1 => 0.9.9-1ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-utils (xenial-release/partner) [1.3.3-0ubuntu6~16.04.0 => 1.3.3-0ubuntu6~16.04.0] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gce-utils [sync] (xenial-release) [1.3.3-0ubuntu6~16.04.0]
-queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr415-0ubuntu1 => 0.1.0~bzr425-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.5]
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (xenial-proposed) [4.23-0ubuntu1~16.04]
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.23-0ubuntu1~14.04]
<bdmurray> nacc: Do you know anything about the existing SRU for pollinate in Precise?
<nacc> bdmurray: no, it seems like it just got missed somehow?
<nacc> bdmurray: i've pinged kirkland on it
-queuebot:#ubuntu-release- Unapproved: nagios-nrpe (yakkety-proposed/main) [2.15-1ubuntu1 => 2.15-1ubuntu2] (ubuntu-server)
<nacc> bdmurray: ah he did respond in the bug, but i didn't get notified!
<nacc> bdmurray: LP: #1593625
<ubot5> Launchpad bug 1593625 in cloud-images "[SRU] add pollinate to precise, update all" [Undecided,New] https://launchpad.net/bugs/1593625
<nacc> bdmurray: it was tested (by kirkland) so seems like it should have gone through; i'm not privy to why it didn't?
<bdmurray> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<bdmurray> it doesn't seem to have a reference to the bug
<nacc> you're right, it doesn't
 * nacc blames kirkland's publishing method :)
<bdmurray> nacc: if there's no bug reference then it doesn't turn green so its dead to the SRU team (or me at least!)
<nacc> interesting -- well, my upload supersedes (and includes what's in -proposed now), but not sure how best to proceed
<bdmurray> nacc: Well, nobody was clamoring for it so we might as well let yours into -proposed.  Agreed?
<nacc> bdmurray: agreed
-queuebot:#ubuntu-release- Unapproved: nagios3 (yakkety-proposed/main) [3.5.1.dfsg-2.1ubuntu2 => 3.5.1.dfsg-2.1ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (precise-proposed) [4.23-0ubuntu1~12.04]
-queuebot:#ubuntu-release- Unapproved: accepted nagios-nrpe [source] (yakkety-proposed) [2.15-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [source] (yakkety-proposed) [3.5.1.dfsg-2.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20160705.1-0ubuntu1 => 15.04.0+16.10.20160705.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.4-0ubuntu4 => 2.0.4-0ubuntu5] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.4-0ubuntu5]
<stgraber> doko_: you broke lxc, please fix: https://launchpadlibrarian.net/287321815/buildlog_ubuntu-yakkety-amd64.lxc_2.0.4-0ubuntu5_BUILDING.txt.gz
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-11-g02f6c4b-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (yakkety-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted simple-scan [source] (yakkety-proposed) [3.22.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted empathy [source] (yakkety-proposed) [3.12.12-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keyring [source] (yakkety-proposed) [3.20.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (yakkety-proposed) [2.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-systemd (yakkety-proposed/main) [231-2build1 => 232-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (yakkety-proposed/main) [16.10.2 => 16.10.3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xdg-utils (yakkety-proposed/main) [1.1.1-1ubuntu1 => 1.1.1-1ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xdg-utils (xenial-proposed/main) [1.1.1-1ubuntu1 => 1.1.1-1ubuntu1.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-systemd [sync] (yakkety-proposed) [232-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (yakkety-proposed) [16.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (yakkety-proposed) [3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pciutils [source] (yakkety-proposed) [1:3.3.1-1.1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted alsa-tools [sync] (yakkety-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [source] (yakkety-proposed) [1.10.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: e2fsprogs (yakkety-proposed/main) [1.43.1-1 => 1.43.3-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-8 => 231-9] (core)
-queuebot:#ubuntu-release- Unapproved: accepted e2fsprogs [sync] (yakkety-proposed) [1.43.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-utils [source] (yakkety-proposed) [1.1.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9]
<bdmurray> infinity: Do you have any plans for bug 1571456?
<ubot5> bug 1571456 in glibc (Ubuntu Xenial) "id crashed with SIGSEGV in sock_eq()" [Medium,Triaged] https://launchpad.net/bugs/1571456
<doko_> stgraber: I'll have a look. looks like lxc wasn't built with pie before
<stgraber> doko_: pretty sure it was but hardening-wrapper was doing some magic to do the right thing for the library vs binaries
<stgraber> stgraber@dakara:~$ hardening-check /usr/bin/lxc-start
<stgraber> /usr/bin/lxc-start:
<stgraber>  Position Independent Executable: yes
-queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.2-0ubuntu5 => 10.2.3-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<doko_> ugh, so hardening-wrapper was hiding the real arguments? excellent :-/
-queuebot:#ubuntu-release- Unapproved: fcitx (xenial-proposed/main) [1:4.2.9.1-1ubuntu1 => 1:4.2.9.1-1ubuntu1.16.04.1] (input-methods, kubuntu, ubuntu-desktop)
<tsimonq2> https://www.kde.org/info/security/advisory-20160930-1.txt
<tsimonq2> santa_, acheronuk, clivejo ^^^
<tsimonq2> that was just pasted in the Debian KDE channel
<tsimonq2> !info kde-cli-tools
<ubot5> kde-cli-tools (source: kde-cli-tools): tools to use KDE services from the command line. In component universe, is extra. Version 4:5.5.5-0ubuntu1 (xenial), package size 138 kB, installed size 680 kB
<tsimonq2> !info kde-cli-tools yakkety
<ubot5> kde-cli-tools (source: kde-cli-tools): tools to use KDE services from the command line. In component universe, is extra. Version 4:5.7.2-0ubuntu1 (yakkety), package size 130 kB, installed size 657 kB
<tsimonq2> aaand we're affected...
-queuebot:#ubuntu-release- Unapproved: autopkgtest (yakkety-proposed/main) [4.0.5 => 4.0.5ubuntu1] (core)
<tsimonq2> !info kde-cli-tools trusty
<ubot5> Package kde-cli-tools does not exist in trusty
<tsimonq2> ok, I'm getting a patch ready for Xenial then
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (yakkety-proposed) [4.0.5ubuntu1]
<doko_> stgraber: why isn't lxc using libtool?
<tsimonq2> ok, release team, here's a diff fixing that: http://paste.ubuntu.com/23253427/
 * tsimonq2 hunts for some documentation on this
#ubuntu-release 2016-09-30
-queuebot:#ubuntu-release- Unapproved: evolution (yakkety-proposed/universe) [3.21.91-1ubuntu1 => 3.22.0-2ubuntu1] (ubuntugnome, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: yelp-xsl (yakkety-proposed/main) [3.20.1-1 => 3.20.1-2] (ubuntu-desktop) (sync)
<powersj> is there a programmatic way to know when something gets added to proposed?
<tsimonq2> that would be awesome ^^^
<slangasek> powersj: I don't believe we have any sort of push notifications from launchpad; you probably just want to poll via apt
<slangasek> powersj: (you could poll launchpad instead, but "published" in launchpad != "published" on the archive, and the latter is more likely to be what you care about)
<powersj> slangasek, yeah what is in the archive... what I was thinking was just using rmadison
<slangasek> rmadison also works, though IIRC it pulls its source data from upstream of the public archive so it can sometimes give you answers before they're true also
<powersj> slangasek, ok thx
<nacc> powersj: ah sorry, i meant to respond but have been  backlogged
<nacc> powersj: i was going to suggest maybe doing something off one of the -changes lists? procmail filter to some sort of trigger?
<powersj> nacc, no worries :) at the qa sprint we are trying to get some notifications going
<nacc> powersj: in theory, eventually, we could do something via git hooks in the importer, i think, too?
<slangasek> powersj: what kind of notifications do you have in mind?  If you're trying to hook up per-package tests, perhaps it would make sense to integrate with proposed-migration + autopkgtest?
-queuebot:#ubuntu-release- Unapproved: psicode (yakkety-proposed/universe) [3.4.0-6 => 3.4.0-6build1] (no packageset)
<slangasek> (speculating because "qa sprint")
<powersj> slangasek, yeah - desire to have other teams get notified that a new package is uploaded to proposed like cloud-init/curtin/etc.
-queuebot:#ubuntu-release- Unapproved: accepted psicode [source] (yakkety-proposed) [3.4.0-6build1]
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu2 => 2.3-0ubuntu3] (edubuntu, ubuntu-server)
<powersj> we have a message server a few teams are using to use to both send notifications from their teams and teams can listen for specific messages to launch or start other testing
<slangasek> hmmm
<slangasek> would be interesting to know how we could align with proposed-migration to avoid duplicating services
<powersj> agreed
<slangasek> what kind of "message server" is this? autopkgtest is doing AMQP already
<powersj> that would do it, we are using pika to communicate, so amqp
<slangasek> powersj: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure might be useful
<slangasek> we're already engaged with the QA team about integrating with ubuntu-system-tests, to trigger tests of images on devices (i.e. phones, currently) when packages change
<powersj> slangasek, I'll read through this tonight, we are revisiting the topic tomorrow and I will mention this
<stgraber> slangasek: would be great if you could let that lxd upload through, reasonably trivial fix
<slangasek> stgraber: looking
<slangasek> stgraber: accepted
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu3]
<stgraber> thanks
-queuebot:#ubuntu-release- Unapproved: libint (yakkety-proposed/universe) [1.1.5-2 => 1.1.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libint [source] (yakkety-proposed) [1.1.5-2build1]
-queuebot:#ubuntu-release- Unapproved: starpu-contrib (yakkety-proposed/multiverse) [1.1.5-0ubuntu6 => 1.2.0~rc2+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted starpu-contrib [sync] (yakkety-proposed) [1.2.0~rc2+dfsg-2]
<wxl> btw sakrecoer +1 on the flavor-specific humour there ;)
-queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.13+nmu2 => 0.13+nmu2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (yakkety-proposed/main) [1.2.4-0ubuntu1 => 1.2.4-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (yakkety-proposed/main) [3.20.2-1ubuntu4 => 3.20.2-1ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gconf (yakkety-proposed/main) [3.2.6-3ubuntu6 => 3.2.6-3ubuntu7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gconf (yakkety-proposed/main) [3.2.6-3ubuntu6 => 3.2.6-3ubuntu7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-terminal-app (yakkety-proposed/universe) [0.7.216 => 0.7.218] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-terminal-app [source] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [amd64] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [ppc64el] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [i386] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [arm64] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [armhf] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [s390x] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntu-terminal-app [powerpc] (yakkety-proposed/universe) [0.7.218] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shotwell (yakkety-proposed/main) [0.22.0+git20160108.r1.f2fb1f7-0ubuntu1 => 0.22.0+git20160108.r1.f2fb1f7-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: d-conf (yakkety-proposed/main) [0.26.0-1 => 0.26.0-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: remmina (yakkety-proposed/main) [1.1.2-3ubuntu1 => 1.1.2-3ubuntu2] (ubuntu-desktop)
<infinity> bdmurray: Yes.
-queuebot:#ubuntu-release- Unapproved: asterisk (yakkety-proposed/universe) [1:13.1.0~dfsg-1.1ubuntu5 => 1:13.10.0~dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted asterisk [source] (yakkety-proposed) [1:13.10.0~dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lightdm (yakkety-proposed/main) [1.19.4-0ubuntu1 => 1.19.5-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gimagereader (yakkety-proposed/universe) [3.1.91-1 => 3.1.91-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gimagereader [sync] (yakkety-proposed) [3.1.91-2]
-queuebot:#ubuntu-release- New binary: monkeysign [amd64] (yakkety-proposed/universe) [2.1.2] (no packageset)
<sakrecoer> hello everyone :) any chance we could get a little help with this before RC next week? https://bugs.launchpad.net/ubuntustudio/+bug/1624690
<ubot5> Ubuntu bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New]
<sakrecoer> we need it to be approved and uploaded. let me know if there is anything else i can provide or do to make this easier for you.
-queuebot:#ubuntu-release- Unapproved: dpdk (yakkety-proposed/main) [16.07-0ubuntu3 => 16.07-0ubuntu4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.2-0ubuntu0.16.04.2 => 10.2.3-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: clipf (yakkety-proposed/universe) [0.4-1 => 0.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clipf [sync] (yakkety-proposed) [0.4-2]
-queuebot:#ubuntu-release- Unapproved: signon (yakkety-proposed/main) [8.58+16.04.20151106-0ubuntu1 => 8.59+16.10.20160916-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lightdm [source] (yakkety-proposed) [1.19.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bamf (yakkety-proposed/main) [0.5.3~bzr0+16.10.20160726.1-0ubuntu1 => 0.5.3+16.10.20160929-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected unity-control-center [source] (yakkety-proposed) [15.04.0+16.10.20160705.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (yakkety-proposed) [3.20.2-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (yakkety-proposed) [0.22.0+git20160108.r1.f2fb1f7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (yakkety-proposed) [1.2.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (yakkety-proposed) [10.2.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (yakkety-proposed) [0.1.0~bzr425-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (yakkety-proposed) [3.22.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted yelp-xsl [sync] (yakkety-proposed) [3.20.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted xml-core [source] (yakkety-proposed) [0.13+nmu2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.433 => 2.434] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected gconf [source] (yakkety-proposed) [3.2.6-3ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted gconf [source] (yakkety-proposed) [3.2.6-3ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted d-conf [sync] (yakkety-proposed) [0.26.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted remmina [source] (yakkety-proposed) [1.1.2-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-screensaver (yakkety-proposed/main) [3.6.1-7ubuntu4 => 3.6.1-7ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (yakkety-proposed) [16.07-0ubuntu4]
-queuebot:#ubuntu-release- New sync: chrome-gnome-shell (yakkety-proposed/primary) [7.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (yakkety-proposed) [2.434]
-queuebot:#ubuntu-release- Unapproved: accepted bamf [sync] (yakkety-proposed) [0.5.3+16.10.20160929-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted signon [sync] (yakkety-proposed) [8.59+16.10.20160916-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-screensaver [source] (yakkety-proposed) [3.6.1-7ubuntu5]
<mardy> pitti: hi! could you please remove from yakkety the s390x packages for online-accounts-api?
<mardy> pitti: context is https://launchpadlibrarian.net/287399148/buildlog_ubuntu-yakkety-s390x.online-accounts-api_0.1+16.10.20160930-0ubuntu1_BUILDING.txt.gz
-queuebot:#ubuntu-release- Unapproved: dymo-cups-drivers (yakkety-proposed/universe) [1.4.0-5 => 1.4.0-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libowfat (yakkety-proposed/universe) [0.30-2 => 0.30-2ubuntu1] (no packageset)
<xnox> slangasek, ^ only libowfat-dietlibc-dev fails to build, on some arches with no reverse (build) dependencies. just dropping that binary package on some architectures is enough.
 * xnox doesn't understand the point of dietlibc in ubuntu whatsoever
-queuebot:#ubuntu-release- Unapproved: accepted dymo-cups-drivers [sync] (yakkety-proposed) [1.4.0-6]
-queuebot:#ubuntu-release- Unapproved: accepted libowfat [source] (yakkety-proposed) [0.30-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: epson-inkjet-printer-escpr (yakkety-proposed/universe) [1.6.5-1 => 1.6.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted epson-inkjet-printer-escpr [sync] (yakkety-proposed) [1.6.8-1]
<xnox> oh that went in straight away.
<Laney> if (uploader == xnox) accept();
<apw> if (uploader == xnox && random % 10 == 0) accept(); /* don't make it easy to understand */
<Laney> void accept() { reject(); /* muhahahaha */ }
<xnox> you two are so nice.
<xnox> apw, you will be in bluefin for the release week, right?
<apw> xnox, i am not sure yet ...
<tsimonq2> by the way sakrecoer, you can get diffs from every PPA
<tsimonq2> sakrecoer: http://pix.toile-libre.org/upload/original/1475233886.png
<tsimonq2> sakrecoer: that is where you can find your diff
<tsimonq2> sakrecoer: and the "no signer" part on upload isn't good :/
<LocutusOfBorg> if (uploader == xnox && uploader = "5") accept() /* always true */
<tsimonq2> sakrecoer: but it seems like it's a daily build... I would build this locally as 0.63, get all the changes in there that you need, then if you debuild -S (-sa as well if you need a tar to be uploaded with it), you can cd .. and debdiff PACKAGE_0.62_whatever_comes_after_this_I_forget.dsc PACKAGE_0.63_whatever_comes_after_this_I_forget.dsc
<tsimonq2> sakrecoer: I'm not sure they'll accept moving targets ;)
-queuebot:#ubuntu-release- Unapproved: meson (yakkety-proposed/universe) [0.33.0-1 => 0.34.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meson [sync] (yakkety-proposed) [0.34.0-1]
<tsimonq2> sakrecoer: also if you need any help and have a good base to work with, #ubuntu-devel is an awesome channel with awesome people in it ;)
-queuebot:#ubuntu-release- Unapproved: bzr (xenial-proposed/main) [2.7.0-2ubuntu2 => 2.7.0-2ubuntu3] (bzr, core)
-queuebot:#ubuntu-release- Unapproved: singular (yakkety-proposed/universe) [4.0.3-p1+ds-3ubuntu1 => 4.0.3-p1+ds-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted singular [sync] (yakkety-proposed) [4.0.3-p1+ds-4]
-queuebot:#ubuntu-release- Unapproved: libreoffice (yakkety-proposed/main) [1:5.2.1~rc2-0ubuntu1 => 1:5.2.2-0ubuntu1] (kubuntu, ubuntu-desktop)
<Laney> langpack flood-o-rama
<apw> Laney, i assume we can just accept those
<Laney> apw: hahaha
<Laney> imagine my face when I debdiffed it
<Laney> wait I thought you meant libreoffice
<Laney> same applies to both though
<apw> Laney, heh i was thinking of the langpacks indeed :)
-queuebot:#ubuntu-release- Unapproved: python-taskflow (yakkety-proposed/main) [1.30.0-1ubuntu1 => 2.3.0-1] (ubuntu-server) (sync)
<Laney> DoS attack in progress
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (yakkety-proposed/main) [1:5.2.1~rc2-0ubuntu1 => 1:5.2.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted python-pylxd [source] (xenial-proposed) [2.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu7 => 2.1.0-1ubuntu8] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (yakkety-proposed/main) [1.50.0-1ubuntu1 => 1.50.0-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libinput (yakkety-proposed/main) [1.4.0-1ubuntu2 => 1.4.3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: qemu (yakkety-proposed/main) [1:2.6.1+dfsg-0ubuntu4 => 1:2.6.1+dfsg-0ubuntu5] (ubuntu-server, virt)
<sakrecoer> thanks tsimonq2 :) i'm very uncomfortable with the building process. but hopefully the ones in the know in our small team are going to find some time to do what you suggest soon..
-queuebot:#ubuntu-release- Unapproved: binwalk (yakkety-proposed/universe) [2.1.1-14 => 2.1.1-15] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted binwalk [sync] (yakkety-proposed) [2.1.1-15]
<mvo> Laney: could you help with forcing snapd into yakkety from yakkety-proposed? the curretn snapd crashes in yakkety and the fix in yakkety-proposed is not promoted because of a single i386 autopkgtest failure that I can not reproduce in a normal autopkgtest VM and that looks very much like its specific to the test environment and not a real issue
<infinity> mvo: And by i386, you mean ppc64el?
<infinity> mvo: Looks like ppc64el has been consistently failing since 2.14 ... New tests or new bugs?
<ogra_> new yakkety i guess :)
<ogra_> (they dont fail in xenial)
<ogra_> (IIRC)
<jdstrand> fuse_support and cups_control look like segfaults in bash, upower a segfault in su
<jdstrand> bluez seems like it is cause there isn't a bluez snap for ppc64el
<jdstrand> login test has 'error: inappropriate ioctl for device'
<jdstrand> clearly the ppc64el errors need to be looked at, but the 4.8 kernel broke all strict mode snaps
<jdstrand> so right now, no one can effectively use snappy on 16.10
<mvo> infinity: many more tests
<mvo> infinity: we went from 3 to >80
<jdstrand> we need the newer snapd for the apparmor profile changes that allow snaps to work again with 4.8 kernels
<mvo> infinity: unfortunately the ppc64el test snaps we use do not fully work
<jdstrand> so, today, ppc64el are totally broken along with everyone else
<jdstrand> forcing this would unbreak !ppc64el (and likely allow ppc64el to work in some capacity-- I don't claim to know how well it works there)
<apw> mvo, does that snapd require the new kernel apparamor changes ?
<jdstrand> s/ppc64el are/ppc64el users are/
<jdstrand> apw: no
<jdstrand> apw: the new changes are for lxd to work well, not this snapd upload
<jdstrand> apw: more precisely, the kernel changes are for snapd to run well under lxd. but lxd also needs this snapd to migrate for snapd to work well in lxd
<apw> jdstrand, ack thanks
<jdstrand> but snapd doesn't need the kernel changes
<ginggs> mvo: hi, are you planning to upload synaptic with a fix for Debian #811857?
<ubot5> Debian bug 811857 in synaptic "synaptic: FTBFS with GCC 6: no matching function for call to" [Serious,Open] http://bugs.debian.org/811857
<mvo> ginggs: uh, I fixed this a long time ago and didn't upload yet, sorry for that, I can prepare an upload on the weekend
<ginggs> mvo: yeah, i saw it in git :) thanks!
<ogra_> synaptic ...
<ogra_> does it have snap support yet ?
<ogra_> :P
-queuebot:#ubuntu-release- Unapproved: loudmouth (yakkety-proposed/universe) [1.5.3-1 => 1.5.3-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: python-eventlet (yakkety-proposed/main) [0.19.0-2 => 0.19.0-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (yakkety-proposed/main) [2:10.0.7-3227872-4.1ubuntu1 => 2:10.0.7-3227872-5ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<smoser> hey.
<smoser> i'm in need of some help
<smoser> i'd like to get cloud-utils 0.29-0ubuntu4 into yakkety
<smoser> it seems to me to be hung on something unrelated.
<smoser> in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<apw> smoser, it is held for failing tests in juju-core with it riight ?
<smoser> i think so, yeah.
<smoser> but the delta seems not likely to me to have caused that.
<apw> i guess to override that we'd want to be convinced it was not related somehow
<smoser> as the only thing changed was mount-image-callback, and i'm pretty sure juju doesn't use that.
<smoser> apw, so issue is amd64 juju-core fail and ppc64el juju core fail, right?
-queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0~rc1-0ubuntu1 => 3.0.0~rc1-0ubuntu2] (openstack)
<apw> smoser, when tested with the new cloud-init yeah
<smoser> apw, cloud-utils, not cloud-inti (right?)
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [source] (yakkety-proposed) [1.50.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-eventlet [source] (yakkety-proposed) [0.19.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted loudmouth [sync] (yakkety-proposed) [1.5.3-2]
-queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.2.0-0ubuntu1 => 1:6.2.0-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (yakkety-proposed) [1:2.6.1+dfsg-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu8]
<apw> smoser, sorry yes
<smoser> apw, can i ask that system to re-run the juju-core-1 test again without cloud-utilsi ?
<smoser> man. i wish i could type.
<apw> smoser, yeah that is a good idea, as i agree it seems unlikley your test would be to blame. i'll try and trigger a juju-core-1 test
<smoser> apw, thank you. also i got mgz to say in #juju-dev that he thinks not related to cloud-utils here.
<apw> smoser, ok done that ...
<apw> smoser, well that sounds like a pretty definative argument
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.3 => 1:16.04.4] (core)
<nacc> asked in #ubuntu-devel, maybe someone here can give me a 'best practice': to trigger a rebuild of python-docutils (which should not ftbfs now that there is a new xml-core), do I just upload a new version -- or will the next test rebuild just automatically pick up the fix?
<jamespage> nacc, you can ask someone with upload privs to hit the rebuild button
 * jamespage looks
<nacc> jamespage: oh i do --
<nacc> me goes to look
<nacc> jamespage: thanks
<jamespage> nacc, yw
<apw> but i sond't see it failing to build ... did it only fail in the test-rebuild ?
<nacc> yeah only i the test-rebuild
<nacc> *in
<nacc> so that's what i was trying to understand, for other actual fix packages, the new upload as cleared it from the ftbfs page -- but this one is due to a breakage in a b-d
<nacc> i can upload a 0.12+dfsg-1build1
<apw> i don't think there is anythig to do then, the next test-rebuild should be fine right ?
<apw> you could poke doko, he may know where the retry button is, as it would be in the test-archive
<nacc> apw: yeah, it should
<nacc> doko_: --^ :) this is for python-docutils
<nacc> apw: thanks!
-queuebot:#ubuntu-release- Unapproved: python-taskflow (yakkety-proposed/main) [1.30.0-1ubuntu1 => 1.30.0-1ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-proposed/main) [1:0.196.21 => 1:0.196.22] (core)
-queuebot:#ubuntu-release- Unapproved: switchsh (yakkety-proposed/universe) [0~20070801-3.2 => 0~20070801-3.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted switchsh [sync] (yakkety-proposed) [0~20070801-3.3]
-queuebot:#ubuntu-release- Unapproved: grap (yakkety-proposed/universe) [1.44-1 => 1.44-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted grap [sync] (yakkety-proposed) [1.44-1.1]
-queuebot:#ubuntu-release- Unapproved: libmsn (yakkety-proposed/universe) [4.2.1+dfsg-1 => 4.2.1+dfsg-1.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libmsn [sync] (yakkety-proposed) [4.2.1+dfsg-1.1]
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20160705.1-0ubuntu1 => 15.04.0+16.10.20160705.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: update-manager (precise-proposed/main) [1:0.156.14.19 => 1:0.156.14.20] (core)
<slangasek> doko_: two weeks to release and gcc is still making the server ISOs oversized; when will that change land in yakkety?  is it part of what's currently in -proposed?
<tsimonq2> sakrecoer: don't be afraid to ask for help ;)
<nacc> slangasek: i uploaded a fix for the python-docutils ftbfs in the test-archive, based upon a patch from the debian bug. But Debian has fixed it differently (just now). Would it be better for us to just sync to that version of xml-core (the source of the ftbfs)?
<slangasek> nacc: without reviewing the diff I couldn't say if I thought that was better :)  we're in post-beta freeze; what's your assessment of the risk of taking the new xml-core?  is it bugfix-only?
<slangasek> and if you've already fixed python-docutils, do we know if other packages are affected by xml-core?
<nacc> slangasek: the smallish fix for xml-core is regression-free, it just fixes a debhelper regex that was buggy
<nacc> slangasek: which i've already uploaded and just need doko to poke the test-build rebuild
<nacc> of python-docutils
<slangasek> nacc: so, you should feel free to sync that
<nacc> slangasek: i think your point makes me thing we shouldn't sync now, though,a s the debian package bumps the version
<slangasek> oh?
<slangasek> why is bumping the version a problem here?
<nacc> well, i mean, it's not bugfix only afaict
<slangasek> ah
<nacc> i need to go review what has changed upstream
<slangasek> ok
<slangasek> then yes, sounds like that's making more work for yourself to review the upstream changes when we already have a fix that suffices for 16.10
<nacc> ack :)
<slangasek> if someone could make cmake debugging output on failure /less terrible/ than autoconf's, that would be wonderful
<doko_> slangasek: when the test rebuild finishes
<jbicha> docbook-xml and docbook-xsl (maybe more) also had test rebuild failures from the old xml-core
<doko_> at least for powerpc
<slangasek> doko_: do you have an estimate of when that will be?
<nacc> jbicha: yeah, those should work now too, i believe
<nacc> jbicha: same issue afaict
<slangasek> doko_: and I guess it needs to wait for the rebuild to finish because otherwise the new, debug-less version would be pulled into the test builds from the main archive.  So if the test rebuild isn't going to finish on time, is there a hard deadline at which you'll switch gcc anyway so that we can get the server images fixed
<slangasek> ?
<doko_> I'll have to upload unstripped versions to some ppa's and let the test rebuild archives depend on them. but not today, and I'm travelling the weekend
-queuebot:#ubuntu-release- Unapproved: srtp (yakkety-proposed/universe) [1.4.5~20130609~dfsg-1.1ubuntu1 => 1.4.5~20130609~dfsg-1.3ubuntu1] (kubuntu)
<doko_> slangasek: btw, did we find out why the server images want to have a gcc installed?
<nacc> doko_: build-essential is seeded on server-ship
<nacc> iirc
<slangasek> doko_: it's probably historical, but also not a decision that I think the server team wants to revisit between beta and release.  So what is the deadline by which we can plan to have gcc changed, no matter the status of the rebuild?  Can we plan on next Thursday, does that give you enough time for a ppa build of gcc?
<nacc> i guess that's more of a practical why not a strategic why :)
<doko_> Thu sounds fine
<slangasek> doko_: ok, thanks
<slangasek> powersj: ^^ so Thursday at the latest for gcc back down to size
-queuebot:#ubuntu-release- Unapproved: akonadi-calendar (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: akonadi (yakkety-proposed/universe) [4:15.12.3-0ubuntu7~2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ark (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3a-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: audiocd-kio (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: bomber (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: akonadi-search (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: artikulate (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: bovo (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: analitza (yakkety-proposed/universe) [4:15.12.3-0ubuntu2~2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: blinken (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: baloo-widgets5 (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cantor (yakkety-proposed/universe) [4:15.12.3-0ubuntu3 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: dolphin-plugins (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: dragon (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gpgmepp (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gwenview (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: cervisia (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: filelight (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: jovie (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: dolphin (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: granatier (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: juk (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kaccounts-integration (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kajongg (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kalgebra (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kamera (yakkety-proposed/universe) [4:15.12.3-1~2ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kapman (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kate (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kaccessible (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kalarmcal (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kanagram (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: katomic (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kaccounts-providers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kapptemplate (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kalzium (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kblackbox (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kblog (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kbreakout (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcachegrind (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcalcore (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcharselect (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcontacts (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-baseapps (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kblocks (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kbruch (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcalutils (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcron (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kbounce (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcolorchooser (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcalc (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde4libs (yakkety-proposed/universe) [4:4.14.16-0ubuntu4 => 4:4.14.22-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-dev-scripts (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdebugsettings (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdegraphics-mobipocket (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-dev-utils (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdegraphics-strigi-analyzer (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeedu-data (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: kdesdk-kioslaves (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: kf5-messagelib (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: kf5-kdepim-apps-libs (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: kleopatra (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kde-runtime (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdegraphics-thumbnailers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdenetwork-strigi-analyzers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdepim-addons (yakkety-proposed/universe) [16.04.3-1 => 16.04.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kdepim (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdesdk-strigi-analyzers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdewebdev (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdiamond (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kfourinline (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kget (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-spectacle (yakkety-proposed/universe) [15.12.3-0ubuntu3 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdenlive (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdepimlibs (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdf (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kgeography (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdenetwork-filesharing (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdesdk-thumbnailers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdepim-runtime (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kfloppy (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: ktp-call-ui (yakkety-proposed/primary) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-addons [source] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kgpg (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khelpcenter (yakkety-proposed/universe) [4:5.6.4-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kidentitymanagement (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kigo (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kimap (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kiriki (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjumpingcube (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: klettres (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: klines (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kgoldrunner (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kholidays (yakkety-proposed/universe) [15.12.3-0ubuntu2 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: killbots (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kiten (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: klickety (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmahjongg (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmbox (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmines (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmousetool (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmplot (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khangman (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kio-extras (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmag (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmime (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
<powersj> slangasek, thx
-queuebot:#ubuntu-release- Unapproved: kmouth (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kpat (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: krdc (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: libkf5gravatar (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kmix (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kppp (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: konquest (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: libkf5calendarsupport (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5kdgantt2 (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5libkdepim (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5mailcommon (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5pimcommon (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5ksieve (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5mailimporter (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: libkf5libkleo (yakkety-proposed/primary) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: minuet (yakkety-proposed/primary) [16.04.3-0ubuntu1]
<tsimonq2> infinity: so that right there is Kubuntu's doing ^^^
<acheronuk> tsimonq2: oi! don't say that as if you have no collective responsibility. :P
-queuebot:#ubuntu-release- Unapproved: kreversi (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kross-interpreters (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksaneplugin (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kshisen (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksnakeduel (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksquares (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksudoku (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kteatime (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktnef (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-accounts-kcm (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: krfb (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscd (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kspaceduel (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksystemlog (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktouch (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-auth-handler (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-contact-list (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-desktop-applets (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-kded-integration-module (yakkety-proposed/universe) [4:15.12.1-2ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-text-ui (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
<tsimonq2> well I do
-queuebot:#ubuntu-release- Unapproved: kruler (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kstars (yakkety-proposed/universe) [4:15.12.3-0ubuntu3 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-approver (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-contact-runner (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-send-file (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kturtle (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kuser (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwordquiz (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkcompactdisc (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkdegames (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
<tsimonq2> and I fully admit to it
<tsimonq2> lol
-queuebot:#ubuntu-release- Unapproved: ksirk (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-common-internals (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktuberling (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwalletmanager (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkdeedu (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkf5grantleetheme (yakkety-proposed/universe) [16.04.3-1 => 16.04.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libkf5kdcraw (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktimer (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kubrick (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkeduvocdocument (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktp-filetransfer-handler (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkf5incidenceeditor (yakkety-proposed/universe) [16.04.2-2 => 16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libkcddb (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
 * acheronuk hides
<tsimonq2> be back in a few hours o/
-queuebot:#ubuntu-release- Unapproved: accepted libkf5grantleetheme [source] (yakkety-proposed) [16.04.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libkf5kipi (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkf5sane (yakkety-proposed/universe) [15.12.1-0ubuntu1 => 16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lokalize (yakkety-proposed/universe) [4:15.12.3-0ubuntu3 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: marble (yakkety-proposed/universe) [4:15.12.3-0ubuntu4 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: okteta (yakkety-proposed/universe) [4:15.12.3-0ubuntu4 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: palapeli (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: picmi (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: print-manager (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: signon-kwallet-extension (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libkf5incidenceeditor [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libkomparediff2 (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: mplayerthumbs (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: parley (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rocs (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: svgpart (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: syndication (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: zeroconf-ioslave (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkf5kmahjongg (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: okular (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: step (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: umbrello (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lskat (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sweeper (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: poxml (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (yakkety-proposed) [1:5.2.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted srtp [source] (yakkety-proposed) [1.4.5~20130609~dfsg-1.3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [sync] (yakkety-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New binary: libevocosm [ppc64el] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [amd64] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [i386] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [arm64] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [armhf] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [s390x] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ghostscript (yakkety-proposed/main) [9.19~dfsg+1-0ubuntu5 => 9.19~dfsg+1-0ubuntu6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [sync] (yakkety-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [arm64] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [i386] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [s390x] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted monkeysign [amd64] (yakkety-proposed) [2.1.2]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [powerpc] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [armhf] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted python-k8sclient [sync] (yakkety-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted python-os-api-ref [amd64] (yakkety-proposed) [0.3.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ruby-ms-rest-azure [sync] (yakkety-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [ppc64el] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted python-msrestazure [sync] (yakkety-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-terminal-app [amd64] (yakkety-proposed) [0.7.218]
-queuebot:#ubuntu-release- New: accepted ruby-azure-sdk [sync] (yakkety-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted python-adal [sync] (yakkety-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted python-azure-storage [sync] (yakkety-proposed) [0.33.0-1]
-queuebot:#ubuntu-release- New: accepted python-msrest [sync] (yakkety-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-ms-rest [sync] (yakkety-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted vagrant-azure [sync] (yakkety-proposed) [2.0.0~pre1-2]
-queuebot:#ubuntu-release- New: accepted python-applicationinsights [sync] (yakkety-proposed) [0.10.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-haikunator [sync] (yakkety-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-azure [sync] (yakkety-proposed) [2.0.0~rc6+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-timeliness [sync] (yakkety-proposed) [0.3.8-1]
-queuebot:#ubuntu-release- New binary: chrome-gnome-shell [amd64] (yakkety-proposed/none) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libevocosm [powerpc] (yakkety-proposed/universe) [4.0.2-3.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-adal [amd64] (yakkety-proposed/universe) [0.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-k8sclient [amd64] (yakkety-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-haikunator [amd64] (yakkety-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vagrant-azure [amd64] (yakkety-proposed/universe) [2.0.0~pre1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-applicationinsights [amd64] (yakkety-proposed/universe) [0.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-timeliness [amd64] (yakkety-proposed/universe) [0.3.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-msrest [amd64] (yakkety-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [amd64] (yakkety-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted libevocosm [arm64] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libevocosm [i386] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libevocosm [ppc64el] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-adal [amd64] (yakkety-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- New: accepted python-k8sclient [amd64] (yakkety-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-haikunator [amd64] (yakkety-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted vagrant-azure [amd64] (yakkety-proposed) [2.0.0~pre1-2]
-queuebot:#ubuntu-release- New: accepted libevocosm [amd64] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libevocosm [powerpc] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-applicationinsights [amd64] (yakkety-proposed) [0.10.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-timeliness [amd64] (yakkety-proposed) [0.3.8-1]
-queuebot:#ubuntu-release- New: accepted libevocosm [armhf] (yakkety-proposed) [4.0.2-3.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ghostscript [source] (yakkety-proposed) [9.19~dfsg+1-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: kate (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libint2 (yakkety-proposed/universe) [2.1.0~beta2-2 => 2.1.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libint2 [sync] (yakkety-proposed) [2.1.0-1.1]
-queuebot:#ubuntu-release- Unapproved: kate (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libunwind (yakkety-proposed/main) [1.1-4.1ubuntu1 => 1.1-4.1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libunwind [source] (yakkety-proposed) [1.1-4.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libxml2 (yakkety-proposed/main) [2.9.4+dfsg1-1 => 2.9.4+dfsg1-2] (core) (sync)
<slangasek> Odd_Bloke: hi, still around?
-queuebot:#ubuntu-release- Unapproved: zfs-linux (yakkety-proposed/main) [0.6.5.8-0ubuntu3 => 0.6.5.8-0ubuntu4] (no packageset)
<tsimonq2> could the release team please approve all the packages recently uploaded by Rohan Garg?
<tsimonq2> the faster we fix any issues the better
<Odd_Bloke> slangasek: o/
<slangasek> doko_: any idea why '#include_next <sys/param.h>' would fail on armhf? https://launchpad.net/ubuntu/+source/ctfutils/10.3~svn297264-2/+build/9825511
<slangasek> hmm maybe because they're using -isystem like a crazy person
<stokachu> pitti: just clarifying juju2 rc2 for yakkety, you are going to remove the 32bit packages manually?
-queuebot:#ubuntu-release- Unapproved: glob2 (yakkety-proposed/universe) [0.9.4.4-2.4ubuntu2 => 0.9.4.4-2.5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted glob2 [sync] (yakkety-proposed) [0.9.4.4-2.5]
-queuebot:#ubuntu-release- Unapproved: konsole (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
<bdmurray> I have messed with casper in a bit could someone have a look at http://paste.ubuntu.com/23257331/?
<bdmurray> s/have/haven't/
-queuebot:#ubuntu-release- New source: gce-compute-image-packages (yakkety-proposed/primary) [20160826-0ubuntu1]
<bdmurray> slangasek: ^^
<slangasek> bdmurray: let's see
<slangasek> bdmurray: how is this undone for the actual live install?
<slangasek> does the package copy grab from the underlay, not from the live fs?
-queuebot:#ubuntu-release- Unapproved: comix (yakkety-proposed/universe) [4.0.4-3 => 4.0.4-3ubuntu1] (no packageset)
<bdmurray> slangasek: I don't know actually
-queuebot:#ubuntu-release- Unapproved: accepted comix [source] (yakkety-proposed) [4.0.4-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kblackbox (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
<slangasek> bdmurray: we'd want to be sure of that... looking at all the other scripts, they seem to only mess with stuff under /root
<slangasek> oh
<slangasek> that's because /root is / ;)
<bdmurray> slangasek: ooh, oops I forgot to add /root back in
<slangasek> bdmurray: ok yes, now that I understand that /root is not /root, it looks ok to me in terms of casper policy - but also you need to be looking at /root/etc/apt instead of /etc so
<bdmurray> How could it be tested for Xenial? We should SRU it there.
<slangasek> bdmurray: by building a daily image and testing the daily image to make sure its config post-install is correct?
-queuebot:#ubuntu-release- New binary: ruby-ms-rest [amd64] (yakkety-proposed/universe) [0.5.0-1] (no packageset)
<wolsen> I know everyone is busy, but when someone gets a chance - is there any possibility of getting fix for lp#1624014  into klibc today?
<nacc> wolsen: it's fix committed and is in proposed?
<wolsen> nacc: indeed it is
<nacc> wolsen: are you asking if it's going to be released?
<wolsen> nacc, that's what I'm asking
<wolsen> sorry if I wasn't more clear
-queuebot:#ubuntu-release- Unapproved: accepted marble [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<bdmurray> wolsen: we try not to release packages from -proposed to -updates on Fridays because of the weekend
<wolsen> bdmurray: that's a perfectly good reason
<bdmurray> wolsen: Feel free to ping me on Monday though
<wolsen> bdmurray: ack will do, thanks!
<slangasek> mwhudson: I'm uncertain why golang-golang-x-tools build-depends on golang-doc, but golang-doc is uninstallable on powerpc because it's arch: all and depends on golang-1.6-doc; does it make sense to have it arch-dep and depend on gccgo-6-doc?
-queuebot:#ubuntu-release- New binary: python-msrestazure [amd64] (yakkety-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: casper (yakkety-proposed/main) [1.378 => 1.379] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (yakkety-proposed) [1:5.2.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libgweather (yakkety-proposed/main) [3.20.3-1 => 3.20.3-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (yakkety-proposed) [1.4.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: marble [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted baloo-widgets5 [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (yakkety-proposed) [2:10.0.7-3227872-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (yakkety-proposed) [1:6.2.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: marble [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: comix (xenial-proposed/universe) [4.0.4-1 => 4.0.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (yakkety-proposed) [1.30.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [source] (yakkety-proposed) [15.04.0+16.10.20160705.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: akonadi [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (kubuntu)
<slangasek> santa_, acheronuk: why do most of these kubuntu uploads appear not to share history with the Debian KDE packages, despite having later versions?  I thought Kubuntu worked closely with the Debian KDE maintainers
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-calendar [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
#ubuntu-release 2016-10-01
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-search [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> bsanta_, acheronuk: random example: kf5-messagelib in Debian unstable has some Breaks/Replaces not present in the Ubuntu version just uploaded
<slangasek> and there are symbols file differences that look suspiciously like you'll have build failures on some archs that have already been fixed in Debian
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> santa_, acheronuk: (analitza) you should really never need to bump the minimum version of symbols in symbols files, and it makes it rather difficult to sanity-check the diff for accidentally dropped symbols
-queuebot:#ubuntu-release- Unapproved: accepted analitza [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debootstrap (yakkety-proposed/main) [1.0.81ubuntu1 => 1.0.81ubuntu2] (core)
-queuebot:#ubuntu-release- New: accepted kleopatra [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (yakkety-proposed) [1.0.81ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kontactinterface (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [source] (yakkety-proposed) [16.04.3-0ubuntu1]
<slangasek> xnox: any expectation of getting rid of boost1.60 for 16.10?
-queuebot:#ubuntu-release- Unapproved: accepted ark [source] (yakkety-proposed) [4:16.04.3a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted artikulate [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> santa_: is it really correct that audiocd-kio 16.04.3 has no changes from 15.12.3?
-queuebot:#ubuntu-release- Unapproved: rejected audiocd-kio [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted blinken [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: asterisk-flite (yakkety-proposed/universe) [2.2-1 => 2.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bomber [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5eventviews [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted asterisk-flite [source] (yakkety-proposed) [2.2-1build1]
-queuebot:#ubuntu-release- Unapproved: kontactinterface (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted bovo [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cantor [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New sync: fonts-atarismall (yakkety-proposed/primary) [2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted cervisia [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dolphin [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dolphin-plugins [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<valorie> slangasek: "why do most of these kubuntu uploads appear not to share history with the Debian KDE packages, despite having later versions?  I thought Kubuntu worked closely with the Debian KDE maintainers" -- we used to share packaging on their git
<valorie> but they never used our packaging, and their git had so many timeouts that we moved it back to LP git
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [ppc64el] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
<valorie> we do merge whenever possible
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [amd64] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [i386] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [arm64] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [powerpc] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [armhf] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dragon [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5ksieve [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted filelight [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdewebdev (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:15.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-baseapps (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:15.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: utidylib (yakkety-proposed/universe) [0.3-1 => 0.3-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gpgmepp [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5kdgantt2 [s390x] (yakkety-proposed/none) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted granatier [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gwenview [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted jovie [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted juk [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkleo [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kaccessible [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [sync] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: kpat (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted akonadi [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-atarismall [sync] (yakkety-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-msrestazure [amd64] (yakkety-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted akonadi [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-ms-rest [amd64] (yakkety-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted akonadi [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5kdgantt2 [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kaccounts-integration [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> valorie: well, codehosting in lp is one thing; but I'm seeing a lot of these packages that clearly haven't merged packaging from what's currently in Debian unstable
-queuebot:#ubuntu-release- New binary: fonts-atarismall [amd64] (yakkety-proposed/none) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kaccounts-providers [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<valorie> slangasek: probably we packaged them weeks ago
-queuebot:#ubuntu-release- New binary: libxml2 [ppc64el] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
<valorie> I hope we'll solve that problem soon
<valorie> we're doing too much extra work
-queuebot:#ubuntu-release- New binary: libxml2 [i386] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- New binary: libxml2 [amd64] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- New binary: libxml2 [s390x] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- New binary: libxml2 [arm64] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kajongg [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libxml2 [powerpc] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kalarmcal [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libxml2 [armhf] (yakkety-proposed/main) [2.9.4+dfsg1-2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kalgebra [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kde-runtime [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kalzium [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> valorie: fwiw kde-runtime is an example; the package in Debian dropped the build-dep on obsolete libqzeigteist-dev months ago, but this packaging change wasn't merged into what was uploaded to yakkety today
-queuebot:#ubuntu-release- Unapproved: accepted kamera [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> valorie: and then, curiously, there are packages such as libkdeedu which Debian has removed as 'obsolete', but are in the queue now with new upstream versions (?)
-queuebot:#ubuntu-release- Unapproved: accepted kanagram [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kapman [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kapptemplate [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kde-runtime (yakkety-proposed/universe) [4:15.12.3-0ubuntu2 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kate [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted katomic [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<valorie> slangasek: I will pass this along to our packagers
<valorie> and we'll get it cleaned up ASAP
-queuebot:#ubuntu-release- Unapproved: accepted kblackbox [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> valorie: cheers
<valorie> thank you for the useful feedback
-queuebot:#ubuntu-release- Unapproved: accepted kblocks [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kblog [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-atarismall [amd64] (yakkety-proposed) [2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted kbreakout [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kbruch [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcachegrind [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcalc [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcalcore [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: evolution-rss (yakkety-proposed/universe) [0.3.95-6 => 0.3.95-6build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-ms-rest-azure [amd64] (yakkety-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-rss [source] (yakkety-proposed) [0.3.95-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted kcalutils [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcharselect [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-azure [amd64] (yakkety-proposed/universe) [2.0.0~rc6+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kcolorchooser [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcontacts [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcron [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libxml2 [amd64] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [armhf] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [powerpc] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [s390x] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [arm64] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [ppc64el] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libxml2 [i386] (yakkety-proposed) [2.9.4+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted kde4libs [source] (yakkety-proposed) [4:4.14.22-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kde-baseapps [source] (yakkety-proposed) [4:15.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kde-baseapps [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdebugsettings [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-dev-scripts [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kde-dev-utils [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdeedu-data [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<xnox> slangasek, with another stab at calligra and a few demotions to proposed it can be done.
<xnox> (boost1.60)
-queuebot:#ubuntu-release- Unapproved: rejected kdegraphics-mobipocket [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdegraphics-strigi-analyzer [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdegraphics-thumbnailers [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdenetwork-filesharing [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdenetwork-strigi-analyzers [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdenlive [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepimlibs [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-runtime [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdesdk-strigi-analyzers [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdesdk-thumbnailers [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src-gles (yakkety-proposed/universe) [5.6.1+dfsg-3ubuntu5~1 => 5.6.1+dfsg-3ubuntu6~4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (yakkety-proposed/main) [5.6.1+dfsg-3ubuntu5~1 => 5.6.1+dfsg-3ubuntu6~4] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted utidylib [source] (yakkety-proposed) [0.3-1build1]
-queuebot:#ubuntu-release- Unapproved: rkt (yakkety-proposed/universe) [1.10.0+dfsg-1 => 1.13.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src-gles [sync] (yakkety-proposed) [5.6.1+dfsg-3ubuntu6~4]
-queuebot:#ubuntu-release- Unapproved: kpat (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted rkt [sync] (yakkety-proposed) [1.13.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: kpimtextedit (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kde-spectacle [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: workrave (yakkety-proposed/universe) [1.10.15-3 => 1.10.16-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted workrave [sync] (yakkety-proposed) [1.10.16-1]
-queuebot:#ubuntu-release- Unapproved: kpat (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected kdewebdev [source] (yakkety-proposed) [4:15.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kopete (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected kdf [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdiamond [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kfloppy [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: syslog-ng-incubator (yakkety-proposed/universe) [0.5.0-1 => 0.5.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kfourinline [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted syslog-ng-incubator [source] (yakkety-proposed) [0.5.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted kgeography [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kget [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-runtime [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected kgoldrunner [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kgpg [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted khangman [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kdewebdev [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted khelpcenter [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kholidays [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdepim-runtime (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kadu-mime-tex (yakkety-proposed/universe) [2.1-1.1 => 2.1-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kholidays [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kholidays [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kholidays [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kadu-mime-tex [source] (yakkety-proposed) [2.1-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kopete (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected kidentitymanagement [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kig [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kholidays [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kigo [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted killbots [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kholidays [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kimap [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kholidays [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kio-extras [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kholidays [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kiriki [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: asterisk (yakkety-proposed/universe) [1:13.10.0~dfsg-1ubuntu1 => 1:13.10.0~dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted asterisk [source] (yakkety-proposed) [1:13.10.0~dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kiten [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-azure [amd64] (yakkety-proposed) [2.0.0~rc6+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted kjumpingcube [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kldap [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-ms-rest-azure [amd64] (yakkety-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted kholidays [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [armhf] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [s390x] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [arm64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kholidays [i386] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted klettres [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted klickety [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted klines [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kmag [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmahjongg [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmailtransport [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kmbox [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmime [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmines [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmix [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kmousetool [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kmouth [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kmplot [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted knavalbattle [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted knetwalk [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-runtime [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: kontactinterface (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected kolf [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kollision [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kolourpaint [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kompare [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected konquest [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kdesdk-kioslaves [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted konsole [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kontactinterface [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kopete [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kpat [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kpimtextedit [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kppp [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kqtquickcharts [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted krdc [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kremotecontrol [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kreversi [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted krfb [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kross-interpreters [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kruler [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ksaneplugin [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kscd [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kshisen [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ksirk [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> are some of these rejects because there is not apparent source change?
-queuebot:#ubuntu-release- Unapproved: accepted ksnakeduel [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kspaceduel [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<apw> acheronuk, the uploader should be getting a reason, i am not sure if we can see what was said after the fact
<slangasek> acheronuk: yes
-queuebot:#ubuntu-release- Unapproved: accepted ksquares [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> build time (and test runner time) is scarce between now and release; if it's really intended that these new upstream version numbers come with no new tarball, and there's some value in having it under the new version number, we can revisit after the queues drain if there's still time
<acheronuk> slangasek: well, a lot of KDE apps for 16.04 series (especially games) were simply not updated by KDE and the source tarballs just re-spun with the new release numbers. in most case I that I think was becasue KDE had a Qt5 port pending but not done for 16.04 release series
<slangasek> they respin tarballs with *no* content changes?
-queuebot:#ubuntu-release- Unapproved: accepted kstars [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
 * acheronuk glares at kde
<slangasek> that's silly. but anyway, this approach increases the chances that the things that actually have changes in them make it in for release, instead of having resources stolen by pointless rebuilds :)
-queuebot:#ubuntu-release- Unapproved: rejected ksudoku [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> yes, I even check some including the example you gave last nighty. diffing the unpacked sources
-queuebot:#ubuntu-release- Unapproved: accepted ksystemlog [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> the other thing I've rejected for is symbols file changes with no soname / package name change, which usually points to ABI breakage that could wreak havoc if all the packages aren't updated together (which there's a risk of given how close to release we are)
<slangasek> (it's also wrong in general, but especially risky this close to release)
<slangasek> if someone has done the analysis to show that those symbols aren't used by any reverse-deps and it's "safe" to include the ABI changes without a lib package name change, we can rescue them from rejected
-queuebot:#ubuntu-release- Unapproved: accepted kteatime [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: are the reject emails going to the actual uploader or person on the last changelog entry? I believe the former?
<slangasek> acheronuk: the uploader
-queuebot:#ubuntu-release- Unapproved: accepted ktimer [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktnef [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ktouch [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: he is not available until Monday, so so if you could possibly (if not too much trouble) indicate those particular ones with symbols issue etc, that would be helpful.
-queuebot:#ubuntu-release- Unapproved: accepted ktp-accounts-kcm [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: I'll do so going forward, but I wouldn't be able to find this for the already-rejected ones without redownloading them and looking at the debdiffs
-queuebot:#ubuntu-release- Unapproved: rejected libkdeedu [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> (AFAIK there are no perms preventing anyone else from doing this)
<slangasek> pretty sure kidentitymanagement was an ABI issue
<slangasek> beyond that I can't say for sure, sorry
<acheronuk> slangasek: no problem. we appreciate what you can do
-queuebot:#ubuntu-release- Unapproved: accepted ktp-approver [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: hmmm. just unpacked the ktouch 15.12.3 and 16.04.3 sources, and diff shows no change
-queuebot:#ubuntu-release- Unapproved: accepted ktp-auth-handler [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: sure, that's why I rejected
-queuebot:#ubuntu-release- Unapproved: accepted ktp-common-internals [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: so are you saying ultimately they can't be accepted, and we have to leave the old versions? or just not now?
-queuebot:#ubuntu-release- Unapproved: accepted ktp-contact-list [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: if the kubuntu team wants the new version numbers, they can upload later; final freeze is just not a good time for that kind of upload
<acheronuk> slangasek: final freeze isn't for 12 days is it?
-queuebot:#ubuntu-release- Unapproved: accepted ktp-contact-runner [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: that's the different meaning of final freeze, after which no more changes are allowed to anything including unseeded universe packages
<slangasek> right now, we're in the "final freeze" that means a release team member looks at all changes to the seeded packages
<slangasek> to weigh things like "is this worth the increased risk that something else that's release critical won't have time to build before release day"
<acheronuk> that is not clear at all on the wiki schedule
-queuebot:#ubuntu-release- Unapproved: accepted ktp-desktop-applets [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktp-filetransfer-handler [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> "Once the BetaRelease is shipped, we roll back to FeatureFreeze and UserInterfaceFreeze status."
<slangasek> acheronuk: which page is that quoting from?
<acheronuk> https://wiki.ubuntu.com/BetaFreeze
<acheronuk> I guess that badly needs an update ^^^
<slangasek> seems so
<slangasek> otoh it's not linked from https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule at all
-queuebot:#ubuntu-release- Unapproved: accepted ktp-kded-integration-module [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<apw> slangasek, that is beta freeze not beta2freeze
<acheronuk> slangasek: it is linked from https://wiki.ubuntu.com/FreezeExceptionProcess
<acheronuk> probably how I ended up with that link
<acheronuk> in fact, looking at the modifications dates for the some pages, they are a bit scarily old. 2012 etc
<apw> acheronuk, the one i am looking at 2009 :/
<acheronuk> apw: eek!
-queuebot:#ubuntu-release- Unapproved: accepted ktp-send-file [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktp-text-ui [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktuberling [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kturtle [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kubrick [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kuser [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwalletmanager [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: if I were you I'd be worrying about the build failures; e.g. kde4libs FTBFS on on armhf,ppc64el,s390x with symbol failures, chances are Debian has a fix for these
<acheronuk> slangasek: yes, I was already 'worrying' about those.
<slangasek> ok :)
-queuebot:#ubuntu-release- Unapproved: accepted kwordquiz [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected libkcddb [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> I am keeping an eye on http://qa.ubuntuwire.org/ftbfs/#kubuntu
-queuebot:#ubuntu-release- Unapproved: accepted libkcompactdisc [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkdegames [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: libkeduvocdocument: symbols file (i.e. ABI) change
-queuebot:#ubuntu-release- Unapproved: rejected libkeduvocdocument [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: I will likely have to pass those onto santa_ , as he has the greater experience of available people with that sort of issue. but noted, and thank you :)
-queuebot:#ubuntu-release- Unapproved: accepted libkf5kdcraw [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5kipi [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5kmahjongg [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5sane [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkomparediff2 [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> the original plan was to sync apps 16.08 with debian, and go with those. but didn't happen in time due to shortage of full -devs, and lack of qtwebengine being done for Yakkety archive, which meant the 16.08 apps would not build most of KDEPIM
<slangasek> acheronuk: btw, the strigi packages, according to the Debian maintainers, are obsolete and have all been dropped from Debian unstable; since none of them had actual content updates for 16.04.3, you might want to check if we can do the same
-queuebot:#ubuntu-release- Unapproved: accepted lokalize [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> (I mention this now because I noticed lokalize dropped its strigi dep)
-queuebot:#ubuntu-release- Unapproved: accepted lskat [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected mplayerthumbs [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5sane [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
<acheronuk> slangasek: noted as well. not sure if those were dropped when these were first staged in our ppas, but it's clear there needs to be some better communication with debian on such matters
<slangasek> mplayerthumbs is another one that's been dropped in Debian but is still in yakkety because digikam depends on it
-queuebot:#ubuntu-release- Unapproved: rejected okteta [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<slangasek> acheronuk: and I've just rejected okteta because it appears to have regressed its symbols files... the previous ones that had been checked against multiple archs were replaced with ones only checked against x86, and as a result some symbols marked as ppc64el-specific were removed from the list completely
<slangasek> (rejected to save build time on the other architectures since it'll need reuploaded in a way that builds on ppc64el)
<slangasek> do the kubuntu team's ppas have ppc64el enabled?
-queuebot:#ubuntu-release- Unapproved: accepted okular [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> no, and I don't think they ever have had. adding extra architectures was something we discussed the other day as likely needed
-queuebot:#ubuntu-release- Unapproved: rejected palapeli [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<apw> lamont, i do not seem to be able to find cloud-initramfs-tools for yakkety that you requested
-queuebot:#ubuntu-release- Unapproved: accepted parley [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5sane [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted picmi [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected poxml [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted print-manager [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rocs [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted signon-kwallet-extension [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted step [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20160705.1-0ubuntu2 => 15.04.0+16.10.20160705.1-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected svgpart [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected sweeper [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted syndication [source] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted umbrello [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
<acheronuk> slangasek: I have to go. Thanks for the help do far.
<slangasek> acheronuk: sure thing.  and that should be the end of the kde packages in the queue, for now
-queuebot:#ubuntu-release- Unapproved: rejected zeroconf-ioslave [source] (yakkety-proposed) [4:16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-control-center [source] (yakkety-proposed) [15.04.0+16.10.20160705.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted bzr [source] (xenial-proposed) [2.7.0-2ubuntu3]
-queuebot:#ubuntu-release- New binary: python-azure-storage [amd64] (yakkety-proposed/universe) [0.33.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-azure-sdk [amd64] (yakkety-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ktp-call-ui [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-19.21] (core, kernel)
<cjwatson> acheronuk: the PPA owner can self-enable ppc64el FWIW; shouldn't be something that requires extensive discussion.  http://blog.launchpad.net/ppa/ppas-for-ppc64el
-queuebot:#ubuntu-release- New binary: ktp-call-ui [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-19.21]
-queuebot:#ubuntu-release- New binary: ktp-call-ui [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ktp-call-ui [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ktp-call-ui [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
<acheronuk> cjwatson: are launchpad ok with us doing that. with the general slowdown of launchpad publishing in recent times, was sort of reluctant to give LP extra build jobs for everything we stage in our ppas
-queuebot:#ubuntu-release- New binary: ktp-call-ui [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ktp-call-ui [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.18.1+16.10 => 2.19+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.19+16.10]
<Mirv> if anyone around, letting qtbase-opensource-src in during the weekend would be nice to get autopkgtests infra fully utilized during the weekend.
<cjwatson> acheronuk: it's fine
<cjwatson> acheronuk: we need to sort out the publishing issues, obviously, but I don't think adding an architecture will break th ebank
<cjwatson> *the bank
<cjwatson> there's a branch in my review queue that's supposed to help though I don't know by how much
-queuebot:#ubuntu-release- Unapproved: writerperfect (yakkety-proposed/universe) [0.9.5-1 => 0.9.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted writerperfect [source] (yakkety-proposed) [0.9.5-1build1]
-queuebot:#ubuntu-release- Unapproved: passwordmaker-cli (yakkety-proposed/universe) [1.5+dfsg-3build1 => 1.5+dfsg-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted passwordmaker-cli [sync] (yakkety-proposed) [1.5+dfsg-3.1]
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (yakkety-proposed/universe) [20160922-1ubuntu1 => 20161001-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (yakkety-proposed) [20161001-1ubuntu1]
<tsimonq2> cjwatson: another concern the Kubuntu team had was Launchpad disk space
<tsimonq2> cjwatson: I think that's the main reason why we didn't have *all* the PPAs enabled
<tsimonq2> cjwatson: (arches, rather)
<tsimonq2> cjwatson: if we can be guaranteed lots of disk space for our PPAs, then I personally think we will discuss it more
 * tsimonq2 takes off Kubuntu hat and puts on Lubuntu hat
<tsimonq2> the only package that is currently FTBFS in the lubuntu packageset is hardinfo. This is due to new build flags, and this has been a problem since *vivid*. Could a release team member please review the email I sent detailing this fix and upload? https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html
 * slangasek blinks at the new incoming component-mismatches
<slangasek> tsimonq2: release team != ubuntu-sponsors; you might want to file a bug with patch and subscribe ubuntu-sponsors first, as that's a wider pool and might get you a faster response (without taking away from release work)
 * tsimonq2 tries again
<tsimonq2> thanks slangasek
<tsimonq2> (stupid thing, I should have known that, sorry for wasting your time)
<slangasek> it's not a waste, and we do double duty as sponsors also - but today I'm only doing queue management :)
<slangasek> tsimonq2: speaking of lubuntu hats, lubuntu images are all still reporting as oversized, all the way back to trusty; would be great if the lubuntu team would set a new realistic limit
<tsimonq2> slangasek: we're aware of that, and we're going to discuss at our Z planning meeting
 * slangasek considers picking a limit in the meantime so that the failures stop cluttering his inbox
<slangasek> :)
<tsimonq2> slangasek: please set the limit to 1 GB for the time being
<tsimonq2> slangasek: and can you sign me up for whatever Lubuntu-related emails y'all get, please? :)
<slangasek> tsimonq2: will do on both counts, thanks.  preferred email?
<tsimonq2> slangasek: tsimonq2@lubuntu.me for Lubuntu stuff
<tsimonq2> slangasek: otherwise tsimonq2@ubuntu.com works
 * tsimonq2 takes off Lubuntu hat and puts on Kubuntu hat
<tsimonq2> slangasek: where's the queue of things to fix?
<slangasek> tsimonq2: build failures; update_excuses.html; otherwise, mostly AA/release-team-only stuff
<tsimonq2> slangasek: I thought acheronuk linked a queue in Launchpad at one point
<tsimonq2> slangasek: I'm talking about the lava pit you guys throw unapproved packages in ;)
<acheronuk> tsimonq2: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=4
<slangasek> ah that one
<tsimonq2> ah yes, thanks
<tsimonq2> slangasek: are there reasons somewhere? have you outlined what's wrong (and I just need to read IRC logs)?
<valorie> I did send an email to -devel last night
<slangasek> tsimonq2: the reasons don't get saved, only emailed to the uploader, and unfortunately I was trying to process these as quickly as possible so I took no notes.  But if you see that the package has a queue diff from the previous version containing no upstream changes (or only trivial ones that don't affect the package output), that's the reason; otherwise it's another reason, and in most cases
<slangasek> that other reason was concern about ABI-breaking changes
<tsimonq2> ah ok
<acheronuk> tsimonq2: was outlining them this morning here after I asked. ones before I asked would be in the reject email to shadeslayer
<tsimonq2> ok acheronuk
<valorie> tsimonq2: he might forward if you ask him
<acheronuk> [18:14]  <shadeslayer> but won't be around till monday to sponsor fixes
<slangasek> yeah, and the vast majority of them were "rejecting this no-op upload".  There were only a couple after our conversation "this morning" that needed substantive follow-up
<acheronuk> valorie: so I guess he won't be around to forward those until Monday either..
<acheronuk> slangasek: yes, I think we can work out 90% of it at least
<valorie> he might read email
<acheronuk> valorie: have emailed him
<valorie> cool
<cjwatson> tsimonq2: adding an architecture for a PPA that has a good reason for it is a perfectly good reason for requesting a quota bump
<cjwatson> tsimonq2: that won't be a problem
<valorie> \o/
<tsimonq2> cjwatson: since both of our major hurdles have been met, I'm enabling All The Arches on the PPAs, thanks :)
<acheronuk> tsimonq2 cjwatson:  I think we are locked out from enabling powerpc and s390x?
 * tsimonq2 takes off Kubuntu hat and puts on Lubuntu hat
<tsimonq2> bug 1629601
<ubot5> bug 1629601 in hardinfo (Ubuntu) "FTBFS due to build flags introduced in vivid" [Undecided,In progress] https://launchpad.net/bugs/1629601
<tsimonq2> needs sponsoring if someone has a minute :) ^
 * tsimonq2 takes off Lubuntu hat and puts on Kubuntu hat
<tsimonq2> hat juggling! :P
<acheronuk> :P
<tsimonq2> acheronuk: correct. cjwatson, if I give you a list of our staging PPAs, would you be able to enable those arches on there?
<cjwatson> tsimonq2,acheronuk: Sorry, can't enable powerpc or s390x for non-Canonical staff - we don't have adequate sandboxing there yet
<tsimonq2> :(
<tsimonq2> cjwatson: have an ETA?
<cjwatson> no
<cjwatson> it's "whenever we get scalingstack working there"
<tsimonq2> cjwatson: anything anyone can help with?
<cjwatson> I doubt it, unless you work in our sysadmin team
<tsimonq2> cjwatson: and I would have to work at Canonical then?
<cjwatson> correct
<tsimonq2> want my resume? :P
<cjwatson> not a hiring manager
<cjwatson> don't want to be one :)
<tsimonq2> gosh darnit :P
<cjwatson> (to be clear, they're already working on deploying a new scalingstack region where it *should* be possible to get powerpc and s390x up and running, but they're unknown quantities and so I don't want to promise any kind of ETA)
<cjwatson> (so it's not like there's no work going on)
<tsimonq2> I see, so at the very minimum it's being worked on?
<acheronuk> tsimonq2: I think hiring you would break a few employment laws as well :P
<cjwatson> the prerequisites for it are being worked on
<cjwatson> er, right, we only hire people who can sign legally-binding contracts - run into that one in the past
<tsimonq2> cjwatson: what if I already worked with Canonical legal to get the CLA signed? :P
<acheronuk> joking aside, we appreciate that it's being worked on. I presume a notice will go out somewhere when it's available?
<tsimonq2> acheronuk: no, I'm 14, I can get hired with a permit in my state. :P
<cjwatson> tsimonq2: the CLA is much less critical than an employment contract
<tsimonq2> ah ic
<cjwatson> anyway, do I look like HR? :)
<cjwatson> acheronuk: definitely
<tsimonq2> +1 acheronuk :)
<acheronuk> cjwatson: any particular list/place? I'm probably subbed to at least one it would go on, but can I check?
<tsimonq2> cjwatson: can you point me towards someone? you're literally the first person to give me a straight answer on why I can't work at Canonical (yet). :P lol
<tsimonq2> (kidding, unless you want to? lol)
<valorie> tsimonq2: I assume they have to follow the laws in the jurisdiction where they are headquartered, first
<tsimonq2> valorie: I checked those out too, same
<valorie> Isle of Man as I recall
 * tsimonq2 does his homework
<tsimonq2> well no they have a US office
<cjwatson> tsimonq2: in the past I've heard a very flat "nobody under 18"; I have no idea whether this is still true
<cjwatson> tsimonq2: I don't have anyone to point you at though; it's been quite a few years since I was involved in hiring.
<valorie> policy is difficult to change
<tsimonq2> cjwatson: on my 18th birthday I'll submit my applications :P
<acheronuk> tsimonq2: I expect you will submit it well before, and will wanting to sign a contract at midnight on your 18th birthday
<tsimonq2> acheronuk: actually 5:40 AM, that's when I was born :P
<valorie> ha
<cjwatson> acheronuk: blog.launchpad.net
<acheronuk> cjwatson: added to my RSS. thanks :)
-queuebot:#ubuntu-release- Unapproved: zthreads (yakkety-proposed/universe) [2.3.2-7.2 => 2.3.2-7.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zthreads [source] (yakkety-proposed) [2.3.2-7.2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yaret (yakkety-proposed/universe) [2.1.0-5 => 2.1.0-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yaret [source] (yakkety-proposed) [2.1.0-5ubuntu1]
#ubuntu-release 2016-10-02
<ahoneybun> heyo
<ahoneybun> balloons: do you handle the iso.qa site?
<ahoneybun> the Kubuntu Beta 2 both 32 and 64 have daily-live links for http
<ahoneybun> http://iso.qa.ubuntu.com/qatracker/milestones/367/builds/131689/downloads
<ahoneybun> http://iso.qa.ubuntu.com/qatracker/milestones/367/builds/131690/downloads
<ahoneybun> this would be the right link: http://cdimage.ubuntu.com/kubuntu/releases/yakkety/beta-2/
<tsimonq2> ahoneybun: well you don't download the links from the ISO QA site
<tsimonq2> ahoneybun: that's for testing
<ahoneybun> that makes no sense
<ahoneybun> we report results based on that image
<tsimonq2> ahoneybun: they are meant to be ephemeral for testing
<ahoneybun> if we get the wrong image or a dead link to
<tsimonq2> ahoneybun: 2 days and they are dead
<tsimonq2> that's because you're testing the daily
<ahoneybun> either way they are dead links
<tsimonq2> /beta-2/ is published after it's released
<ahoneybun> you don't see the issue
<tsimonq2> ahoneybun: that's intended and I don't see it changing
<tsimonq2> I do see what you're saying
<tsimonq2> and like I said, intended
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu3 => 2.3-0ubuntu4] (edubuntu, ubuntu-server)
<stgraber> bunch of bugfixes for LXD if anyone's around ^
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (yakkety-proposed) [0.6.5.8-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (yakkety-proposed) [1.379]
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (yakkety-proposed) [3.20.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [armhf] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [s390x] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-azure-sdk [amd64] (yakkety-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [arm64] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktp-call-ui [i386] (yakkety-proposed) [16.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-azure-storage [amd64] (yakkety-proposed) [0.33.0-1]
<lamont> apw: doh.
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.29ubuntu1 => 0.29ubuntu1.1] (edubuntu, ubuntu-server)
<lamont> apw: or whoever: I lose access to the hardware for verification monday morning (for at least all of monday) -- if that can land sometime before sun afternoon, it's likely I can test it before I don't have hardware access to do so.  thanks
<stgraber> lamont: version number looks a bit odd for an upload to the dev release
<stgraber> lamont: if you're still around, can I have you re-upload this as ubuntu2 and I'll let it in
<stgraber> lamont: diff otherwise looks good to me, so just version number nitpick :)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu4]
<lamont> stgraber: fine
-queuebot:#ubuntu-release- Unapproved: rejected cloud-initramfs-tools [source] (yakkety-proposed) [0.29ubuntu1.1]
<lamont> stgraber: your lxd fix for me made it into at least yakkety-proposed, yes?
<stgraber> should be in yakkety proper by now, yeah
<lamont> cool
<lamont> which means I can build pure -proposed, without my ppa, for testing
<lamont> Successfully uploaded packages.
 * lamont goes back to the grill.
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.29ubuntu1 => 0.29ubuntu2] (edubuntu, ubuntu-server)
<stgraber> cool, will let it in as soon as LP gives me a diff
<lamont> ta
 * lamont afk, back in the mornintg.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (yakkety-proposed) [0.29ubuntu2]
<tsimonq2> hmm, can I find a list of packagesets somewhere?
<tsimonq2> the API is causing me trouble :/
<stgraber> http://people.canonical.com/~ubuntu-archive/packagesets/
<tsimonq2> if only that would be linked somewhere more obvious...
<tsimonq2> thanks stgraber! :)
-queuebot:#ubuntu-release- Unapproved: vino (yakkety-proposed/main) [3.8.1-0ubuntu11 => 3.8.1-0ubuntu12] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: vino (xenial-proposed/main) [3.8.1-0ubuntu9.1 => 3.8.1-0ubuntu9.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libvisca (yakkety-proposed/universe) [1.0.1-1.1 => 1.0.1-1.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libvisca [source] (yakkety-proposed) [1.0.1-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libtuxcap (yakkety-proposed/universe) [1.4.0.dfsg2-2.2build1 => 1.4.0.dfsg2-2.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libtuxcap [sync] (yakkety-proposed) [1.4.0.dfsg2-2.3]
-queuebot:#ubuntu-release- Unapproved: gnome-user-share (yakkety-proposed/main) [3.14.2-2ubuntu4 => 3.14.2-2ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: systemtap (yakkety-proposed/universe) [3.0-6 => 3.0-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted systemtap [sync] (yakkety-proposed) [3.0-7]
-queuebot:#ubuntu-release- Unapproved: autopkgtest (yakkety-proposed/main) [4.0.5ubuntu1 => 4.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: supercollider-sc3-plugins (yakkety-proposed/universe) [3.7.1~repack-1 => 3.7.1~repack-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted supercollider-sc3-plugins [sync] (yakkety-proposed) [3.7.1~repack-2]
-queuebot:#ubuntu-release- Unapproved: mandos (yakkety-proposed/universe) [1.7.10-1 => 1.7.11-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mandos [sync] (yakkety-proposed) [1.7.11-1]
-queuebot:#ubuntu-release- Unapproved: rtpproxy (yakkety-proposed/universe) [1.2.1-2.1ubuntu1 => 1.2.1-2.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rtpproxy [sync] (yakkety-proposed) [1.2.1-2.2]
-queuebot:#ubuntu-release- Unapproved: transifex-client (yakkety-proposed/universe) [0.11.1+git15~g655c5e9-1 => 0.11.1+git15~g655c5e9-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted transifex-client [sync] (yakkety-proposed) [0.11.1+git15~g655c5e9-1.1]
<Mirv> if qtbase-opensource-src could be let in to yakkety-proposed, it could use the currently free autopkgtest infra
-queuebot:#ubuntu-release- Unapproved: lernid (yakkety-proposed/universe) [1.0.4 => 1.0.7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lernid [source] (yakkety-proposed) [1.0.7]
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9 => 231-9git1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [sync] (yakkety-proposed) [4.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-share [source] (yakkety-proposed) [3.14.2-2ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted vino [source] (yakkety-proposed) [3.8.1-0ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (yakkety-proposed) [5.6.1+dfsg-3ubuntu6~4]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9git1]
-queuebot:#ubuntu-release- Unapproved: synaptic (yakkety-proposed/universe) [0.83 => 0.83+nmu1ubuntu1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: evolution-indicator (yakkety-proposed/universe) [0.2.20-0ubuntu27 => 0.2.20-0ubuntu28] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mail-notification (yakkety-proposed/universe) [5.4.dfsg.1-14build3 => 5.4.dfsg.1-14build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-indicator [source] (yakkety-proposed) [0.2.20-0ubuntu28]
-queuebot:#ubuntu-release- Unapproved: accepted mail-notification [source] (yakkety-proposed) [5.4.dfsg.1-14build4]
<Mirv> (thank you)
<jbicha> could kdegraphics-mobipocket be accepted from the yakkety rejected queue? I see that okular depends on the new version
<jbicha> I'll let someone else try to sort out the other kde stuff
-queuebot:#ubuntu-release- Unapproved: gnome-keyring (yakkety-proposed/main) [3.20.0-2ubuntu3 => 3.20.0-2ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-session (yakkety-proposed/main) [3.20.2-1ubuntu4 => 3.20.2-1ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keyring [source] (yakkety-proposed) [3.20.0-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted synaptic [source] (yakkety-proposed) [0.83+nmu1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: sdformat (yakkety-proposed/universe) [4.1.0-2build1 => 4.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sdformat [sync] (yakkety-proposed) [4.1.1-1]
-queuebot:#ubuntu-release- Unapproved: gazebo (yakkety-proposed/universe) [7.3.0+dfsg-6build1 => 7.3.1+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gazebo [sync] (yakkety-proposed) [7.3.1+dfsg-1]
<lamont> does cloud-initramfs-tools_0.27ubuntu1.1 show up in the xenial queue?
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu4 => 2.3-0ubuntu5] (edubuntu, ubuntu-server)
<stgraber> yep
<stgraber> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (yakkety-proposed) [3.20.2-1ubuntu5]
<lamont> stgraber: can you mkae it land in -proposed?
<lamont> and I suspect that open-iscsi/yakkety-proposed might not be a regression any more, if the test gets retried.  Though I'd start with just retrying the open-iscsi biuld test, not all of them (zomg)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-initramfs-tools [source] (xenial-proposed) [0.27ubuntu1.1]
<lamont> ta
<stgraber> accepted the SRU and re-tried open-iscsi in yakkety (can't retry just a single test)
<lamont> that'll let me test and +1 the SRU pile for xenial
<lamont> figures
<lamont> and thanks
-queuebot:#ubuntu-release- Unapproved: pcl (yakkety-proposed/universe) [1.8.0+dfsg1-3ubuntu2 => 1.8.0+dfsg1-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (yakkety-proposed) [1.8.0+dfsg1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (yakkety-proposed) [2.3-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: lxd (yakkety-proposed/main) [2.3-0ubuntu4 => 2.3-0ubuntu5] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: netatalk (yakkety-proposed/universe) [2.2.5-1ubuntu1 => 2.2.5-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted netatalk [sync] (yakkety-proposed) [2.2.5-1.1]
-queuebot:#ubuntu-release- Unapproved: gmusicbrowser (yakkety-proposed/universe) [1.1.15~ds0-0ubuntu1 => 1.1.15~ds0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gmusicbrowser [sync] (yakkety-proposed) [1.1.15~ds0-1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (yakkety-proposed) [2.3-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: brag (yakkety-proposed/universe) [1.4.1-2 => 1.4.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted brag [source] (yakkety-proposed) [1.4.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: log4cpp (yakkety-proposed/universe) [1.1.1-1 => 1.1.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted log4cpp [sync] (yakkety-proposed) [1.1.1-3]
-queuebot:#ubuntu-release- Unapproved: clustalo (yakkety-proposed/universe) [1.2.2-1 => 1.2.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clustalo [sync] (yakkety-proposed) [1.2.3-1]
#ubuntu-release 2017-09-25
<LocutusOfBorg> doko, this gcc ICE is really recent https://launchpadlibrarian.net/338535910/buildlog_ubuntu-artful-i386.llvm-toolchain-3.8_1%3A3.8.1-24ubuntu7_BUILDING.txt.gz
<LocutusOfBorg> appeared between gcc 7.2.0-4 and 7.2.0-7
<LocutusOfBorg> I'm trying to "give-back"
<jbicha> anyone want to review some UIFe's before the Beta? LP: #1717946 LP: #1718083 LP: #1715869 LP: #1713712
<ubot5> Launchpad bug 1717946 in ubuntu-meta (Ubuntu) "UIFe: Drop xterm and xdiagnose from default install" [Undecided,Confirmed] https://launchpad.net/bugs/1717946
<ubot5> Launchpad bug 1718083 in gnome-control-center (Ubuntu) "UIFe: Add Additional Printer Settings button" [Low,Fix released] https://launchpad.net/bugs/1718083
<ubot5> Launchpad bug 1715869 in gnome-control-center (Ubuntu) "UIFe: It should say 'Position on screen' not 'Screen position' in Dock panel in 3.25.x" [Low,Fix released] https://launchpad.net/bugs/1715869
<ubot5> Launchpad bug 1713712 in gnome-shell-extension-ubuntu-dock (Ubuntu) "[UIFe, FFe] Provide Unity Launcher API" [Medium,New] https://launchpad.net/bugs/1713712
<juliank> apport autopkgtest is broken
<juliank> It just failed for apt 1.5, but 1.5 only moved a comment around, so it can't be the cause of the issue.
<juliank> The test "apport-valgrind creates a user specified sandbox and cache" failed
<juliank> apart from that inconvenience apt/1.5 is good to go
<jbicha> please bump the ostree badtest hints to 2017.11-2ubuntu1
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.13 => 2.02~beta2-36ubuntu3.14] (core)
<sil2100> Who's the official release manager of Kubuntu right now?
<sil2100> acheronuk: ping
<sil2100> acheronuk: hey! I'm prepping stuff for final beta, I noticed the kde-l10n-* packages are a bit old
<acheronuk> slangasek: that is valorie
<sil2100> acheronuk: (from last month)
<sil2100> acheronuk: I noticed you did the last ones, any possibility of getting those regenerated for today?
<sil2100> We're late with everything and I'd like to spin some images
<acheronuk> sil2100: they are the latest release we can ship with our current apps version 17.04.3
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.13 => 1.66.14] (core)
<sil2100> acheronuk: ok, thanks
<acheronuk> sil2100: you about to freeze the archive now?
<sil2100> Not yet, in a bit I will try to
<sil2100> I need to see if all is in place
<acheronuk> sil2100: so would you shout at me if I uploaded something? :P
<sil2100> acheronuk: depends what ;p
<sil2100> I'm new to this yet so there's high chance I won't yell if it doesn't make my work harder ;)
<acheronuk> sil2100: I was going to try unbreaking this: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cantor
<acheronuk> or at least make it broken in a less fatal way....
<acheronuk> but a leaf package, so I can leave it alone and wait. I don't want to cause any delays
<acheronuk> oh, wait. not seeded. so it can't matter I guess
<acheronuk> seeded on any iso I mean
<acheronuk> valorie is current Kubuntu release manager. she is on PDT (UTC -7:00) I think
<sil2100> Yep, unseeded is good
<slangasek> sil2100: http://iso.qa.ubuntu.com/qatracker/milestones/382/builds
<slangasek> sil2100: "has all the images listed on the ReleaseManifest" - this is just kicking off a set of builds by hand for nusakan (and commenting them out in cron)
<sil2100> slangasek: I checked the manifest for the isotracker milestone but I don't see the main Ubuntu there, just flavors
<sil2100> slangasek: I think we need to modify the manifest since it looks like the one we used for beta 1
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Final Beta] (20170925) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Final Beta] (20170925) has been added
<infinity> sil2100: Indeed, Final Beta participation is not optional.  Anyone who intends to release with Artful must participate in Final Beta.  The manifest should be changed to reflect that.
<infinity> (Including removing non-release products, like lubuntu-next and xubuntu-core)
<valorie> sil2100: am I not listed somewhere I should be, as Kubuntu Release Manager?
<valorie> also this is my first time being In Charge, so feel free to school me when tsimonq2 doesn't do it first
<valorie> :-)
<tsimonq2> infinity: But what if I want to release Lubuntu Next? :P
<sil2100> valorie: same here! First time doing such a big release, so I probably don't know where to look for the list of official release managers for flavors
<sil2100> Anyway, will be proceeding with the beta stuff after our meeting now
<tsimonq2> sil2100: Can Lubuntu release Lubuntu Next please?
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Final Beta] (20170925) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Final Beta] (20170925) has been added
<valorie> there is a Official List?
<tsimonq2> valorie: Nope but some people (including me) know who is responsible for what
<tsimonq2> I'd ask people who have done milestone checklist tracking When In Doubt.
<flocculant> sil2100: at least for Xubuntu the manifest is right http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/60/manifest
<flocculant> looking at that Kubuntu isn't :)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-12.13] (core, kernel)
<flocculant> valorie: most of the flavour 'release' type people are in here - or should be :)
<flocculant> and you can certainly ask me anything you want to
<tsimonq2> That too.
<tsimonq2> I *think* everyone except Kylin representatives at least idle here.
<tsimonq2> (could be wrong)
<flocculant> shame that manifest isn't easily edited - perhaps wouldn't hurt to have a 'release contact' page on the wiki each cycle
<flocculant> probably useful for quite a few people
<sil2100> flocculant: yeah, waiting for slangasek to finish the meeting so I can poke him to fix the manifest up ;)
<flocculant> sil2100: trouble with that is - next cycle I believe it just copies, so if a flavour changes things - not likely to even think about the manifest because uneditable
<flocculant> anyway - not likely to be changed from xubuntu pov anytime soon :D
<valorie> yeah, that is not correct -- so how does that get changed?
<valorie> I may or may not be RM long-term
<slangasek> sil2100: done, I think; AIUI Ubuntu-GNOME is not doing any more image releases so I have not enabled them
<flocculant> sil2100: actually re contacts for that on Xubuntu - if rather than nicks of people it could be https://launchpad.net/~xubuntu-release then that will always be correct
<valorie> I was able to remove quite a bit of cruft there we hadn't released for years
<valorie> but not edit the contact person
<valorie> ooo, I like that idea
<valorie> since I envision Release Manager as just the owner of team, anyway
<flocculant> ours is owned by Council
<valorie> ours could be as well
<flocculant> yup
<valorie> I'll ask the KC about it
<valorie> btw your wiki link has moved
<flocculant> wiki link?
<valorie> on ~xubuntu-release
<valorie> https://wiki.ubuntu.com/Xubuntu/Processes#Release_Cycle no longer exists
<flocculant> oh yea - we moved a bunch of stuff
<valorie> nice docs!
<flocculant> thanks :)
<sil2100> tsimonq2: well, I'm new to this, but I guess we will - at least for this beta (since we were releasing it for Beta 1 already)
<sil2100> slangasek: thanks! Yeah, ubuntu-gnome is no more for artful as per jbicha's request
<jbicha> could someone with access drop Ubuntu GNOME from the Artful Daily iso tracker?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-12.13]
<apw> kirkland, what is the gen on these two calc-stats uploads
<kirkland> apw: the older of the two is superceded by the newer
-queuebot:#ubuntu-release- New: rejected calc-stats [source] (artful-proposed) [1.3-0ubuntu1]
<jibel> jbicha, that will remove it from xenial too
<jbicha> jibel: oh, we don't want that. Thanks! :)
<jibel> jbicha, I removed the testsuite for artful, so there is nothing to test, and added a note for the builds.
<jbicha> ok
<tsimonq2> sil2100: Ack, thanks
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.3-0ubuntu1 => 3:11.0.3-0ubuntu2] (openstack, ubuntu-server)
<tsimonq2> Hmmm so is the autosyncer from Debian part of Launchpad or Britney?
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu1 => 2:9.1.2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20170718-0ubuntu1~14.04.0 => 20170921+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20170718-0ubuntu1~16.04.0 => 20170921+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20170718-0ubuntu1~17.04.0 => 20170921+dfsg1-0ubuntu1~17.04.0] (ubuntu-cloud)
<sil2100> Waiting for the archive lock now
<sil2100> Once that's done I'll kick new images
<tsimonq2> \o/
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Zesty 17.04 | Archive: final beta freeze | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<sil2100> We should be frozen now \o/
<tsimonq2> \o/
<sil2100> I think I kicked off all the images
<sil2100> Will check in on those in an hour
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (artful-proposed/universe) [3.26.0-1ubuntu1 => 3.26.0-1ubuntu2] (desktop-extra)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Final Beta] (20170925.2) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Final Beta] (20170925.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Final Beta] (20170925) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Final Beta] (20170925) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Final Beta] has been updated (20170925.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Final Beta] has been updated (20170925.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Final Beta] (20170925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Artful Final Beta] (20170925.1) has been added
#ubuntu-release 2017-09-26
-queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.7-0ubuntu0.16.04.1 => 10.2.9-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceph (zesty-proposed/main) [10.2.7-0ubuntu0.17.04.1 => 10.2.9-0ubuntu0.17.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<ginggs> cjwatson: you've dealt with R transitions before, right? does LP: #1719245 seem do-able?
<ubot5> Launchpad bug 1719245 in r-base (Ubuntu) "FFe: Sync r-base 3.4.1.20170921-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1719245
<LocutusOfBorg> btw is ben sad? http://people.canonical.com/~ubuntu-archive/transitions/html/r-api.html
<LocutusOfBorg> I would have expected this link to appear, I pushed the r-api ben file 15 hours ago or so
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (artful-proposed) [3.26.0-1ubuntu2]
<cjwatson> tsimonq2: The auto-syncer is part of ubuntu-archive-tools
<cjwatson> ginggs: It's possible I did one at some point but I don't remember what it involved ...
<cjwatson> LocutusOfBorg: Uncaught exception: ben-specific error: parse error in file "config/monitor/planned/r-api.ben", line 6, character 0
<cjwatson> LocutusOfBorg: missing semicolon on the last line, I think
<ginggs> cjwatson: ok, i think it's just going to be many many no-change rebuilds, but I'll wait for an ack from release team
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.0-2 => 3.26.0+20170925~ea214fb-1] (desktop-extra, ubuntu-desktop) (sync)
<fossfreedom_> LocutusOfBorg: hi - need a bit of help! I'm just testing Ubuntu and Ubuntu Budgie beta 2 and I've discovered that bug 1719136 is specifically due to virtualbox (crashing gnome-session I think) - works just fine on real hardware and vmware workstation.  I need to reassign it from ubiquity to another package.  What's that package?  xorg?
<ubot5> bug 1719136 in ubiquity (Ubuntu) "Ubuntu and Ubuntu Budgie - there is no background picture on try/install" [Undecided,Confirmed] https://launchpad.net/bugs/1719136
<LocutusOfBorg> cjwatson, interesting, the "auto-trackers" generated by debian has no ending semicolon, and they worked (I see e.g. monitor/old/gdcm.ben auto-petsc.ben gsl.ben)
<LocutusOfBorg> but maybe I'm wrong
<LocutusOfBorg> lets see the next regeneration
<LocutusOfBorg> fossfreedom_, do you have 3d acceleration enabled? do you have virtualbox-guest-x11 installed?
<LocutusOfBorg> which vbox version
<fossfreedom_> I've tried both with and without 3D acceleration. Occurs with virtualbox 5.1.26 and 5.1.28
<jbicha> LocutusOfBorg: artful vbox running the artful live iso so -guest-x11 isn't installed. It might be a regression triggered by Linux 4.13
<fossfreedom_> likely - everything was fine until 4.13 landed last week
<jbicha> fossfreedom_: see LP: #1718679
<ubot5> Launchpad bug 1718679 in linux (Ubuntu) "Upgrade to 4.13.0-11.12 in artful amd64 VM breaks display on wayland" [High,Fix committed] https://launchpad.net/bugs/1718679
<jbicha> changelog for linux 4.13.0-12.13 (in artful-proposed) says that CONFIG_DRM_VBOXVIDEO=n is set now
<fossfreedom_> ah - so its likely to be fixed when linux 4.13.0-12.13 migrates to the release pocket?  I presume after the beta?
-queuebot:#ubuntu-release- Unapproved: wxpython3.0 (artful-proposed/universe) [3.0.2.0+dfsg-4 => 3.0.2.0+dfsg-5] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ettercap (artful-proposed/universe) [1:0.8.2-9ubuntu1 => 1:0.8.2-10build1] (no packageset)
<LocutusOfBorg> what they did do in the kernel
<LocutusOfBorg> git grep DRM_VBOX
<LocutusOfBorg> drivers/staging/Makefile:obj-$(CONFIG_DRM_VBOXVIDEO)    += vboxvideo/
<LocutusOfBorg> apw, so, this is becoming a reality
<apw> LocutusOfBorg, seems that someone is upstreaming your drivers, oh and they don't work :)  that one is now off in the kernel i believe
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.0-2 => 3.26.0+20170925~ea214fb-1] (desktop-extra, ubuntu-desktop) (sync)
<LocutusOfBorg> apw, actually I followed strictly the kernel development and the binaries in the vbox-dev mail list
<LocutusOfBorg> I just didn't know they they were already merged
<LocutusOfBorg> not sure what fedora did to make them work, maybe some xorg/wayland changes
<LocutusOfBorg> for sure having them mainline will make me and you happier
<LocutusOfBorg> at least me :p
<sforshee> LocutusOfBorg: I just had to disable the ones merged upstream because they weren't working with wayland
<LocutusOfBorg> sforshee, this is exactly what we are talking about
<LocutusOfBorg> but AFAIK fedora is using wayland by default
<LocutusOfBorg> maybe we can see if they patched it?
<sforshee> ah, /me needs to read backscroll
<apw> LocutusOfBorg, it is pretty late in the day to be trying to switch drivers for that
<LocutusOfBorg> no problem sforshee thanks for "fixing" :)
<LocutusOfBorg> apw, for sure we need to investigate and revert once we found the issue, I'm not asking to change that now
<LocutusOfBorg> but 18.04 with mainline kernel drivers is a nice thing
 * LocutusOfBorg goes asking on vbox-dev
<sforshee> LocutusOfBorg: yeah once we know what's wrong I can turn it back on, but fwiw I did try with 4.14-rc1 and saw the same problem
<sforshee>  turn it on for the next release I mean
<LocutusOfBorg> got it, thanks
<jbicha> apw: do you know if the kernel update is likely to make it into Final Beta before release?
<jbicha> or sforshee ^ ?
<sil2100> jibel: hey! Will you be performing https://wiki.ubuntu.com/ReleaseValidationProcess for final beta?
<Laney> sil2100: what's the chat regarding accepting stuff and respins?
-queuebot:#ubuntu-release- Unapproved: accepted ettercap [source] (artful-proposed) [1:0.8.2-10build1]
 * Laney just turned on the auto-accept cron job
 * apw ^5 Laney
 * sil2100 probably doesn't have th necessary backlog for that
<sforshee> jbicha: I think we can likely make that happen
<sil2100> Laney: thanks for furning that on, I probably didn't have the power and everyone that did was away
<apw> jbicha, i would vote for that kernel to be in the beta, as it has a significant vbox regression fix in it
<sil2100> apw: what's the ETA for the new kernel?
<Laney> pew pew pew
<apw> sil2100, it is built and in -proposed waiting on a rerun of a systemd ADT test which is expected to pass
<sil2100> I only see a few test results submitted so I guess we could still re-spin
<sil2100> (could someone give me the bug number for the vbox regression?)
<Laney> the linux-meta tests are actually green
<Laney> win
<jbicha> sil2100: LP: #1718679
<ubot5> Launchpad bug 1718679 in linux (Ubuntu) "Upgrade to 4.13.0-11.12 in artful amd64 VM breaks display on wayland" [High,Fix committed] https://launchpad.net/bugs/1718679
<sil2100> jbicha: thanks!
<sil2100> Laney: \o/
<sil2100> So I guess we'll have the kernel promotable soonish?
<Laney> going to accept these things out of the queue then
<Laney> ...and unblock NM
-queuebot:#ubuntu-release- Unapproved: rejected mutter [sync] (artful-proposed) [3.26.0+20170925~ea214fb-1]
-queuebot:#ubuntu-release- Unapproved: accepted wxpython3.0 [sync] (artful-proposed) [3.0.2.0+dfsg-5]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (artful-proposed) [3.26.0+20170925~ea214fb-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (artful-proposed/main) [17.10.15 => 17.10.16] (ubuntu-desktop)
<sil2100> Laney: ok, makes sense, thanks
<jibel> sil2100, I can do
-queuebot:#ubuntu-release- Unapproved: cups (artful-proposed/main) [2.2.4-7ubuntu1 => 2.2.4-7ubuntu2] (core)
<sforshee> sil2100: I'm hoping so, still looking at test results but so far no red flags
<sforshee> like apw said waiting on a systemd rerun in adt
<juliank> Can someone force apt/1.5 to migrate from artful-proposed? It's just a version bump from ~rc4 and a comment location changed, but it's blocked because apport suddenly started failing. Probably should fix apport to, but I'd at least like to have the final apt in the final beta :)
<tkamppeter> Hi. I have uploaded cups 2.2.4-7ubuntu2 with only a small fix in the autopkgtest, needed to let cups-filters 1.17.7 go from -proposed to the release. No regression potential as the code itself has no change.
<tkamppeter> Can you pass this through?
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Artful Final Beta] (20101020ubuntu520) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Artful Final Beta] (20101020ubuntu520) has been added
<Laney> tkamppeter: you probably need to retry the cups-filters tests now that cups has migrated
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cups-filters
<Laney> click those recycle icons
<Laney> No, it had the new cups
<Laney> so your fix doesn't work?
<sil2100> juliank: I see some apport regressions, didn't look at those yet - did you check on them?
<juliank> sil2100: Well, I don't know why they happen. Some valgrind apport log error. There were no functional changes in the apt upload, so I don't see how it could cause that
<juliank> As I wrote, I just moved a comment in the code around
<sil2100> juliank: I see a change in the .service file too
<sil2100> Ah, nvm
<juliank> sil2100: You must be looking at the wrong diff, then, not at 1.5~rc4 to 1.5
<sil2100> I was looking at the wrong diff
<juliank> Which is here https://launchpadlibrarian.net/338547723/apt_1.5~rc4_1.5.diff.gz
<sil2100> ;)
<sil2100> ETOOMANYTABS
<juliank> AFAICT, apport is creating some kind of sandbox, and that fails
<juliank> Was there like a temporary uninstallability problem or something?
-queuebot:#ubuntu-release- Unapproved: kylin-greeter (artful-proposed/universe) [17.10.0 => 17.10.2] (ubuntukylin)
<juliank> That seems to be the issue ERROR: Cannot find package which ships ExecutablePath /bin/true
<juliank> there's of course always the options of new compiler bugs, but then all hope is lost anyway :D
<sil2100> Probably, I guess we'll see once autopkgtests kick in for the new version - I didn't see this failing before really, maybe just bad luck this time
<juliank> sil2100: It also failed before that way
<juliank> for example, 2.20.6-0ubuntu4	binutils/2.29-4ubuntu1	2017-08-08 04:38:40 UTC
<juliank> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/a/apport/20170808_043840_306c1@/log.gz
<Laney> tkamppeter: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<juliank> I guess we could try re-running it
 * Laney runs apport locally
<juliank> Queues were empty, so I triggered them again
<sil2100> juliank: ACK
<juliank> I guess I should prepare 1.2.25 for xenial in the meantime, so 1.4.8 and 1.2.25 can be reviewed together (they're subsets)
-queuebot:#ubuntu-release- Unapproved: debian-installer (artful-proposed/main) [20101020ubuntu520 => 20101020ubuntu521] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-software-center (artful-proposed/universe) [1.3.11 => 1.3.13] (ubuntukylin)
<tkamppeter> I have seen the log of the CUPS autopkgtests and there was still something wrong. This I have fixed in the 2.2.4-7ubuntu2 upload. So this needs to get passed through to -proposed and after that the cups-filters tests be re-triggered.
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (artful-proposed/universe) [1.7.1 => 1.7.4] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (artful-proposed/universe) [1.0.3-0ubuntu1 => 1.0.4-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-menu (artful-proposed/universe) [1.0.2-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (artful-proposed/universe) [1.0.2-0ubuntu1 => 1.0.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-session-manager (artful-proposed/universe) [1.0.1-0ubuntu1 => 1.0.2-0ubuntu1] (ubuntukylin)
<sil2100> hmm, I see a lot of kylin-related uploads
<sil2100> Laney: since we still have some time, maybe you could accept those ^?
-queuebot:#ubuntu-release- Unapproved: accepted kylin-greeter [source] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (artful-proposed) [1.7.4]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menu [source] (artful-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-session-manager [source] (artful-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-software-center [source] (artful-proposed) [1.3.13]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [source] (artful-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (artful-proposed) [1.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.24 => 1.2.25] (core)
<juliank> ^ my work is done, 1.4.7+1.4.8 (-v1.4.6 essentially) is in zesty unapproved queue; and 1.2.25 is in xenial. (^ rbalint)
<juliank> They are also in the PPA at https://launchpad.net/~deity/+archive/ubuntu/apt/+packages
<juliank> although the 1.2.25 there has a different changelog author :D
<rbalint> juliank: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (zesty-proposed) [4.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (artful-proposed) [20101020ubuntu521]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (zesty-proposed) [1:8.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (artful-proposed/main) [0.97ubuntu1 => 0.97ubuntu2] (desktop-core, ubuntu-server)
<juliank> Yay, apport passed
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (zesty-proposed) [2:10.0.6-0ubuntu1]
<sil2100> \o/
<sil2100> Ok, let's stabilize what we already have in -proposed, migrate as much as we can and prep for a respin
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (artful-proposed) [2.2.4-7ubuntu2]
<sil2100> jibel: fust FYI - we will be respinning the images in a bit
<LocutusOfBorg> sil2100, unattended-upgrades please :)
<LocutusOfBorg> it is important, because it might break upgrades
 * LocutusOfBorg AFK
<juliank> Oh, for 1.2.26 I need to change .travis.yml - wily is gone from archive now, and CI failed for the final "bump the version" commit.
<juliank> (the other series already use up-to-date docker images :D)
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (zesty-proposed) [1:8.0.4-0ubuntu1]
<sil2100> LocutusOfBorg: hm, indeed
 * sil2100 sighs
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (artful-proposed) [0.97ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (zesty-proposed) [2:11.0.3-0ubuntu1]
<sil2100> But let's try not accept anything that we don't need now for the beta
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (zesty-proposed) [1:10.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (zesty-proposed) [1:6.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.middleware [source] (zesty-proposed) [3.23.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (zesty-proposed) [3:11.0.3-0ubuntu2]
-queuebot:#ubuntu-release- Builds: Netboot s390x [Artful Final Beta] has been updated (20101020ubuntu521)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (xenial-proposed) [2:9.1.2-0ubuntu2]
<sil2100> A notice to all release-team members! We only have the archive frozen this time, there is no block on britney to keep things lingering in -proposed
<sil2100> So please only accept things into -proposed that we actually consider essential to the beta release
<sil2100> (best not accept anything that's not critical right now)
-queuebot:#ubuntu-release- Unapproved: cairo (artful-proposed/main) [1.14.10-1 => 1.14.10-1ubuntu1] (core)
<mparillo> Other Flavours: I see bad certificates in both FF (second tab, against Mozilla!) and in Discover Updates against Gnome and KDE when testing both 64 and 32-bit Kubuntu ISOs in a VM. Error message in FF pasted here: http://iso.qa.ubuntu.com/qatracker/milestones/382/builds/157594/testcases/1300/results Can anybody confirm that this is not Kubuntu-specfic?
<slangasek> mparillo: what is 'Discover Updates'? I don't see that listed in the test case and it doesn't sound like part of the desktop experience on other flavors
<mparillo> Discover is a 'software store'. But I assume the same root cause is shared with the second tab in Firefox. Have you done a fresh install from a Beta 2 ISO and tested Firefox?
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (artful-proposed/main) [17.10.5 => 17.10.6] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (artful-proposed) [17.10.16]
-queuebot:#ubuntu-release- Unapproved: golang-check.v1 (artful-proposed/main) [0.0+git20161208.0.20d25e2-1 => 0.0+git20161208.0.20d25e2-1build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.23~16.04.1 => 0.29~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: variety (artful-proposed/universe) [0.6.4-3 => 0.6.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libpng1.6 (artful-proposed/main) [1.6.32-2 => 1.6.32-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted variety [sync] (artful-proposed) [0.6.6-1]
<tsimonq2> cjwatson: Ok thanks
<tsimonq2> sil2100: So I went to publish the Call for Testing for Lubuntu... could we get some alternate images spun up please?
<sil2100> tsimonq2: I'll be re-spinning the images once the publisher settles down
<tsimonq2> sil2100: Ack, can you say something here when that is done? I'll hold off on the Call for Testing then.
<sil2100> Sure, I'll also send out a quick mail to ubuntu-devel@ with some info
<flocculant> I thought there'd not be a respin - then I woke up and the coffee was cold :p
<sil2100> Well, we could have done without it, but there was a high kernel-related bug (noticable during testing) that got fixed so seeing that there weren't so many tests done yet, I decided to get that in
<flocculant> :)
<tsimonq2> sil2100: As lon as we get Lubuntu Alternate images :)
<tsimonq2> *long
<sil2100> tsimonq2: in the meantime I'm digging into it to figure out why we didn't have those appearing (same for beta-1 actually)
<tsimonq2> sil2100: Well for Beta 1 they were FTBFS
<tsimonq2> I accepted that we weren't going to have a Beta 1 with Alternates.
<tsimonq2> But dailies should be fine?
<sil2100> tsimonq2: well, there are no dailies for alternates ;p I now see through cdimage logs that there's some error
<sil2100> Which explains why I didn't see them appearing in cdimage even though I kicked them
<sil2100> Digging into that
-queuebot:#ubuntu-release- Unapproved: libxmlada (artful-proposed/universe) [17.1.2017-4 => 17.1.2017-5] (no packageset) (sync)
<sil2100> tsimonq2: I see things migrated so I'll kick all images and then look into what's up with alternate
-queuebot:#ubuntu-release- Unapproved: accepted libxmlada [sync] (artful-proposed) [17.1.2017-5]
<sil2100> Notice: new image builds for final beta have been started!
<tsimonq2> sil2100: slangasek might know more
<sil2100> He's on meetings right now
<sil2100> I'll figure this out, no worries - in case this takes too long I have them all at one place here in NY
<sil2100> I think I know what it might be
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu10 => 234-2ubuntu11] (core)
<tsimonq2> sil2100: Oh you're in NYC, cool :D
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Artful Final Beta] (20170926) has been added
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (artful-proposed/main) [1:3.26.0-0ubuntu2 => 1:3.26.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Unapproved: sweethome3d (artful-proposed/universe) [5.5+dfsg-1 => 5.5.2+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d [sync] (artful-proposed) [5.5.2+dfsg-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Unapproved: gradle-debian-helper (artful-proposed/universe) [1.5.1 => 1.6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle-debian-helper [sync] (artful-proposed) [1.6]
-queuebot:#ubuntu-release- Unapproved: joda-convert (artful-proposed/universe) [1.8.3-1 => 1.9.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mina2 (artful-proposed/universe) [2.0.16-1 => 2.0.16-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: r-base (artful-proposed/universe) [3.4.1-2 => 3.4.1.20170921-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted joda-convert [sync] (artful-proposed) [1.9.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted r-base [sync] (artful-proposed) [3.4.1.20170921-1]
-queuebot:#ubuntu-release- Unapproved: accepted mina2 [sync] (artful-proposed) [2.0.16-2]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Unapproved: gnome-shell (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.0-0ubuntu2] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Final Beta] has been updated (20170926)
<slangasek> tsimonq2, sil2100: if it's just that you're looking for new lubuntu alternate dailies and there aren't any, that's because the cronjob has lubuntu all in one line
<slangasek> so it's all commented out
<sil2100> slangasek: no no, I was building them but they're failing on the debian-cd step
<sil2100> slangasek: so it's funny, the reason they fail is because at one step the whole process is failing because of libustr-1.0-1 not being installed but it's required by debootstrap
<sil2100> slangasek: before Sept the 20th it was found and recognized, now it is not pulled in during the CD creation
<sil2100> slangasek: looking at cdimage I see in the rawlist.debootstrap output it's there but the rawlist that's actually being used doesn't have it, not sure how it's generated
<sil2100> slangasek: the seeds show the libustr-1.0-1 is pulled in through the libustr-dev -> libsemanage1-dev chain
<sil2100> I don't know what could have caused it, checked both the lubuntu and ubuntu seeds and even though there were some changes on the 19th, none of them look like they could be responsible
<slangasek> sil2100: ok, if it's required by debootstrap then it's a priorities mismatch issue in the archive; but why would any -dev be pulled in by the bootstrap set?
<sil2100> There was a new libsemanage upload from do_ko on the 19th as well, but the diff doesn't seem to be messing with the deps
<slangasek> -dev packages shouldn't be part of the debootstrap set
<sil2100> Well, not sure, I just checked here to learn how this ustr lib is pulled in the first place: http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.artful/supported
<slangasek> sil2100: 'supported' is not the stuff that's pulled into the image
<slangasek> and libustr-1.0-1 shows no interesting revdeps
<sil2100> Yeah, might be that something moved it to supported
<sil2100> But I didn't see any changes that could have caused that
<cyphermox> Priority: required.
<cyphermox> ^ this is important.
<slangasek> ah so the issue is that it is currently marked required and it shouldn't be
<slangasek> cyphermox, sil2100, tsimonq2: fixed; needs an archive publish cycle before it takes effect
<slangasek> ah I suspect this is NBS
<slangasek> hmmm strangely not
<slangasek> but yeah, libsemanage1 seems to have dropped a runtime dep on it
<tsimonq2> slangasek: ack
<sil2100> \o/
<sil2100> slangasek: thanks!
<sil2100> So I was looking at the right direction, but didn't check the bin-dependencies, only source ones
<sil2100> Invalidly assumed that since libsemanage-dev was still depping on ustr-dev it was all fine ;) Anyway, it looks like I also should have just looked at the cdimage build logs for the 20th image
<sil2100> cyphermox pointed out it had additional info as it had a task change diff
 * sil2100 learned a lot through this
<cyphermox> so do I
-queuebot:#ubuntu-release- Unapproved: lxd (artful-proposed/main) [2.18-0ubuntu2 => 2.18-0ubuntu3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Artful Final Beta] has been updated (20170926)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (artful-proposed) [2.18-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (artful-proposed) [234-2ubuntu11]
-queuebot:#ubuntu-release- Unapproved: slof (artful-proposed/main) [20161019+dfsg-1 => 20170724+dfsg-1] (ubuntu-server) (sync)
#ubuntu-release 2017-09-27
<slangasek> infinity: are we still avoiding adding a force-badtest on twisted because free might fix it?
-queuebot:#ubuntu-release- Unapproved: trilinos (artful-proposed/universe) [12.10.1-4 => 12.10.1-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted trilinos [source] (artful-proposed) [12.10.1-4build1]
-queuebot:#ubuntu-release- Unapproved: libgnatcoll (artful-proposed/universe) [17.0.2017-2ubuntu2 => 17.0.2017-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libgnatcoll [sync] (artful-proposed) [17.0.2017-3]
-queuebot:#ubuntu-release- Unapproved: abind (artful-proposed/universe) [1.4-5-1 => 1.4-5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: acepack (artful-proposed/universe) [1.4.1-2 => 1.4.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted abind [source] (artful-proposed) [1.4-5-1build1]
-queuebot:#ubuntu-release- Unapproved: bitops (artful-proposed/universe) [1.0-6-1 => 1.0-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cairodevice (artful-proposed/universe) [2.24-2 => 2.24-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cluster (artful-proposed/universe) [2.0.6-2 => 2.0.6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted acepack [source] (artful-proposed) [1.4.1-2build1]
-queuebot:#ubuntu-release- Unapproved: chron (artful-proposed/universe) [2.3-50-2 => 2.3-50-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: boot (artful-proposed/universe) [1.3-20-1 => 1.3-20-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted boot [source] (artful-proposed) [1.3-20-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted chron [source] (artful-proposed) [2.3-50-2build1]
-queuebot:#ubuntu-release- Unapproved: codetools (artful-proposed/universe) [0.2-15-1 => 0.2-15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dbi (artful-proposed/universe) [0.7-1 => 0.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cairodevice [source] (artful-proposed) [2.24-2build1]
-queuebot:#ubuntu-release- Unapproved: date (artful-proposed/universe) [1.2.37-2 => 1.2.37-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cluster [source] (artful-proposed) [2.0.6-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted bitops [source] (artful-proposed) [1.0-6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted codetools [source] (artful-proposed) [0.2-15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted dbi [source] (artful-proposed) [0.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted date [source] (artful-proposed) [1.2.37-2build1]
-queuebot:#ubuntu-release- Unapproved: foreign (artful-proposed/universe) [0.8.69-1 => 0.8.69-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gtools (artful-proposed/universe) [3.5.0-2 => 3.5.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gtable (artful-proposed/universe) [0.2.0-1 => 0.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted foreign [source] (artful-proposed) [0.8.69-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted gtools [source] (artful-proposed) [3.5.0-2build1]
-queuebot:#ubuntu-release- Unapproved: misc3d (artful-proposed/universe) [0.8-4-2 => 0.8-4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mvtnorm (artful-proposed/universe) [1.0-6-2 => 1.0-6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gtable [source] (artful-proposed) [0.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: mnormt (artful-proposed/universe) [1.5-5-2 => 1.5-5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lattice (artful-proposed/universe) [0.20-35-1 => 0.20-35-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: polspline (artful-proposed/universe) [1.1.12-3 => 1.1.12-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lattice [source] (artful-proposed) [0.20-35-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mnormt [source] (artful-proposed) [1.5-5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted polspline [source] (artful-proposed) [1.1.12-3build1]
-queuebot:#ubuntu-release- Unapproved: quadprog (artful-proposed/universe) [1.5-5-3 => 1.5-5-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocgenerics (artful-proposed/universe) [0.22.0-1 => 0.22.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted misc3d [source] (artful-proposed) [0.8-4-2build1]
-queuebot:#ubuntu-release- Unapproved: pvclust (artful-proposed/universe) [2.0-0-1 => 2.0-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mvtnorm [source] (artful-proposed) [1.0-6-2build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-affyio (artful-proposed/universe) [1.44.0-1 => 1.44.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pvclust [source] (artful-proposed) [2.0-0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-affyio [source] (artful-proposed) [1.44.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted quadprog [source] (artful-proposed) [1.5-5-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocgenerics [source] (artful-proposed) [0.22.0-1build1]
-queuebot:#ubuntu-release- Unapproved: gprbuild (artful-proposed/universe) [2017-4 => 2017-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gprbuild [sync] (artful-proposed) [2017-5]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocinstaller (artful-proposed/universe) [1.26.0-1 => 1.26.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomeinfodbdata (artful-proposed/universe) [0.99.0-1 => 0.99.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-dnacopy (artful-proposed/universe) [1.48.0-1build1 => 1.48.0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocinstaller [source] (artful-proposed) [1.26.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomeinfodbdata [source] (artful-proposed) [0.99.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-mergeomics (artful-proposed/universe) [1.4.0-1 => 1.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-ade4 (artful-proposed/universe) [1.7-5-1 => 1.7-5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-dnacopy [source] (artful-proposed) [1.48.0-1build2]
-queuebot:#ubuntu-release- Unapproved: r-bioc-preprocesscore (artful-proposed/universe) [1.36.0-1 => 1.36.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-limma (artful-proposed/universe) [3.30.8+dfsg-1 => 3.30.8+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-limma [source] (artful-proposed) [3.30.8+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-preprocesscore [source] (artful-proposed) [1.36.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-amore (artful-proposed/universe) [0.2-15-1 => 0.2-15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-mergeomics [source] (artful-proposed) [1.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ade4 [source] (artful-proposed) [1.7-5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-amore [source] (artful-proposed) [0.2-15-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-assertthat (artful-proposed/universe) [0.1-1 => 0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-backports (artful-proposed/universe) [1.0.5-1 => 1.0.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-assertthat [source] (artful-proposed) [0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-base64enc (artful-proposed/universe) [0.1-3-1 => 0.1-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-biasedurn (artful-proposed/universe) [1.07-1 => 1.07-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-bms (artful-proposed/universe) [0.3.4-2 => 0.3.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-backports [source] (artful-proposed) [1.0.5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-blockmodeling (artful-proposed/universe) [0.1.8-1 => 0.1.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-beeswarm (artful-proposed/universe) [0.2.3-1 => 0.2.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-base64enc [source] (artful-proposed) [0.1-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-biasedurn [source] (artful-proposed) [1.07-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bms [source] (artful-proposed) [0.3.4-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-ca (artful-proposed/universe) [0.70-1 => 0.70-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-colorspace (artful-proposed/universe) [1.3-2-1 => 1.3-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-beeswarm [source] (artful-proposed) [0.2.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-brew (artful-proposed/universe) [1.0-6-1 => 1.0-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-corpcor (artful-proposed/universe) [1.6.8-3 => 1.6.8-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-blockmodeling [source] (artful-proposed) [0.1.8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-cairo (artful-proposed/universe) [1.5-9-1 => 1.5-9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-brew [source] (artful-proposed) [1.0-6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-cairo [source] (artful-proposed) [1.5-9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-corpcor [source] (artful-proposed) [1.6.8-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-deal (artful-proposed/universe) [1:1.2-37-2 => 1:1.2-37-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-deoptimr (artful-proposed/universe) [1.0-8-1 => 1.0-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ca [source] (artful-proposed) [0.70-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-curl (artful-proposed/universe) [2.8.1-1ubuntu1 => 2.8.1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-colorspace [source] (artful-proposed) [1.3-2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-deldir (artful-proposed/universe) [0.1-12-1 => 0.1-12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-curl [source] (artful-proposed) [2.8.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-deldir [source] (artful-proposed) [0.1-12-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-desolve (artful-proposed/universe) [1.14-1build1 => 1.14-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-ecodist (artful-proposed/universe) [2.0.1-1 => 2.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-deal [source] (artful-proposed) [1:1.2-37-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-digest (artful-proposed/universe) [0.6.12-1 => 0.6.12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-deoptimr [source] (artful-proposed) [1.0-8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-ellipse (artful-proposed/universe) [0.3-8-1 => 0.3-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-desolve [source] (artful-proposed) [1.14-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ecodist [source] (artful-proposed) [2.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-digest [source] (artful-proposed) [0.6.12-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ellipse [source] (artful-proposed) [0.3-8-1build1]
-queuebot:#ubuntu-release- Unapproved: libpng1.6 (artful-proposed/main) [1.6.32-2 => 1.6.32-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: r-cran-epibasix (artful-proposed/universe) [1.3-2 => 1.3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-estimability (artful-proposed/universe) [1.2-1 => 1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-epibasix [source] (artful-proposed) [1.3-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-evd (artful-proposed/universe) [2.3-2-1 => 2.3-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-filehash (artful-proposed/universe) [2.3-1ubuntu1 => 2.3-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-estimability [source] (artful-proposed) [1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-formatr (artful-proposed/universe) [1.4-1 => 1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-fastmatch (artful-proposed/universe) [1.0-4-1 => 1.0-4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-evd [source] (artful-proposed) [2.3-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-filehash [source] (artful-proposed) [2.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: r-cran-formula (artful-proposed/universe) [1.2-2-1 => 1.2-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-geepack (artful-proposed/universe) [1.2-1-1 => 1.2-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-getopt (artful-proposed/universe) [1.20.0-2 => 1.20.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fastmatch [source] (artful-proposed) [1.0-4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-futile.options (artful-proposed/universe) [1.0.0-2 => 1.0.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-formatr [source] (artful-proposed) [1.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-genabel.data (artful-proposed/universe) [1.0.0-1 => 1.0.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-formula [source] (artful-proposed) [1.2-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-geepack [source] (artful-proposed) [1.2-1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-getopt [source] (artful-proposed) [1.20.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gridbase (artful-proposed/universe) [0.4-7-2 => 0.4-7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-hdf5 (artful-proposed/universe) [1.6.10-4build1 => 1.6.10-4build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-futile.options [source] (artful-proposed) [1.0.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-goftest (artful-proposed/universe) [1.0-3-1 => 1.0-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-highr (artful-proposed/universe) [0.6-1 => 0.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-genabel.data [source] (artful-proposed) [1.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gss (artful-proposed/universe) [2.1-7-2 => 2.1-7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-highr [source] (artful-proposed) [0.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-goftest [source] (artful-proposed) [1.0-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gss [source] (artful-proposed) [2.1-7-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-httpcode (artful-proposed/universe) [0.2.0-1 => 0.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-isocodes (artful-proposed/universe) [2016.12.09-1 => 2016.12.09-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gridbase [source] (artful-proposed) [0.4-7-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-int64 (artful-proposed/universe) [1.1.2-4 => 1.1.2-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-hdf5 [source] (artful-proposed) [1.6.10-4build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-iterators (artful-proposed/universe) [1.0.8-1 => 1.0.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-httpcode [source] (artful-proposed) [0.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-isocodes [source] (artful-proposed) [2016.12.09-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-int64 [source] (artful-proposed) [1.1.2-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-iterators [source] (artful-proposed) [1.0.8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gsl (artful-proposed/universe) [1.9-10.3-1ubuntu3 => 1.9-10.3-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gsl [source] (artful-proposed) [1.9-10.3-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: r-cran-jsonlite (artful-proposed/universe) [1.2-1 => 1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-lambda.r (artful-proposed/universe) [1.1.9-1 => 1.1.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-learnbayes (artful-proposed/universe) [2.15-3 => 2.15-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-kernlab (artful-proposed/universe) [0.9-25-1 => 0.9-25-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-lazyeval (artful-proposed/universe) [0.2.0-1 => 0.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-learnbayes [source] (artful-proposed) [2.15-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-jsonlite [source] (artful-proposed) [1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lambda.r [source] (artful-proposed) [1.1.9-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-lhs (artful-proposed/universe) [0.14-1 => 0.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-logspline (artful-proposed/universe) [2.1.9-1 => 2.1.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-kernlab [source] (artful-proposed) [0.9-25-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-listenv (artful-proposed/universe) [0.6.0-1 => 0.6.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lazyeval [source] (artful-proposed) [0.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-lpsolve (artful-proposed/universe) [5.6.13-3 => 5.6.13-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-listenv [source] (artful-proposed) [0.6.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lpsolve [source] (artful-proposed) [5.6.13-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-maldiquant (artful-proposed/universe) [1.16.1-1 => 1.16.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mass (artful-proposed/universe) [7.3-47-1 => 7.3-47-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-logspline [source] (artful-proposed) [2.1.9-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-maps (artful-proposed/universe) [3.1.1-1 => 3.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-magrittr (artful-proposed/universe) [1.5-3build1 => 1.5-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lhs [source] (artful-proposed) [0.14-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maldiquant [source] (artful-proposed) [1.16.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mass [source] (artful-proposed) [7.3-47-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mcmc (artful-proposed/universe) [0.9-4-2 => 0.9-4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mime (artful-proposed/universe) [0.5-1 => 0.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maps [source] (artful-proposed) [3.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-medadherence (artful-proposed/universe) [1.03-2 => 1.03-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-matrixcalc (artful-proposed/universe) [1.0.3-2 => 1.0.3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-minpack.lm (artful-proposed/universe) [1.2-1-1 => 1.2-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-magrittr [source] (artful-proposed) [1.5-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mcmc [source] (artful-proposed) [0.9-4-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mime [source] (artful-proposed) [0.5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mlbench (artful-proposed/universe) [2.1-1-1 => 2.1-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-medadherence [source] (artful-proposed) [1.03-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-modeltools (artful-proposed/universe) [0.2-21-1 => 0.2-21-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-minpack.lm [source] (artful-proposed) [1.2-1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-matrixcalc [source] (artful-proposed) [1.0.3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mlbench [source] (artful-proposed) [2.1-1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-modeltools [source] (artful-proposed) [0.2-21-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-multicore (artful-proposed/universe) [0.2-1 => 0.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-ncdf4 (artful-proposed/universe) [1.15-1build1 => 1.15-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mvnormtest (artful-proposed/universe) [0.1-9-1 => 0.1-9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-nleqslv (artful-proposed/universe) [3.3.1-1 => 3.3.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-multicore [source] (artful-proposed) [0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ncdf4 [source] (artful-proposed) [1.15-1build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-nloptr (artful-proposed/universe) [1.0.4-1 => 1.0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-nnet (artful-proposed/universe) [7.3-12-2 => 7.3-12-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mvnormtest [source] (artful-proposed) [0.1-9-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-nlp (artful-proposed/universe) [0.1-9-1 => 0.1-9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nleqslv [source] (artful-proposed) [3.3.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-nnls (artful-proposed/universe) [1.4-1 => 1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nloptr [source] (artful-proposed) [1.0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nnet [source] (artful-proposed) [7.3-12-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-numderiv (artful-proposed/universe) [2016.8-1-1 => 2016.8-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (artful-proposed/universe) [0.9.6-1 => 0.9.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-pbivnorm (artful-proposed/universe) [0.6.0-1 => 0.6.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nlp [source] (artful-proposed) [0.1-9-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-nws (artful-proposed/universe) [2.0.0.3-4 => 2.0.0.3-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nnls [source] (artful-proposed) [1.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pbapply (artful-proposed/universe) [1.3-1-1 => 1.3-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-numderiv [source] (artful-proposed) [2016.8-1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-openssl [source] (artful-proposed) [0.9.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pbivnorm [source] (artful-proposed) [0.6.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-plogr (artful-proposed/universe) [0.1-1-1 => 0.1-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-png (artful-proposed/universe) [0.1-7-1 => 0.1-7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nws [source] (artful-proposed) [2.0.0.3-4build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pkgkitten (artful-proposed/universe) [0.1.4-1 => 0.1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-polyclip (artful-proposed/universe) [1.5-6-1 => 1.5-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pbapply [source] (artful-proposed) [1.3-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-plotrix (artful-proposed/universe) [3.6-4-1 => 3.6-4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pkgkitten [source] (artful-proposed) [0.1.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-plotrix [source] (artful-proposed) [3.6-4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-polyclip [source] (artful-proposed) [1.5-6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-princurve (artful-proposed/universe) [1.1-12-1 => 1.1-12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-plogr [source] (artful-proposed) [0.1-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-praise (artful-proposed/universe) [1.0.0-1 => 1.0.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-png [source] (artful-proposed) [0.1-7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-praise [source] (artful-proposed) [1.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-princurve [source] (artful-proposed) [1.1-12-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-profilemodel (artful-proposed/universe) [0.5-9-1 => 0.5-9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-psy (artful-proposed/universe) [1.1-2 => 1.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-proto (artful-proposed/universe) [1.0.0-1 => 1.0.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-pwt (artful-proposed/universe) [7.1.1-3 => 7.1.1-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-profilemodel [source] (artful-proposed) [0.5-9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-psy [source] (artful-proposed) [1.1-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pwt8 (artful-proposed/universe) [8.1.1-2 => 8.1.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-qtl (artful-proposed/universe) [1.40-8-1 => 1.40-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-proto [source] (artful-proposed) [1.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pwt9 (artful-proposed/universe) [9.0-0-1 => 9.0-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pwt [source] (artful-proposed) [7.1.1-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-qvcalc (artful-proposed/universe) [0.9-0-1 => 0.9-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-qvcalc [source] (artful-proposed) [0.9-0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pwt8 [source] (artful-proposed) [8.1.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-qtl [source] (artful-proposed) [1.40-8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-r6 (artful-proposed/universe) [2.2.2-1 => 2.2.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-randomforest (artful-proposed/universe) [4.6-12-1 => 4.6-12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pwt9 [source] (artful-proposed) [9.0-0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-randomfieldsutils (artful-proposed/universe) [0.3.25-1 => 0.3.25-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-r.methodss3 (artful-proposed/universe) [1.7.1-1 => 1.7.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-r.methodss3 [source] (artful-proposed) [1.7.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-randomfieldsutils [source] (artful-proposed) [0.3.25-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-raschsampler (artful-proposed/universe) [0.8-8-1build1 => 0.8-8-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-registry (artful-proposed/universe) [0.3-1 => 0.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-repr (artful-proposed/universe) [0.12.0-1 => 0.12.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-r6 [source] (artful-proposed) [2.2.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-readbrukerflexdata (artful-proposed/universe) [1.8.3-1 => 1.8.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-randomforest [source] (artful-proposed) [4.6-12-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rematch (artful-proposed/universe) [1.0.1-1 => 1.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-raschsampler [source] (artful-proposed) [0.8-8-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-registry [source] (artful-proposed) [0.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-repr [source] (artful-proposed) [0.12.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rjsonio (artful-proposed/multiverse) [1.3-0-2 => 1.3-0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-readbrukerflexdata [source] (artful-proposed) [1.8.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rjson (artful-proposed/universe) [0.2.15-1 => 0.2.15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rematch [source] (artful-proposed) [1.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rnetcdf (artful-proposed/universe) [1.8-2-1 => 1.8-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rjson [source] (artful-proposed) [0.2.15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rnetcdf [source] (artful-proposed) [1.8-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rjsonio [source] (artful-proposed) [1.3-0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rniftilib (artful-proposed/universe) [0.0-35.r79-2 => 0.0-35.r79-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rsclient (artful-proposed/universe) [0.7-3-2 => 0.7-3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rsclient [source] (artful-proposed) [0.7-3-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rniftilib [source] (artful-proposed) [0.0-35.r79-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-segmented (artful-proposed/universe) [0.5-1.4-1 => 0.5-1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-shape (artful-proposed/universe) [1.4.2-1 => 1.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-runit (artful-proposed/universe) [0.4.31-2 => 0.4.31-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-seroincidence (artful-proposed/universe) [1.0.5-1 => 1.0.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-shape [source] (artful-proposed) [1.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-runit [source] (artful-proposed) [0.4.31-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-seroincidence [source] (artful-proposed) [1.0.5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-snowballc (artful-proposed/universe) [0.5.1-1 => 0.5.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-spam (artful-proposed/universe) [1.4-0-1build1 => 1.4-0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-segmented [source] (artful-proposed) [0.5-1.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-sourcetools (artful-proposed/universe) [0.1.5-1 => 0.1.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-slam (artful-proposed/universe) [0.1-40-1 => 0.1-40-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-spam [source] (artful-proposed) [1.4-0-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-slam [source] (artful-proposed) [0.1-40-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sourcetools [source] (artful-proposed) [0.1.5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-spatial (artful-proposed/universe) [7.3-11-2 => 7.3-11-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-stabledist (artful-proposed/universe) [0.7-1-1 => 0.7-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-snowballc [source] (artful-proposed) [0.5.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-spc (artful-proposed/universe) [1:0.5.3-1 => 1:0.5.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-sparsem (artful-proposed/universe) [1.77-1 => 1.77-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-statmod (artful-proposed/universe) [1.4.30-1 => 1.4.30-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-statmod [source] (artful-proposed) [1.4.30-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sparsem [source] (artful-proposed) [1.77-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-spc [source] (artful-proposed) [1:0.5.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-stringi (artful-proposed/universe) [1.1.2-1 => 1.1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-testit (artful-proposed/universe) [0.6-1 => 0.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-spatial [source] (artful-proposed) [7.3-11-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-teachingdemos (artful-proposed/universe) [2.10-1 => 2.10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-stabledist [source] (artful-proposed) [0.7-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-timedate (artful-proposed/universe) [3012.100-2 => 3012.100-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-timedate [source] (artful-proposed) [3012.100-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-stringi [source] (artful-proposed) [1.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-testit [source] (artful-proposed) [0.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-teachingdemos [source] (artful-proposed) [2.10-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-truncnorm (artful-proposed/universe) [1.0-7-2 => 1.0-7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-truncnorm [source] (artful-proposed) [1.0-7-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-uuid (artful-proposed/universe) [0.1.2-8 => 0.1.2-8build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-uuid [source] (artful-proposed) [0.1.2-8build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-vgam (artful-proposed/universe) [1.0-3-1 => 1.0-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-withr (artful-proposed/universe) [1.0.2-1 => 1.0.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-viridislite (artful-proposed/universe) [0.2.0-1 => 0.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-xml (artful-proposed/universe) [3.98-1.9-1 => 3.98-1.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-xml [source] (artful-proposed) [3.98-1.9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-vgam [source] (artful-proposed) [1.0-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-withr [source] (artful-proposed) [1.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-yaml (artful-proposed/universe) [2.1.14-1 => 2.1.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-other-iwrlars (artful-proposed/universe) [0.9-5-2 => 0.9-5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-viridislite [source] (artful-proposed) [0.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-other-amsmercury (artful-proposed/universe) [1.3.0-2 => 1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-xtable (artful-proposed/universe) [1:1.8-2-1 => 1:1.8-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: relimp (artful-proposed/universe) [1.0-5-2 => 1.0-5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted relimp [source] (artful-proposed) [1.0-5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-xtable [source] (artful-proposed) [1:1.8-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-other-amsmercury [source] (artful-proposed) [1.3.0-2build1]
-queuebot:#ubuntu-release- Unapproved: rgtk2 (artful-proposed/universe) [2.20.33-1 => 2.20.33-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rmpi (artful-proposed/universe) [0.6-6-4 => 0.6-6-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-yaml [source] (artful-proposed) [2.1.14-1build1]
-queuebot:#ubuntu-release- Unapproved: rjava (artful-proposed/universe) [0.9-8-3 => 0.9-8-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-other-iwrlars [source] (artful-proposed) [0.9-5-2build1]
-queuebot:#ubuntu-release- Unapproved: rodbc (artful-proposed/universe) [1.3-15-1 => 1.3-15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rodbc [source] (artful-proposed) [1.3-15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rgtk2 [source] (artful-proposed) [2.20.33-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rmpi [source] (artful-proposed) [0.6-6-4build1]
-queuebot:#ubuntu-release- Unapproved: rsprng (artful-proposed/universe) [1.0-5 => 1.0-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sm (artful-proposed/universe) [2.2-5.4-2build1 => 2.2-5.4-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rjava [source] (artful-proposed) [0.9-8-3build1]
-queuebot:#ubuntu-release- Unapproved: rsymphony (artful-proposed/universe) [0.1-27-1 => 0.1-27-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rserve (artful-proposed/universe) [1.7-3-3 => 1.7-3-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sm [source] (artful-proposed) [2.2-5.4-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted rserve [source] (artful-proposed) [1.7-3-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted rsymphony [source] (artful-proposed) [0.1-27-1build1]
-queuebot:#ubuntu-release- Unapproved: tkrplot (artful-proposed/universe) [0.0.23-4 => 0.0.23-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rsprng [source] (artful-proposed) [1.0-5build1]
-queuebot:#ubuntu-release- Unapproved: snow (artful-proposed/universe) [1:0.4.2-1 => 1:0.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tkrplot [source] (artful-proposed) [0.0.23-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted snow [source] (artful-proposed) [1:0.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: geary (artful-proposed/universe) [0.12~20170814-0ubuntu1 => 0.12~20170915-0.4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwts (artful-proposed/universe) [17.08.00-0ubuntu1 => 17.09.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (artful-proposed) [17.09.00-0ubuntu1]
<acheronuk> hi. does it matter if something seeded on the ubuntu-studio DVD would be FTBFS is anyone tried to rebuild it?
<acheronuk> i.e. bug #1719792
<ubot5> bug 1719792 in mlt (Ubuntu Artful) "FTBFS in artful with new glibc 2.26 - xlocale.h -> locale.h required" [High,New] https://launchpad.net/bugs/1719792
<acheronuk> or can we leave that to fix later
-queuebot:#ubuntu-release- Unapproved: twisted (artful-proposed/main) [17.5.0-2ubuntu2 => 17.9.0-1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: afnix (artful-proposed/universe) [2.6.3-1 => 2.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted afnix [sync] (artful-proposed) [2.8.0-1]
-queuebot:#ubuntu-release- Unapproved: openhpi (artful-proposed/main) [3.6.1-2.2 => 3.6.1-3] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: adabrowse (artful-proposed/universe) [4.0.3-7ubuntu1 => 4.0.3-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted adabrowse [sync] (artful-proposed) [4.0.3-8]
-queuebot:#ubuntu-release- Unapproved: asis (artful-proposed/universe) [2017-1 => 2017-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted asis [sync] (artful-proposed) [2017-2]
-queuebot:#ubuntu-release- Unapproved: liblog4ada (artful-proposed/universe) [1.3-2 => 1.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted liblog4ada [sync] (artful-proposed) [1.3-3]
-queuebot:#ubuntu-release- Unapproved: ecryptfs-utils (artful-proposed/main) [111-0ubuntu4 => 111-0ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: libaws (artful-proposed/universe) [17.2.2017-1 => 17.2.2017-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libaws [sync] (artful-proposed) [17.2.2017-2]
<cjwatson> https://paste.ubuntu.com/25627072/ - "lp-subscribed-bugs ubuntu-archive"
-queuebot:#ubuntu-release- Unapproved: ceilometer (artful-proposed/main) [1:9.0.0-0ubuntu4 => 1:9.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gdata (artful-proposed/universe) [2.18.0-1 => 2.18.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gdata [source] (artful-proposed) [2.18.0-1build1]
-queuebot:#ubuntu-release- Unapproved: latticeextra (artful-proposed/universe) [0.6-28-2 => 0.6-28-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-biobase (artful-proposed/universe) [2.36.2-1 => 2.36.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kernsmooth (artful-proposed/universe) [2.23-15-3 => 2.23-15-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nlme (artful-proposed/universe) [3.1.131-3 => 3.1.131-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kernsmooth [source] (artful-proposed) [2.23-15-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted nlme [source] (artful-proposed) [3.1.131-3build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-edger (artful-proposed/universe) [3.14.0+dfsg-1 => 3.14.0+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-hilbertvis (artful-proposed/universe) [1.32.0-1 => 1.32.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-bbmle (artful-proposed/universe) [1.0.18-2 => 1.0.18-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted latticeextra [source] (artful-proposed) [0.6-28-2build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-graph (artful-proposed/universe) [1.54.0-1 => 1.54.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biobase [source] (artful-proposed) [2.36.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-s4vectors (artful-proposed/universe) [0.14.3-1 => 0.14.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-graph [source] (artful-proposed) [1.54.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-s4vectors [source] (artful-proposed) [0.14.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-brglm (artful-proposed/universe) [0.5-9-1 => 0.5-9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-catools (artful-proposed/universe) [1.17.1-1 => 1.17.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-hilbertvis [source] (artful-proposed) [1.32.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-calibrate (artful-proposed/universe) [1.7.2-1 => 1.7.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bbmle [source] (artful-proposed) [1.0.18-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-checkmate (artful-proposed/universe) [1.8.2-1 => 1.8.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-edger [source] (artful-proposed) [3.14.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-brglm [source] (artful-proposed) [0.5-9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-catools [source] (artful-proposed) [1.17.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-class (artful-proposed/universe) [7.3-14-2 => 7.3-14-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-contfrac (artful-proposed/universe) [1.1-10-1 => 1.1-10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-dosefinding (artful-proposed/universe) [0.9-15-1 => 0.9-15-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-calibrate [source] (artful-proposed) [1.7.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-coda (artful-proposed/universe) [0.19-1-1 => 0.19-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-checkmate [source] (artful-proposed) [1.8.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-data.table (artful-proposed/universe) [1.10.0-1 => 1.10.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-class [source] (artful-proposed) [7.3-14-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-contfrac [source] (artful-proposed) [1.1-10-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dosefinding [source] (artful-proposed) [0.9-15-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-coda [source] (artful-proposed) [0.19-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-downloader (artful-proposed/universe) [0.4-1 => 0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-data.table [source] (artful-proposed) [1.10.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-downloader [source] (artful-proposed) [0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-eco (artful-proposed/universe) [3.1-7-1 => 3.1-7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-eco [source] (artful-proposed) [3.1-7-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-fields (artful-proposed/universe) [8.10-1ubuntu1 => 8.10-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-futile.logger (artful-proposed/universe) [1.4.3-1 => 1.4.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-elliptic (artful-proposed/universe) [1.3-7-1 => 1.3-7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-foreach (artful-proposed/universe) [1.4.3-1 => 1.4.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-elliptic [source] (artful-proposed) [1.3-7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-foreach [source] (artful-proposed) [1.4.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-genabel (artful-proposed/universe) [1.8-0-1 => 1.8-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-googlevis (artful-proposed/universe) [0.6.2-1 => 0.6.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-hexbin (artful-proposed/universe) [1.27.1-1 => 1.27.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fields [source] (artful-proposed) [8.10-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: r-cran-globals (artful-proposed/universe) [0.8.0-1 => 0.8.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-futile.logger [source] (artful-proposed) [1.4.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gridextra (artful-proposed/universe) [2.2.1-1 => 2.2.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-genabel [source] (artful-proposed) [1.8-0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-googlevis [source] (artful-proposed) [0.6.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-hexbin [source] (artful-proposed) [1.27.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-lavaan (artful-proposed/universe) [0.5.22-1 => 0.5.22-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mapproj (artful-proposed/universe) [1.2-4-1 => 1.2-4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-globals [source] (artful-proposed) [0.8.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-httr (artful-proposed/universe) [1.2.1-1 => 1.2.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gridextra [source] (artful-proposed) [2.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mapdata (artful-proposed/universe) [2.2-6-1 => 2.2-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mapproj [source] (artful-proposed) [1.2-4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-httr [source] (artful-proposed) [1.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mapdata [source] (artful-proposed) [2.2-6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-matrixstats (artful-proposed/universe) [0.52.2-1 => 0.52.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mixtools (artful-proposed/universe) [1.0.4-1 => 1.0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lavaan [source] (artful-proposed) [0.5.22-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-memoise (artful-proposed/universe) [1.0.0-1 => 1.0.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-markdown (artful-proposed/universe) [0.7.7-1 => 0.7.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mixtools [source] (artful-proposed) [1.0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted ecryptfs-utils [source] (artful-proposed) [111-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-matrixstats [source] (artful-proposed) [0.52.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mnp (artful-proposed/universe) [2.6-4-1 => 2.6-4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: s390-dasd (artful-proposed/main) [0.0.45ubuntu1 => 0.0.45ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-markdown [source] (artful-proposed) [0.7.7-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-munsell (artful-proposed/universe) [0.4.3-1 => 0.4.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-memoise [source] (artful-proposed) [1.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-munsell [source] (artful-proposed) [0.4.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mnp [source] (artful-proposed) [2.6-4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-optparse (artful-proposed/universe) [1.3.2-1 => 1.3.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-pbdzmq (artful-proposed/universe) [0.2.6+dfsg-1 => 0.2.6+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-optparse [source] (artful-proposed) [1.3.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pbdzmq [source] (artful-proposed) [0.2.6+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: mlt (artful-proposed/universe) [6.4.1-5ubuntu1 => 6.4.1-5ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: r-cran-r.oo (artful-proposed/universe) [1.21.0-1 => 1.21.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-prettyunits (artful-proposed/universe) [1.0.2-1 => 1.0.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rcurl (artful-proposed/universe) [1.95-4.8-2 => 1.95-4.8-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcurl [source] (artful-proposed) [1.95-4.8-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-prettyunits [source] (artful-proposed) [1.0.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-readmzxmldata (artful-proposed/universe) [2.8.1-1 => 2.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rsolnp (artful-proposed/universe) [1.16+dfsg-1 => 1.16+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-seqinr (artful-proposed/universe) [3.3-3-1 => 3.3-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-r.oo [source] (artful-proposed) [1.21.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-sendmailr (artful-proposed/universe) [1.2-1-1 => 1.2-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rpostgresql (artful-proposed/universe) [0.4-1 => 0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-seqinr [source] (artful-proposed) [3.3-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-readmzxmldata [source] (artful-proposed) [2.8.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rsolnp [source] (artful-proposed) [1.16+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-sn (artful-proposed/universe) [1.5-0-1 => 1.5-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-stringr (artful-proposed/universe) [1.1.0-1 => 1.1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rpostgresql [source] (artful-proposed) [0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-sp (artful-proposed/universe) [1:1.2-5-2 => 1:1.2-5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sendmailr [source] (artful-proposed) [1.2-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tikzdevice (artful-proposed/universe) [0.10-1-1 => 0.10-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-stringr [source] (artful-proposed) [1.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-timeseries (artful-proposed/universe) [3022.101.2-2 => 3022.101.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-vioplot (artful-proposed/universe) [0.2-2 => 0.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tikzdevice [source] (artful-proposed) [0.10-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-other-mott-happy (artful-proposed/universe) [2.4-1 => 2.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-tm (artful-proposed/universe) [0.6-2-3 => 0.6-2-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sn [source] (artful-proposed) [1.5-0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-other-nitpick (artful-proposed/universe) [2.0-2 => 2.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sp [source] (artful-proposed) [1:1.2-5-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tm [source] (artful-proposed) [0.6-2-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-other-mott-happy [source] (artful-proposed) [2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-zoo (artful-proposed/universe) [1.8-0-1 => 1.8-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rggobi (artful-proposed/universe) [2.1.21-2 => 2.1.21-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-vioplot [source] (artful-proposed) [0.2-2build1]
-queuebot:#ubuntu-release- Unapproved: rcpp (artful-proposed/universe) [0.12.12-1 => 0.12.12-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-other-nitpick [source] (artful-proposed) [2.0-2build1]
-queuebot:#ubuntu-release- Unapproved: rglpk (artful-proposed/universe) [0.6-3-1 => 0.6-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-timeseries [source] (artful-proposed) [3022.101.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-zoo [source] (artful-proposed) [1.8-0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rggobi [source] (artful-proposed) [2.1.21-2build1]
-queuebot:#ubuntu-release- Unapproved: rmatrix (artful-proposed/universe) [1.2-11-1 => 1.2-11-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: robustbase (artful-proposed/universe) [0.92-7-2 => 0.92-7-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rcpp [source] (artful-proposed) [0.12.12-1build1]
-queuebot:#ubuntu-release- Unapproved: rmysql (artful-proposed/universe) [0.10.13-1 => 0.10.13-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rglpk [source] (artful-proposed) [0.6-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rmatrix [source] (artful-proposed) [1.2-11-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted robustbase [source] (artful-proposed) [0.92-7-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted rmysql [source] (artful-proposed) [0.10.13-1build1]
-queuebot:#ubuntu-release- Unapproved: nova (artful-proposed/main) [2:16.0.0-0ubuntu2 => 2:16.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.0-0ubuntu1 => 2:11.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mutter (artful-proposed/main) [3.26.0+20170925~ea214fb-1 => 3.26.0+20170925~ea214fb-1ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (artful-proposed/main) [1:11.0.0-0ubuntu1 => 1:11.0.1-0ubuntu1] (openstack, ubuntu-server)
<xnox> sil2100, could you please review https://launchpad.net/ubuntu/artful/+queue?queue_state=1&queue_text=s390-dasd ?
<xnox> sil2100, then after it is built, we will retest it with frank and if all is good we will need s390x server iso only respin
<sil2100> tsimonq2: I just kicked the alternate images for lubuntu, I didn't do it before since I was actually planning yet another re-spin - but now I'm not sure about that anymore
<sil2100> xnox: oh, uh, ok, let me take a look
-queuebot:#ubuntu-release- Unapproved: accepted s390-dasd [source] (artful-proposed) [0.0.45ubuntu2]
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Final Beta] (20170927) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Final Beta] (20170927) has been added
-queuebot:#ubuntu-release- Unapproved: r-cran-rcppgsl (artful-proposed/universe) [0.3.2-2ubuntu2 => 0.3.2-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcppgsl [source] (artful-proposed) [0.3.2-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected libpng1.6 [sync] (artful-proposed) [1.6.32-3]
-queuebot:#ubuntu-release- Unapproved: accepted openhpi [sync] (artful-proposed) [3.6.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [sync] (artful-proposed) [17.9.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libpng1.6 [sync] (artful-proposed) [1.6.32-3]
-queuebot:#ubuntu-release- Unapproved: accepted slof [sync] (artful-proposed) [20170724+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (artful-proposed) [17.10.6]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (artful-proposed) [1:9.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (artful-proposed) [1:11.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (artful-proposed) [2:16.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-check.v1 [source] (artful-proposed) [0.0+git20161208.0.20d25e2-1build1]
<flocculant> fossfreedom: saw your comment on Auto selected keyboard layout - that'll be why I thought the encrypt password bug had mysteriously fixed itself :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (artful-proposed/universe) [17.10.1 => 17.10.2] (ubuntugnome)
<jbicha> please reject ubutnu-gnome-default-settings, I'm uploading a better version in a moment ^
-queuebot:#ubuntu-release- Unapproved: ubiquity (artful-proposed/main) [17.10.7 => 17.10.8] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (artful-proposed/universe) [17.10.1 => 17.10.2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (artful-proposed/universe) [0.78 => 0.79] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: libhdhomerun (artful-proposed/universe) [20170815-1 => 20170815-2] (mythbuntu) (sync)
<jbicha> libhdhomerun sync is for LP: #1719360
<ubot5> Launchpad bug 1719360 in libhdhomerun (Ubuntu) "libhdhomerun ABI breakage" [Undecided,New] https://launchpad.net/bugs/1719360
-queuebot:#ubuntu-release- Unapproved: foolscap (artful-proposed/universe) [0.12.6-1 => 0.12.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted foolscap [source] (artful-proposed) [0.12.7-0ubuntu1]
 * sil2100 pokes flexiondotorg with a reminder about release notes for mate
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.4.11-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python3-defaults (artful-proposed/main) [3.6.2-1ubuntu3 => 3.6.2-1ubuntu4] (core)
<slangasek> ginggs: was there an FFe discussion about this r-base transition that's just been started and seems to cause the whole R stack to regress its autopkgtests?
<ginggs> slangasek: yup, LP: #1719245
<ubot5> Launchpad bug 1719245 in r-base (Debian) "FFe: Sync r-base 3.4.1.20170921-1 (universe) from Debian unstable (main)" [Unknown,New] https://launchpad.net/bugs/1719245
<ginggs> slangasek: they'll start to pass once we get further down the dependency levels
<slangasek> k
-queuebot:#ubuntu-release- Unapproved: mgltools-networkeditor (artful-proposed/multiverse) [1.5.7-1 => 1.5.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mgltools-vision (artful-proposed/multiverse) [1.5.7-1 => 1.5.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mgltools-viewerframework (artful-proposed/multiverse) [1.5.7-1 => 1.5.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (artful-proposed) [3.6.2-1ubuntu4]
<sil2100> tsimonq2: hey, how's the lubuntu release notes are going for final beta? :)
-queuebot:#ubuntu-release- Unapproved: accepted mgltools-networkeditor [source] (artful-proposed) [1.5.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mgltools-vision [source] (artful-proposed) [1.5.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mgltools-viewerframework [source] (artful-proposed) [1.5.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-7ubuntu1 => 7.2.0-7ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted mlt [source] (artful-proposed) [6.4.1-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cairo [source] (artful-proposed) [1.14.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (artful-proposed) [1:3.26.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted libhdhomerun [sync] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (artful-proposed) [7.2.0-7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (artful-proposed) [3.26.0+20170925~ea214fb-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (artful-proposed) [3.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New binary: libhdhomerun [ppc64el] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-meta [ppc64el] (artful-proposed/universe) [0.79] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libhdhomerun [s390x] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: libhdhomerun [amd64] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-meta [amd64] (artful-proposed/universe) [0.79] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-default-settings [amd64] (artful-proposed/universe) [17.10.2] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-meta [i386] (artful-proposed/universe) [0.79] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libhdhomerun [i386] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-meta [arm64] (artful-proposed/universe) [0.79] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-7ubuntu1 => 7.2.0-7ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: libhdhomerun [armhf] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- New binary: ubuntu-gnome-meta [armhf] (artful-proposed/universe) [0.79] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [source] (artful-proposed) [7.2.0-7ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-gnome-default-settings [source] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- New binary: libhdhomerun [arm64] (artful-proposed/universe) [20170815-2] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-7ubuntu2 => 7.2.0-7ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (artful-proposed) [7.2.0-7ubuntu3]
<tsimonq2> sil2100: Oh yeah, heh, I should probably work on those...
<tsimonq2> (I usually procrastinate... yeah maybe not this time? :) )
<sil2100> No new re-spins planned for now, so would be good to get ready for tomorrow!
<tsimonq2> Probably ;)
<sil2100> Whoops
<flocculant> that sounds ominous ...
<flocculant> :)
-queuebot:#ubuntu-release- Builds: 37 entries have been added, updated or disabled
-queuebot:#ubuntu-release- Unapproved: apport (artful-proposed/main) [2.20.7-0ubuntu1 => 2.20.7-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.0.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<flexiondotorg> sil2100: The release notes are ready. I'll publish when the isos are released.
<flexiondotorg> I'll pu the link in the wiki later.
#ubuntu-release 2017-09-28
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-7ubuntu3 => 7.2.0-7ubuntu4] (core)
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-default-settings [amd64] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-meta [amd64] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-meta [armhf] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-meta [ppc64el] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-meta [arm64] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New: accepted ubuntu-gnome-meta [i386] (artful-proposed) [0.79]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [amd64] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [armhf] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [ppc64el] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [arm64] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [s390x] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- New: accepted libhdhomerun [i386] (artful-proposed) [20170815-2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (artful-proposed) [7.2.0-7ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (artful-proposed) [3.26.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Beta 2] has been marked as ready
<infinity1> slangasek: It was implied that the twisted fix was in progress.  If that's not entirely true, we should re-evaluate.
<slangasek> infinity1: if it's in progress, it's a slow and staid progression
<infinity1> slangasek: Indeed.
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: dlib (artful-proposed/universe) [18.18-2 => 18.18-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dlib [source] (artful-proposed) [18.18-2build1]
-queuebot:#ubuntu-release- Unapproved: fbasics (artful-proposed/universe) [3011.87-3 => 3011.87-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fimport (artful-proposed/universe) [3000.82-3 => 3000.82-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fbasics [source] (artful-proposed) [3011.87-3build1]
-queuebot:#ubuntu-release- Unapproved: gplots (artful-proposed/universe) [3.0.1-2 => 3.0.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fimport [source] (artful-proposed) [3000.82-3build1]
-queuebot:#ubuntu-release- Unapproved: lmtest (artful-proposed/universe) [0.9.35-2 => 0.9.35-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mgcv (artful-proposed/universe) [1.8-18-1 => 1.8-18-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-affy (artful-proposed/universe) [1.52.0-1 => 1.52.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mgcv [source] (artful-proposed) [1.8-18-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-hypergraph (artful-proposed/universe) [1.48.0-1 => 1.48.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-rbgl (artful-proposed/universe) [1.50.0+dfsg1-1 => 1.50.0+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-affy [source] (artful-proposed) [1.52.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-iranges (artful-proposed/universe) [2.10.2-1 => 2.10.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gplots [source] (artful-proposed) [3.0.1-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-adegraphics (artful-proposed/universe) [1.0-6-1ubuntu1 => 1.0-6-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lmtest [source] (artful-proposed) [0.9.35-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-rbgl [source] (artful-proposed) [1.50.0+dfsg1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-ape (artful-proposed/universe) [4.1-2 => 4.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-adegraphics [source] (artful-proposed) [1.0-6-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: r-cran-bbmisc (artful-proposed/universe) [1.10-1 => 1.10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-hypergraph [source] (artful-proposed) [1.48.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-bio3d (artful-proposed/universe) [2.3-1-1 => 2.3-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-iranges [source] (artful-proposed) [2.10.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-crayon (artful-proposed/universe) [1.3.2-1 => 1.3.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bio3d [source] (artful-proposed) [2.3-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-cubature (artful-proposed/universe) [1.3-11-1 => 1.3-11-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-crayon [source] (artful-proposed) [1.3.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-domc (artful-proposed/universe) [1.3.4-1 => 1.3.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ape [source] (artful-proposed) [4.1-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-doparallel (artful-proposed/universe) [1.0.10-3 => 1.0.10-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bbmisc [source] (artful-proposed) [1.10-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-dosnow (artful-proposed/universe) [1.0.14-1 => 1.0.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-doparallel [source] (artful-proposed) [1.0.10-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-e1071 (artful-proposed/universe) [1.6-8-2 => 1.6-8-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dosnow [source] (artful-proposed) [1.0.14-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-energy (artful-proposed/universe) [1.7-0-2 => 1.7-0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-cubature [source] (artful-proposed) [1.3-11-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-domc [source] (artful-proposed) [1.3.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-e1071 [source] (artful-proposed) [1.6-8-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-energy [source] (artful-proposed) [1.7-0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-erm (artful-proposed/universe) [0.15-7-1build1 => 0.15-7-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-expm (artful-proposed/universe) [0.999-0-1build1 => 0.999-0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-evaluate (artful-proposed/universe) [0.10-1 => 0.10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-fitbitscraper (artful-proposed/universe) [0.1.8-2 => 0.1.8-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-future (artful-proposed/universe) [1.2.0-1 => 1.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-expm [source] (artful-proposed) [0.999-0-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-future [source] (artful-proposed) [1.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-glmnet (artful-proposed/universe) [2.0-5-1build1 => 2.0-5-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fitbitscraper [source] (artful-proposed) [0.1.8-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gnm (artful-proposed/universe) [1.0-8-1 => 1.0-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-gam (artful-proposed/universe) [1.14-1 => 1.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-erm [source] (artful-proposed) [0.15-7-1build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-htmltools (artful-proposed/universe) [0.3.5-2 => 0.3.5-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-evaluate [source] (artful-proposed) [0.10-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-glmnet [source] (artful-proposed) [2.0-5-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-htmltools [source] (artful-proposed) [0.3.5-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-hypergeo (artful-proposed/universe) [1.2-13-1 => 1.2-13-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gnm [source] (artful-proposed) [1.0-8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-irlba (artful-proposed/universe) [2.1.2-1 => 2.1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-httpuv (artful-proposed/universe) [1.3.3-3 => 1.3.3-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gam [source] (artful-proposed) [1.14-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-lubridate (artful-proposed/universe) [1.6.0-1build1 => 1.6.0-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-hypergeo [source] (artful-proposed) [1.2-13-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lubridate [source] (artful-proposed) [1.6.0-1build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-maptools (artful-proposed/multiverse) [1:0.8-41+dfsg-1 => 1:0.8-41+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-minqa (artful-proposed/universe) [1.2.4-1 => 1.2.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-irlba [source] (artful-proposed) [2.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-matrixmodels (artful-proposed/universe) [0.4-1-1 => 0.4-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-maldiquantforeign (artful-proposed/universe) [0.10.1-1 => 0.10.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-httpuv [source] (artful-proposed) [1.3.3-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-modelmetrics (artful-proposed/universe) [1.1.0-1 => 1.1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-matrixmodels [source] (artful-proposed) [0.4-1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-modelmetrics [source] (artful-proposed) [1.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-plyr (artful-proposed/universe) [1.8.4-1 => 1.8.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-qqman (artful-proposed/universe) [0.1.4-2 => 0.1.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-minqa [source] (artful-proposed) [1.2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-progress (artful-proposed/universe) [1.1.2-1 => 1.1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-pkgmaker (artful-proposed/universe) [0.22-1 => 0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maldiquantforeign [source] (artful-proposed) [0.10.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-r.utils (artful-proposed/universe) [2.5.0-1 => 2.5.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maptools [source] (artful-proposed) [1:0.8-41+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-progress [source] (artful-proposed) [1.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-r.utils [source] (artful-proposed) [2.5.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-raster (artful-proposed/universe) [2.5-8-1 => 2.5-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-qqman [source] (artful-proposed) [0.1.4-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rcpparmadillo (artful-proposed/universe) [0.7.960.1.1-1 => 0.7.960.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-randomfields (artful-proposed/universe) [3.1.36-1 => 3.1.36-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pkgmaker [source] (artful-proposed) [0.22-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-plyr [source] (artful-proposed) [1.8.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-randomfields [source] (artful-proposed) [3.1.36-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcpparmadillo [source] (artful-proposed) [0.7.960.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-raster [source] (artful-proposed) [2.5-8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rcppeigen (artful-proposed/universe) [0.3.3.3.0-1 => 0.3.3.3.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcppeigen [source] (artful-proposed) [0.3.3.3.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rentrez (artful-proposed/universe) [1.0.4-1 => 1.0.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rjags (artful-proposed/universe) [1:4-6-1 => 1:4-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rinside (artful-proposed/universe) [0.2.14-1 => 0.2.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rneos (artful-proposed/universe) [0.3-2-1 => 0.3-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rentrez [source] (artful-proposed) [1.0.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rjags [source] (artful-proposed) [1:4-6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rprotobuf (artful-proposed/universe) [0.4.8-1 => 0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-semtools (artful-proposed/universe) [0.4.14-1 => 0.4.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rinside [source] (artful-proposed) [0.2.14-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rsqlite (artful-proposed/universe) [1.1-2-1 => 1.1-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rneos [source] (artful-proposed) [0.3-2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tibble (artful-proposed/universe) [1.2-1 => 1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-triebeard (artful-proposed/universe) [0.3.0-1 => 0.3.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rsqlite [source] (artful-proposed) [1.1-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tibble [source] (artful-proposed) [1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-ttr (artful-proposed/universe) [0.23-2-1 => 0.23-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-xml2 (artful-proposed/universe) [1.1.0-1ubuntu1 => 1.1.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-semtools [source] (artful-proposed) [0.4.14-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-v8 (artful-proposed/universe) [1.3-1 => 1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-triebeard [source] (artful-proposed) [0.3.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-other-curvefdp (artful-proposed/universe) [2.0-2 => 2.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rprotobuf [source] (artful-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ttr [source] (artful-proposed) [0.23-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-xml2 [source] (artful-proposed) [1.1.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: sandwich (artful-proposed/universe) [2.4-0-1 => 2.4-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: urca (artful-proposed/universe) [1.3-0-2 => 1.3-0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-v8 [source] (artful-proposed) [1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: survival (artful-proposed/universe) [2.41-3-2 => 2.41-3-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-other-curvefdp [source] (artful-proposed) [2.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted sandwich [source] (artful-proposed) [2.4-0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted urca [source] (artful-proposed) [1.3-0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted survival [source] (artful-proposed) [2.41-3-2build1]
<acheronuk> any release team about?
<acheronuk> on beta2 iso testing, I am failing test cases on bug #1706859
<ubot5> bug 1706859 in ubiquity (Ubuntu) "Auto-selected keyboard layout no longer matches chosen region on "Where are you" page" [Undecided,Confirmed] https://launchpad.net/bugs/1706859
<acheronuk> I did not fail that on previous release testing, but it has regressed further
<acheronuk> there is a ubiquity update in the unapproved queue from cyphermox, which apparently fixes bug #1719908
<ubot5> bug 1719908 in ubiquity (Ubuntu Artful) "Keyboard step - Keyboard layout not applied when layout is selected" [Undecided,New] https://launchpad.net/bugs/1719908
<acheronuk> howevever, I'm not sure if even that would help on the other bug
<acheronuk> building the source in unapproved to check
<acheronuk> nope. doesn't fix my bug
-queuebot:#ubuntu-release- Unapproved: dichromat (artful-proposed/universe) [2.0.0-3 => 2.0.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-combinat (artful-proposed/universe) [0.0-8-4 => 0.0-8-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dichromat [source] (artful-proposed) [2.0.0-3build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-epitools (artful-proposed/universe) [1:0.5-7-1build1 => 1:0.5-7-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-genetics (artful-proposed/universe) [1.3.8.1-1 => 1.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-combinat [source] (artful-proposed) [0.0-8-4build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-gmaps (artful-proposed/universe) [0.2-2 => 0.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-g.data (artful-proposed/universe) [2.4-1 => 2.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-hwriter (artful-proposed/universe) [1.3.2-1 => 1.3.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gmaps [source] (artful-proposed) [0.2-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-inline (artful-proposed/universe) [0.3.14-1 => 0.3.14-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mfilter (artful-proposed/universe) [0.1.3-1 => 0.1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-hwriter [source] (artful-proposed) [1.3.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-labeling (artful-proposed/universe) [0.3-1 => 0.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-epitools [source] (artful-proposed) [1:0.5-7-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-genetics [source] (artful-proposed) [1.3.8.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-g.data [source] (artful-proposed) [2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-misctools (artful-proposed/universe) [0.6-16-1 => 0.6-16-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-inline [source] (artful-proposed) [0.3.14-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mfilter [source] (artful-proposed) [0.1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tcltk2 (artful-proposed/universe) [1.2-11-1 => 1.2-11-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-wdi (artful-proposed/universe) [2.4-1 => 2.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rcolorbrewer (artful-proposed/universe) [1.1-2-1 => 1.1-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-labeling [source] (artful-proposed) [0.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tensor (artful-proposed/universe) [1.5-1 => 1.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-misctools [source] (artful-proposed) [0.6-16-1build1]
-queuebot:#ubuntu-release- Unapproved: r-omegahat-xmlrpc (artful-proposed/universe) [0.3-0-1 => 0.3-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tcltk2 [source] (artful-proposed) [1.2-11-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-wdi [source] (artful-proposed) [2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rcolorbrewer [source] (artful-proposed) [1.1-2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tensor [source] (artful-proposed) [1.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-omegahat-xmlrpc [source] (artful-proposed) [0.3-0-1build1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: rpart (artful-proposed/universe) [4.1-11-1 => 4.1-11-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rpart [source] (artful-proposed) [4.1-11-1build1]
-queuebot:#ubuntu-release- Unapproved: fbonds (artful-proposed/universe) [3010.77-2 => 3010.77-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fgarch (artful-proposed/universe) [3010.82.1-2 => 3010.82.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fbonds [source] (artful-proposed) [3010.77-2build1]
-queuebot:#ubuntu-release- Unapproved: fmultivar (artful-proposed/universe) [3011.78-2 => 3011.78-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ftrading (artful-proposed/universe) [3010.78-2 => 3010.78-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gmodels (artful-proposed/universe) [2.16.2-2 => 2.16.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fgarch [source] (artful-proposed) [3010.82.1-2build1]
-queuebot:#ubuntu-release- Unapproved: funitroots (artful-proposed/universe) [3010.78-3 => 3010.78-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: foptions (artful-proposed/universe) [3022.85-3 => 3022.85-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fmultivar [source] (artful-proposed) [3011.78-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted ftrading [source] (artful-proposed) [3010.78-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted gmodels [source] (artful-proposed) [2.16.2-2build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-aroma.light (artful-proposed/universe) [3.6.0-1 => 3.6.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-delayedarray (artful-proposed/universe) [0.2.7-1 => 0.2.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted foptions [source] (artful-proposed) [3022.85-3build1]
-queuebot:#ubuntu-release- Unapproved: lme4 (artful-proposed/universe) [1.1-13-1build1 => 1.1-13-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted funitroots [source] (artful-proposed) [3010.78-3build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biomformat (artful-proposed/universe) [1.2.0-1 => 1.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lme4 [source] (artful-proposed) [1.1-13-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biomformat [source] (artful-proposed) [1.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomeinfodb (artful-proposed/universe) [1.12.2-1 => 1.12.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-metagenomeseq (artful-proposed/universe) [1.16.0-2 => 1.16.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-aroma.light [source] (artful-proposed) [3.6.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-makecdfenv (artful-proposed/universe) [1.50.0-1 => 1.50.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-delayedarray [source] (artful-proposed) [0.2.7-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-multtest (artful-proposed/universe) [2.32.0-1 => 2.32.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomeinfodb [source] (artful-proposed) [1.12.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-metagenomeseq [source] (artful-proposed) [1.16.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-snpstats (artful-proposed/universe) [1.24.0+dfsg-1 => 1.24.0+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-amelia (artful-proposed/universe) [1.7.4-1 => 1.7.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-makecdfenv [source] (artful-proposed) [1.50.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-xvector (artful-proposed/universe) [0.16.0-1 => 0.16.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-multtest [source] (artful-proposed) [2.32.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-bayesfactor (artful-proposed/universe) [0.9.12-2-2 => 0.9.12-2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-snpstats [source] (artful-proposed) [1.24.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-amelia [source] (artful-proposed) [1.7.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-bayesm (artful-proposed/universe) [3.0-2-2 => 3.0-2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-cmprsk (artful-proposed/universe) [2.2-7-2build1 => 2.2-7-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-xvector [source] (artful-proposed) [0.16.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-cellranger (artful-proposed/universe) [1.1.0-1 => 1.1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bayesfactor [source] (artful-proposed) [0.9.12-2-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-distory (artful-proposed/universe) [1.4.2-1 => 1.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bayesm [source] (artful-proposed) [3.0-2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-cmprsk [source] (artful-proposed) [2.2-7-2build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-dplyr (artful-proposed/universe) [0.5.0-1ubuntu2 => 0.5.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-etm (artful-proposed/universe) [0.6-2-3build1 => 0.6-2-3build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-cellranger [source] (artful-proposed) [1.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-epicalc (artful-proposed/universe) [2.15.1.0-2 => 2.15.1.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-distory [source] (artful-proposed) [1.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dplyr [source] (artful-proposed) [0.5.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-etm [source] (artful-proposed) [0.6-2-3build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-epicalc [source] (artful-proposed) [2.15.1.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-fail (artful-proposed/universe) [1.3-1 => 1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fail [source] (artful-proposed) [1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-htmlwidgets (artful-proposed/universe) [0.8-1 => 0.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-maxlik (artful-proposed/universe) [1.3-4-1 => 1.3-4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-gbm (artful-proposed/universe) [2.1.1-1 => 2.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-knitr (artful-proposed/universe) [1.15.1-2 => 1.15.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gbm [source] (artful-proposed) [2.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-knitr [source] (artful-proposed) [1.15.1-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-msm (artful-proposed/universe) [1.6.4-1 => 1.6.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-quantreg (artful-proposed/universe) [5.33-2build1 => 5.33-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-reshape (artful-proposed/universe) [0.8.6-1 => 0.8.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-htmlwidgets [source] (artful-proposed) [0.8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-quantmod (artful-proposed/universe) [0.4-10-1 => 0.4-10-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maxlik [source] (artful-proposed) [1.3-4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-r.cache (artful-proposed/universe) [0.12.0-2 => 0.12.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-msm [source] (artful-proposed) [1.6.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-quantreg [source] (artful-proposed) [5.33-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-reshape [source] (artful-proposed) [0.8.6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rncl (artful-proposed/universe) [0.8.2-1 => 0.8.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rocr (artful-proposed/universe) [1.0-7-2build1 => 1.0-7-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-quantmod [source] (artful-proposed) [0.4-10-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-reshape2 (artful-proposed/universe) [1.4.2-1 => 1.4.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-r.cache [source] (artful-proposed) [0.12.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rngtools (artful-proposed/universe) [1.2.4-2 => 1.2.4-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-reshape2 [source] (artful-proposed) [1.4.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rngtools [source] (artful-proposed) [1.2.4-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rsdmx (artful-proposed/universe) [0.5.9+dfsg-1 => 0.5.9+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-shiny (artful-proposed/universe) [1.0.0+dfsg-1 => 1.0.0+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rncl [source] (artful-proposed) [0.8.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-scales (artful-proposed/universe) [0.4.1-1 => 0.4.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rocr [source] (artful-proposed) [1.0-7-2build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-survey (artful-proposed/universe) [3.31-5-1 => 3.31-5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rsdmx [source] (artful-proposed) [0.5.9+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-shiny [source] (artful-proposed) [1.0.0+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-testthat (artful-proposed/universe) [1.0.2-2 => 1.0.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-urltools (artful-proposed/universe) [1.6.0-1 => 1.6.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-scales [source] (artful-proposed) [0.4.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-th.data (artful-proposed/universe) [1.0-8-1 => 1.0-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-survey [source] (artful-proposed) [3.31-5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-vcd (artful-proposed/universe) [1:1.4-3-1 => 1:1.4-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-testthat [source] (artful-proposed) [1.0.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-urltools [source] (artful-proposed) [1.6.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-vegan (artful-proposed/universe) [2.4-2-1build1 => 2.4-2-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-th.data [source] (artful-proposed) [1.0-8-1build1]
-queuebot:#ubuntu-release- Unapproved: strucchange (artful-proposed/universe) [1.5-1-2 => 1.5-1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-vcd [source] (artful-proposed) [1:1.4-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-vegan [source] (artful-proposed) [2.4-2-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted strucchange [source] (artful-proposed) [1.5-1-2build1]
-queuebot:#ubuntu-release- Unapproved: matchit (artful-proposed/universe) [2.4-21-1 => 2.4-21-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted matchit [source] (artful-proposed) [2.4-21-1build1]
-queuebot:#ubuntu-release- Unapproved: zelig (artful-proposed/universe) [4.2-1-1 => 4.2-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zelig [source] (artful-proposed) [4.2-1-1build1]
-queuebot:#ubuntu-release- Unapproved: effects (artful-proposed/universe) [3.1.2-1 => 3.1.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted effects [source] (artful-proposed) [3.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: fassets (artful-proposed/universe) [3011.83-2 => 3011.83-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fasianoptions (artful-proposed/universe) [3010.79-3 => 3010.79-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fcopulae (artful-proposed/universe) [3011.81-2 => 3011.81-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fexoticoptions (artful-proposed/universe) [2152.78-3 => 2152.78-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fextremes (artful-proposed/universe) [3010.81-2 => 3010.81-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fassets [source] (artful-proposed) [3011.83-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted fexoticoptions [source] (artful-proposed) [2152.78-3build1]
-queuebot:#ubuntu-release- Unapproved: fnonlinear (artful-proposed/universe) [3010.78-3 => 3010.78-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: multcomp (artful-proposed/universe) [1.4-6-1 => 1.4-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fcopulae [source] (artful-proposed) [3011.81-2build1]
-queuebot:#ubuntu-release- Unapproved: fregression (artful-proposed/universe) [3011.81-2 => 3011.81-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fextremes [source] (artful-proposed) [3010.81-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted fasianoptions [source] (artful-proposed) [3010.79-3build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-annotationdbi (artful-proposed/universe) [1.36.1-2 => 1.36.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fregression [source] (artful-proposed) [3011.81-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-annotationdbi [source] (artful-proposed) [1.36.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted multcomp [source] (artful-proposed) [1.4-6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biostrings (artful-proposed/universe) [2.44.0-1 => 2.44.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fnonlinear [source] (artful-proposed) [3010.78-3build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomicranges (artful-proposed/universe) [1.28.2-1 => 1.28.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-ebseq (artful-proposed/universe) [1.14.0-1 => 1.14.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-interactivedisplaybase (artful-proposed/universe) [1.12.0-1 => 1.12.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-ebseq [source] (artful-proposed) [1.14.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-interactivedisplaybase [source] (artful-proposed) [1.12.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomicranges [source] (artful-proposed) [1.28.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-arm (artful-proposed/universe) [1.9-3-1 => 1.9-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biostrings [source] (artful-proposed) [2.44.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-bold (artful-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-batchjobs (artful-proposed/universe) [1.6-1 => 1.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-bradleyterry2 (artful-proposed/universe) [1.0-6-1 => 1.0-6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-batchjobs [source] (artful-proposed) [1.6-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bradleyterry2 [source] (artful-proposed) [1.0-6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-dbitest (artful-proposed/universe) [1.4-1 => 1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-epi (artful-proposed/universe) [2.7-1 => 2.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-bold [source] (artful-proposed) [0.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-diagnosismed (artful-proposed/universe) [0.2.3-4 => 0.2.3-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-crul (artful-proposed/universe) [0.2.0-1 => 0.2.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-arm [source] (artful-proposed) [1.9-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dbitest [source] (artful-proposed) [1.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-epi [source] (artful-proposed) [2.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-diagnosismed [source] (artful-proposed) [0.2.3-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-crul [source] (artful-proposed) [0.2.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-ggplot2 (artful-proposed/universe) [2.2.1-2 => 2.2.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-maptree (artful-proposed/universe) [1.4-7-1 => 1.4-7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-htmltable (artful-proposed/universe) [1.9-1 => 1.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-mcmcpack (artful-proposed/universe) [1.3-8-1 => 1.3-8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ggplot2 [source] (artful-proposed) [2.2.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-maptree [source] (artful-proposed) [1.4-7-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-miniui (artful-proposed/universe) [0.1.1-1 => 0.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-htmltable [source] (artful-proposed) [1.9-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mlmrev (artful-proposed/universe) [1.0-6-2 => 1.0-6-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mcmcpack [source] (artful-proposed) [1.3-8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pbkrtest (artful-proposed/universe) [0.4-7-1 => 0.4-7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-pheatmap (artful-proposed/universe) [1.0.8-1 => 1.0.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-miniui [source] (artful-proposed) [0.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pbkrtest [source] (artful-proposed) [0.4-7-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pscbs (artful-proposed/universe) [0.62.0-1 => 0.62.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mlmrev [source] (artful-proposed) [1.0-6-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-pscl (artful-proposed/universe) [1.4.9-1 => 1.4.9-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pheatmap [source] (artful-proposed) [1.0.8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-readxl (artful-proposed/universe) [1.0.0-1 => 1.0.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rotl (artful-proposed/universe) [3.0.1-1 => 3.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pscl [source] (artful-proposed) [1.4.9-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rotl [source] (artful-proposed) [3.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-shinybs (artful-proposed/universe) [0.61-1 => 0.61-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-readxl [source] (artful-proposed) [1.0.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-solrium (artful-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-scatterd3 (artful-proposed/universe) [0.8.1+dfsg-1 => 0.8.1+dfsg-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-pscbs [source] (artful-proposed) [0.62.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-spatstat (artful-proposed/universe) [1.48-0-1 => 1.48-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-scatterd3 [source] (artful-proposed) [0.8.1+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-solrium [source] (artful-proposed) [0.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-spdep (artful-proposed/universe) [0.6-9-1build1 => 0.6-9-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-vcdextra (artful-proposed/universe) [0.7-0-1 => 0.7-0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-shinybs [source] (artful-proposed) [0.61-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tidyr (artful-proposed/universe) [0.6.1-1 => 0.6.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-spatstat [source] (artful-proposed) [1.48-0-1build1]
-queuebot:#ubuntu-release- Unapproved: rgl (artful-proposed/universe) [0.98.1-2 => 0.98.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-spdep [source] (artful-proposed) [0.6-9-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-vcdextra [source] (artful-proposed) [0.7-0-1build1]
-queuebot:#ubuntu-release- Unapproved: tseries (artful-proposed/universe) [0.10-42-1 => 0.10-42-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tidyr [source] (artful-proposed) [0.6.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rgl [source] (artful-proposed) [0.98.1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted tseries [source] (artful-proposed) [0.10-42-1build1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20170918-0ubuntu1 => 16.10+17.10.20170925-0ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: car (artful-proposed/universe) [2.1-5-1 => 2.1-5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted car [source] (artful-proposed) [2.1-5-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-altcdfenvs (artful-proposed/universe) [1:2.36.0-1 => 1:2.36.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-annotationhub (artful-proposed/universe) [2.8.1-1 => 2.8.1-1build1] (no packageset)
<cyphermox> acheronuk: not meant to fix that just yet; we're working on it
-queuebot:#ubuntu-release- Unapproved: fportfolio (artful-proposed/universe) [3011.81-2 => 3011.81-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-annotate (artful-proposed/universe) [1.52.1+dfsg-1 => 1.52.1+dfsg-1build1] (no packageset)
<acheronuk> cyphermox: I assume no chance for this beta2 then?
-queuebot:#ubuntu-release- Unapproved: accepted fportfolio [source] (artful-proposed) [3011.81-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-annotate [source] (artful-proposed) [1.52.1+dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocparallel (artful-proposed/universe) [1.10.1-1 => 1.10.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-altcdfenvs [source] (artful-proposed) [1:2.36.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biomart (artful-proposed/universe) [2.30.0-1 => 2.30.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-annotationhub [source] (artful-proposed) [2.8.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocparallel [source] (artful-proposed) [1.10.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-go.db (artful-proposed/universe) [3.4.0-1 => 3.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-savr (artful-proposed/universe) [1.12.0-1 => 1.12.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biomart [source] (artful-proposed) [2.30.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-summarizedexperiment (artful-proposed/universe) [1.6.3-1 => 1.6.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-qvalue (artful-proposed/universe) [2.6.0-1 => 2.6.0-1build1] (no packageset)
<cyphermox> acheronuk: no, but one of the bugs is not a bug, probably.
<acheronuk> cyphermox: what is not a bug?
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-go.db [source] (artful-proposed) [3.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-savr [source] (artful-proposed) [1.12.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-coin (artful-proposed/universe) [1.1-3-1 => 1.1-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-lsmeans (artful-proposed/universe) [2.25-1 => 2.25-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-qvalue [source] (artful-proposed) [2.6.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-conting (artful-proposed/universe) [1.6-1 => 1.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-summarizedexperiment [source] (artful-proposed) [1.6.3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-luminescence (artful-proposed/universe) [0.6.4-1 => 0.6.4-1build1] (no packageset)
<cyphermox> language pick by timezone selection
<cyphermox> (moreover, you can easily get that wrong, given that some timezones have a dozen valid keymaps)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-coin [source] (artful-proposed) [1.1-3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lsmeans [source] (artful-proposed) [2.25-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-mi (artful-proposed/universe) [1.0-4 => 1.0-4build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-nmf (artful-proposed/universe) [0.20.6-1 => 0.20.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-conting [source] (artful-proposed) [1.6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-natserv (artful-proposed/universe) [0.1.4-1 => 0.1.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-luminescence [source] (artful-proposed) [0.6.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-polycub (artful-proposed/universe) [0.5-2-1 => 0.5-2-1build1] (no packageset)
<acheronuk> cyphermox: it used to work ok. for me every time
<acheronuk> but yes, it could maybe get it wrong
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-mi [source] (artful-proposed) [1.0-4build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-nmf [source] (artful-proposed) [0.20.6-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rglwidget (artful-proposed/universe) [0.2.1-1 => 0.2.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rredlist (artful-proposed/universe) [0.3.0-1 => 0.3.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-natserv [source] (artful-proposed) [0.1.4-1build1]
<cyphermox> ie. it's not a regression AFAICT, I think it just looked like that was what was happening due to language selection
-queuebot:#ubuntu-release- Unapproved: r-cran-ritis (artful-proposed/universe) [0.5.4-1 => 0.5.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-polycub [source] (artful-proposed) [0.5-2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-shinyjs (artful-proposed/universe) [0.9-1 => 0.9-1build1] (no packageset)
<sil2100> acheronuk: for this beta no more re-spins are planned, it won't be a perfect release but this would delay things too much
<sil2100> We need to aim to get it in for release
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rglwidget [source] (artful-proposed) [0.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rredlist [source] (artful-proposed) [0.3.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-tgp (artful-proposed/universe) [2.4-14-2 => 2.4-14-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-worrms (artful-proposed/universe) [0.1.0-1 => 0.1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-ritis [source] (artful-proposed) [0.5.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-viridis (artful-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-shinyjs [source] (artful-proposed) [0.9-1build1]
<cyphermox> acheronuk: I will need to confer with others anyway, to figure out what to do about it. I'm preparing a test package in my PPA to have a closer look
<cyphermox> keyboard selection in general is kinda broken
<acheronuk> LOL. "it's not a bug, it's a feature"
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-tgp [source] (artful-proposed) [2.4-14-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-worrms [source] (artful-proposed) [0.1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-viridis [source] (artful-proposed) [0.4.0-1build1]
<acheronuk> ok. I've been marking test cases failed, and I fairly stick by that. but given the circumstances, I think can mark stuff ready for the beta despite that
<cyphermox> I think we generally should all have another talk about what pass vs. fails means, because IIRC, we would normally mark things pass (not fail) with bugs attached, unless the install could really not be completed.
<acheronuk> Select your timezone, and click on the continue button
<acheronuk>     The 'Keyboard Layout' screen appears
<acheronuk>     The proposed keyboard corresponds with your keyboard
<acheronuk> If an action fails, or produces an unexpected result, please submit a 'failed' result and file a bug.
<acheronuk> on that definition, it is a fail ^^^^
<cyphermox> interesting
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 2] has been marked as ready
<acheronuk> cyphermox: I did agonise a bit, despite the above, whether to actually mark those fails. you can argue it several ways I admit
<cyphermox> sure
<acheronuk> I just have OEM on Kubuntu i386 left to do, then I think we are done for that
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (artful-proposed) [16.10+17.10.20170925-0ubuntu1]
<sil2100> \o/
<sil2100> I'll be helping out with some Ubuntu Studio testing in a moment, waiting for the isos to download
-queuebot:#ubuntu-release- Unapproved: libs3 (artful-proposed/universe) [2.0-2 => 2.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libs3 [sync] (artful-proposed) [2.0-3]
-queuebot:#ubuntu-release- Unapproved: mgetty (artful-proposed/universe) [1.1.36-3 => 1.1.36-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: afnix (artful-proposed/universe) [2.8.0-1 => 2.8.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted afnix [sync] (artful-proposed) [2.8.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted mgetty [sync] (artful-proposed) [1.1.36-3.1]
<acheronuk> valorie: when you are around, please see the above regarding me marking those cases as failed. that was the only issue causing me to do that, so if it's otherwise ok then will be marking as ready anyway
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.459 => 2.460] (desktop-core)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Beta 2] has been marked as ready
<sil2100> xnox: build kicked
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Beta 2] has been updated (20170928.1)
-queuebot:#ubuntu-release- Unapproved: gcompris-qt (artful-proposed/universe) [0.80-0ubuntu1 => 0.81-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (artful-proposed/main) [0.12.4 => 0.12.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (artful-proposed) [0.12.5]
-queuebot:#ubuntu-release- Unapproved: hmisc (artful-proposed/universe) [4.0-3-1 => 4.0-3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-genefilter (artful-proposed/universe) [1.56.0-1 => 1.56.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hmisc [source] (artful-proposed) [4.0-3-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-geneplotter (artful-proposed/universe) [1.52.0-2 => 1.52.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-afex (artful-proposed/universe) [0.16-1-1 => 0.16-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genefilter [source] (artful-proposed) [1.56.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-rsamtools (artful-proposed/universe) [1.28.0-1 => 1.28.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-caret (artful-proposed/universe) [6.0-73+dfsg1-1 => 6.0-73+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-rsamtools [source] (artful-proposed) [1.28.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-caret [source] (artful-proposed) [6.0-73+dfsg1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-igraph (artful-proposed/universe) [1.0.1-1build1 => 1.0.1-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-afex [source] (artful-proposed) [0.16-1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-dynlm (artful-proposed/universe) [0.3.5-1 => 0.3.5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-geneplotter [source] (artful-proposed) [1.52.0-2build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-sem (artful-proposed/universe) [3.1.8-1 => 3.1.8-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rlumshiny (artful-proposed/universe) [0.1.1-1 => 0.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-igraph [source] (artful-proposed) [1.0.1-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sem [source] (artful-proposed) [3.1.8-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-taxize (artful-proposed/universe) [0.8.0-1 => 0.8.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rlumshiny [source] (artful-proposed) [0.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-surveillance (artful-proposed/multiverse) [1.13.0-1 => 1.13.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dynlm [source] (artful-proposed) [0.3.5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-surveillance [source] (artful-proposed) [1.13.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-taxize [source] (artful-proposed) [0.8.0-1build1]
<sil2100> xnox: ^ image available for testing
<sil2100> jibel: any blockers for desktop on your horizon?
-queuebot:#ubuntu-release- Unapproved: boinc (artful-proposed/universe) [7.8.2+dfsg-3 => 7.8.2+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted boinc [sync] (artful-proposed) [7.8.2+dfsg-4]
<LocutusOfBorg> jbicha, ^^ after this one wx-webview can be dropped
-queuebot:#ubuntu-release- Unapproved: mono-tools (artful-proposed/universe) [4.2-2ubuntu1 => 4.2-2.1] (cli-mono) (sync)
<flocculant> sil2100: you doing studio? if not I could smoketest the 32 bit install
<jibel> sil2100, no, I documented the major issues and will sign off the images
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: its (artful-proposed/universe) [1.1.8-6 => 1.1.8-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-deseq2 (artful-proposed/universe) [1.14.1-1 => 1.14.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted its [source] (artful-proposed) [1.1.8-6build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomicalignments (artful-proposed/universe) [1.12.1-1 => 1.12.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-adegenet (artful-proposed/universe) [2.0.1-1 => 2.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-deseq2 [source] (artful-proposed) [1.14.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-phyloseq (artful-proposed/universe) [1.19.1-2build1 => 1.19.1-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomicalignments [source] (artful-proposed) [1.12.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-adegenet [source] (artful-proposed) [2.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-epir (artful-proposed/universe) [0.9-79-1 => 0.9-79-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-lexrankr (artful-proposed/universe) [0.4.0-1 => 0.4.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-phyloseq [source] (artful-proposed) [1.19.1-2build2]
-queuebot:#ubuntu-release- Unapproved: r-cran-fitcoach (artful-proposed/universe) [1.0-1 => 1.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-boolnet (artful-proposed/universe) [2.1.3-1 => 2.1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-boolnet [source] (artful-proposed) [2.1.3-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fitcoach [source] (artful-proposed) [1.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-phangorn (artful-proposed/universe) [2.1.1-1 => 2.1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rms (artful-proposed/universe) [5.1-1-1 => 5.1-1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-epir [source] (artful-proposed) [0.9-79-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rcmdrmisc (artful-proposed/universe) [1.0-5-1 => 1.0-5-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-lexrankr [source] (artful-proposed) [0.4.0-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-rnexml (artful-proposed/universe) [2.0.7-1build1 => 2.0.7-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-phangorn [source] (artful-proposed) [2.1.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rms [source] (artful-proposed) [5.1-1-1build1]
-queuebot:#ubuntu-release- Unapproved: mono (artful-proposed/main) [4.6.2.7+dfsg-1ubuntu1 => 4.6.2.7+dfsg-1ubuntu2] (cli-mono, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcmdrmisc [source] (artful-proposed) [1.0-5-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rnexml [source] (artful-proposed) [2.0.7-1build2]
<flocculant> sil2100: did the install test - not done the post-install thing
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (artful-proposed/universe) [1.3.0-0ubuntu5 => 1.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openssl-ibmca [source] (artful-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-rtracklayer (artful-proposed/universe) [1.36.4-1 => 1.36.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-rtracklayer [source] (artful-proposed) [1.36.4-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-haplo.stats (artful-proposed/universe) [1.7.7-1 => 1.7.7-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rcmdr (artful-proposed/universe) [2.3-2-1 => 2.3-2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-shortread (artful-proposed/universe) [1.34.0-1 => 1.34.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-phylobase (artful-proposed/universe) [0.8.2-1 => 0.8.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-shortread [source] (artful-proposed) [1.34.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-phylobase [source] (artful-proposed) [0.8.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-haplo.stats [source] (artful-proposed) [1.7.7-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted rcmdr [source] (artful-proposed) [2.3-2-1build1]
<bdmurray> apw: I did add some SRU team members to britney. https://code.launchpad.net/~brian-murray/britney/britney2-ubuntu/+merge/295847  Seems I need to do it again though.
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (artful-proposed/main) [1.401 => 1.402] (core)
<sil2100> flocculant: thanks, I have the image installed on a VM but went off for lunch
<sil2100> flocculant: so you probably beat me to it already ;)
<sil2100> Thanks1
<sil2100> !
<sil2100> flocculant: are you running the post-inst tests?
<sil2100> tsimonq2: hey, any news on lubuntu testing?
<sil2100> tsimonq2: I see most of those aren't done yet
<sil2100> I'd like to release in some hours if possible - are you guys working on that?
-queuebot:#ubuntu-release- Unapproved: libinput (artful-proposed/main) [1.8.2-1ubuntu1 => 1.8.2-1ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Artful Beta 2] has been marked as ready
 * sil2100 pokes tsimonq2 
<acheronuk> sil2100: tsimonq2 says he doesn't know the status of those. I think he is still in school for a couple of hrs as well
-queuebot:#ubuntu-release- Unapproved: r-bioc-bsgenome (artful-proposed/universe) [1.42.0-2 => 1.42.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-adephylo (artful-proposed/universe) [1.1-10-2 => 1.1-10-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomicfeatures (artful-proposed/universe) [1.28.0-1 => 1.28.0-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-bsgenome [source] (artful-proposed) [1.42.0-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-adephylo [source] (artful-proposed) [1.1-10-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomicfeatures [source] (artful-proposed) [1.28.0-1build1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Artful Beta 2] has been marked as ready
<acheronuk> sil2100: tsimonq2 says "please mention Lubuntu Next like in the Alpha 1 announcement!" and he won't be home for 1 1/2 - 2 hrs
<acheronuk> Telegram is a great bonus and a curse. lol
<sil2100> acheronuk: ok, if Lubuntu actually gets tested in a few, I don't want to do the release during the night ;) Thanks for passing messages!
<sil2100> They have so many images that it's crazy
<sil2100> I need those signed off
<acheronuk> I know! sadly I can't really do realistic iso testing on this laptop I'm on at the moment :/
<acheronuk> I pinged the Kubuntu-dev channel to see if any of our testers can assist, but no real bites so far
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.459 => 2.461] (desktop-core)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Artful Beta 2] has been marked as ready
<wxl> um
<wxl> doesn't he mean beta 2 announcement? :)
<wxl> anyways i'll start doing a couple tests
<acheronuk> wxl: I assume he means like was previously done in the Alpha 1 announcement
<sil2100> I personally require at least basic testing done, e.g. if the livesystem works, installs, boots up, starts applications (and terminal) and shutdowns
<wxl> with tsimonq2 logic doesn't always apply XD
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: r-bioc-ensembldb (artful-proposed/universe) [1.6.2-1 => 1.6.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-ensembldb [source] (artful-proposed) [1.6.2-1build1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-variantannotation (artful-proposed/universe) [1.22.1-1 => 1.22.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-variantannotation [source] (artful-proposed) [1.22.1-1build1]
-queuebot:#ubuntu-release- Unapproved: r-cran-treescape (artful-proposed/universe) [1.10.18-6 => 1.10.18-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-treescape [source] (artful-proposed) [1.10.18-6build1]
-queuebot:#ubuntu-release- Unapproved: kdenlive (artful-proposed/universe) [4:17.08.0-0ubuntu1 => 4:17.08.1-0ubuntu1] (kubuntu)
<flocculant> sil2100: nope - no post-install, only had vm to check install and didn't have time to muck about with it and jack
<sil2100> flocculant: it's done now, thanks for your help with the others!
<flocculant> sil2100: no problem, studio and xubuntu are quite close - I usually end up doing some sort of smoketest there ...
<flexiondotorg> sil2100: I'm just popping up for air. How's it coming along?
<ginggs> any ubuntu-archive admin around to look at LP: #1719937 please?
<ubot5> Launchpad bug 1719937 in rgtk2 (Ubuntu) "Please remove r-cran-rgtk2 and r-cran-rggobi s390x binaries" [Undecided,New] https://launchpad.net/bugs/1719937
<sil2100> flexiondotorg: we're almost good to go, waiting for 2 final tests - arm64 and s390x for server
<sil2100> Once those are in I'm starting the machinery
<flexiondotorg> sil2100: Thanks.
<flexiondotorg> Please ping me when it's done. I'll get a notification.
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (trusty-proposed) [0.103ubuntu4.8]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (zesty-proposed) [10.2.9-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (xenial-proposed) [10.2.9-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (zesty-proposed) [20170921+dfsg1-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20170921+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20170921+dfsg1-0ubuntu1~14.04.0]
<sil2100> bdmurray: ah, crap, good point with the bug numbers, eh
<sil2100> That's what you get for uploading in haste
<bdmurray> That's right you get REJECTED!
<sil2100> :'(
<sil2100> SHAME ON ME
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20170718-0ubuntu1~14.04.0 => 20170921+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20170718-0ubuntu1~16.04.0 => 20170921+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20170718-0ubuntu1~17.04.0 => 20170921+dfsg1-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cups-filters (artful-proposed/main) [1.17.7-0ubuntu2 => 1.17.8-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: squid3 (trusty-proposed/main) [3.3.8-1ubuntu6.9 => 3.3.8-1ubuntu6.10] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: r-bioc-biovizbase (artful-proposed/universe) [1.22.0-2 => 1.22.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biovizbase [source] (artful-proposed) [1.22.0-2build1]
 * tsimonq2 pokes sil2100 
<tsimonq2> :)
 * sil2100 is waiting with jibel and/or slangasek
<tsimonq2> I'm just responding to "* sil2100 pokes tsimonq2" :P
<tsimonq2> sil2100: You aren't waiting on me, are ya?
<tsimonq2> Lubuntu is all marked as ready already...
<sil2100> No no, I need someone with isotracker powers now to mark some stuff as ready for server
<sil2100> The ones that are tested
<sil2100> Oh, but jibel is doing that now
<tsimonq2> I was gonna say, you might have someone within 100 feet of you with those powers :P
<tsimonq2> Lucky :P
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: r-bioc-gviz (artful-proposed/universe) [1.18.1-2 => 1.18.1-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-gviz [source] (artful-proposed) [1.18.1-2build1]
<sil2100> xnox: where are the s390x tests? How long does it take to finish them?
<sil2100> (test-results I mean)
<xnox> sil2100, see d-i
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (artful-proposed) [1.8.2-1ubuntu2]
<sil2100> flexiondotorg: ping
<sil2100> flexiondotorg: I did a mistake re: ubuntu-mate, would you be available for testing a respin if anything?
<flexiondotorg> sil2100: Yo
-queuebot:#ubuntu-release- Unapproved: lxqt-l10n (artful-proposed/universe) [0.11.2-2ubuntu1 => 0.11.2-3ubuntu1] (no packageset)
<tsimonq2> Low priority, feel free to approve but not urgent ^^^^
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Artful Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-l10n [source] (artful-proposed) [0.11.2-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-cummerbund (artful-proposed/universe) [2.16.0-2 => 2.16.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-cummerbund [source] (artful-proposed) [2.16.0-2build1]
-queuebot:#ubuntu-release- Unapproved: isdnutils (artful-proposed/universe) [1:3.25+dfsg1-8ubuntu1 => 1:3.25+dfsg1-9ubuntu1] (no packageset)
<rbalint> could someone please let golang-github-opencontainers-selinux-dev in for next runc update?
-queuebot:#ubuntu-release- Unapproved: accepted isdnutils [source] (artful-proposed) [1:3.25+dfsg1-9ubuntu1]
<sil2100> It is happening, the final beta release is happening
<tsimonq2> \o/
<valorie> yay!
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.460]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (artful-proposed) [2.461]
-queuebot:#ubuntu-release- Unapproved: live-build (artful-proposed/main) [3.0~a57-1ubuntu30 => 3.0~a57-1ubuntu31] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: qtermwidget (artful-proposed/universe) [0.7.1-6 => 0.7.1-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (artful-proposed) [3.0~a57-1ubuntu31]
-queuebot:#ubuntu-release- Unapproved: juffed (artful-proposed/universe) [0.10-85-g5ba17f9-13ubuntu1 => 0.10-85-g5ba17f9-14] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted calc-stats [source] (artful-proposed) [1.4-0ubuntu1]
<flexiondotorg> sil2100: Are the wheels still turning?
<valorie> a couple of the torrents are published.....
<valorie> trickle trickle
<sil2100> Yeah, ongoing
 * tsimonq2 stares at snakefruit
-queuebot:#ubuntu-release- Unapproved: im-config (artful-proposed/main) [0.29-1.4ubuntu1 => 0.32-1ubuntu1] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
<sil2100> How are the torrents? Looking good?
<tsimonq2> valorie would know :P
 * sil2100 tries some
<valorie> there are 22 so far
<valorie> I think that's all?
<valorie> hmmm, hard to tell because I don't think they have torrents for netboot, etc.
 * sil2100 waits for the torrents to start seeding
<valorie> mine are
<sil2100> The main ubuntu amd64 isn't yet :<
-queuebot:#ubuntu-release- Unapproved: weechat (artful-proposed/universe) [1.9-1build1 => 1.9.1-1] (no packageset) (sync)
<valorie> oh, they are sort of not
<valorie> just sittin'
<flexiondotorg> Ummm, sil2100 I'm not seeing any releases on cdimage.
<valorie> right, we've not got the notifications yet
<sil2100> flexiondotorg: I checked and saw, what do you mean?
-queuebot:#ubuntu-release- Unapproved: accepted weechat [sync] (artful-proposed) [1.9.1-1]
<sil2100> flexiondotorg: I mean, I saw the releases
<flexiondotorg> http://cdimage.ubuntu.com/ubuntu/releases/17.10/beta-2/
<sil2100> Any in particular you mean are missing?
<flexiondotorg> Is empty.
-queuebot:#ubuntu-release- Unapproved: otrs2 (artful-proposed/universe) [5.0.22-1 => 5.0.23-1] (no packageset) (sync)
<sil2100> flexiondotorg: look in releases.ubuntu.com
<sil2100> For final beta those go there
<sil2100> http://releases.ubuntu.com/17.10/
<flexiondotorg> http://cdimage.ubuntu.com/ubuntu-mate/releases/17.10/
-queuebot:#ubuntu-release- Unapproved: accepted otrs2 [sync] (artful-proposed) [5.0.23-1]
<flexiondotorg> Redirects to there and no beta-2
<sil2100> I see beta-2 there
<sil2100> And images
<sil2100> http://cdimage.ubuntu.com/ubuntu-mate/releases/17.10/beta-2/
<flexiondotorg> http://releases.ubuntu.com/ has nothing for 17.10/artful
<valorie> published 4 mins ago!
<valorie> lol
<sil2100> I have it there, probably mirror/sync issues
<valorie> yup
<sil2100> If I see it on the webbrowser then it will appear sooner or later, no worries
<valorie> I'm pretty sure once the notifications hit, we're a go
<sil2100> If it's not there in 30 mins then we should start worrying
<sil2100> valorie: indeed!
<sil2100> Not sending the announcement until all is settled
<flexiondotorg> No beta-2 here https://usercontent.irccloud-cdn.com/file/yKA6oCiZ/ubuntu-mate-releases.png
<valorie> my kubuntu and the xubuntu isos are downloading in ktorrent now
<sil2100> Torrents still 0 seeds, this is taking a while
-queuebot:#ubuntu-release- Unapproved: jbig2dec (artful-proposed/main) [0.13-4.1 => 0.13-5] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: openjpeg2 (artful-proposed/universe) [2.1.2-1.3 => 2.2.0-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: php-horde-image (artful-proposed/universe) [2.5.1-1 => 2.5.2-1] (no packageset) (sync)
<sil2100> flexiondotorg: I even checked from my remote shell that releases.ubuntu.com has the beta-2 images, so I guess it's only on your side
<flexiondotorg> Yeah, Ive just logged in via a VPN to home.
-queuebot:#ubuntu-release- Unapproved: accepted php-horde-image [sync] (artful-proposed) [2.5.2-1]
<flexiondotorg> I see beta-2
<flexiondotorg> From the wifi at the rally, I don't.
<flexiondotorg> Caching I guess.
<sil2100> Only the main amd64 torrent story worries me
<sil2100> hm, ok, one thing I noticed, I don't see 17.10 netboot images
<sil2100> I think I'll have to do those manually?
-queuebot:#ubuntu-release- Unapproved: pyjwt (artful-proposed/main) [1.4.2-1ubuntu1 => 1.4.2-1.1] (ubuntu-server) (sync)
<valorie> I wonder why?
<valorie> but there never have been
<valorie> torrents, i mean
<valorie> I just removed all my limits on downloading, so I can start actually seeding more quickly
-queuebot:#ubuntu-release- Unapproved: enigmail (artful-proposed/universe) [2:1.9.8.2-1 => 2:1.9.8.2-2] (mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: sane-backends-extras (artful-proposed/universe) [1.0.22.4build1 => 1.0.22.5] (no packageset) (sync)
<sil2100> Ok, I guess it works
<sil2100> flexiondotorg, valorie: you see any issues so far?
<sil2100> Any last words? Or should I consider the release as released?
<tsimonq2> imho, JFDI :)
<valorie> I'm running the beta from upgrades as we speak
<valorie> no problems from my end
<valorie> and the torrents are all downloading, even if slowly
<sil2100> slangasek, cjwatson, Laney: I would need someone to add an announcement to https://launchpad.net/ubuntu/+announce
 * valorie waits on the kubuntu.org announcement though
<sil2100> Damn, I might also need someone to get my e-mail through to ubuntu-announce@
<valorie> it's odd that we've gotten no individual "beta is published" notifications though
<valorie> so something isn't fully cooked
<flexiondotorg> sil2100: popey will moderate your email in a sec
<sil2100> Working on the announcement, some additional stuff is needed, one moment
#ubuntu-release 2017-09-29
-queuebot:#ubuntu-release- Unapproved: hdhomerun-config-gui (artful-proposed/universe) [20161117-0ubuntu2 => 20161117-0ubuntu3] (mythbuntu)
<valorie> c'mon notifications!
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Zesty 17.04, Artful 17.10 Final Beta | Archive: final beta freeze | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: kodi-pvr-hdhomerun (artful-proposed/universe) [2.4.2+git20160820-2 => 2.4.2+git20160820-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kodi-pvr-hdhomerun [source] (artful-proposed) [2.4.2+git20160820-2build1]
-queuebot:#ubuntu-release- Unapproved: fcitx-qimpanel (artful-proposed/universe) [2.1.2-2 => 2.1.2-3] (input-methods, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [sync] (artful-proposed) [2:1.9.8.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted hdhomerun-config-gui [source] (artful-proposed) [20161117-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted openjpeg2 [sync] (artful-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted sane-backends-extras [sync] (artful-proposed) [1.0.22.5]
-queuebot:#ubuntu-release- Unapproved: accepted fcitx-qimpanel [sync] (artful-proposed) [2.1.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted qtermwidget [sync] (artful-proposed) [0.7.1-7]
-queuebot:#ubuntu-release- Unapproved: accepted juffed [sync] (artful-proposed) [0.10-85-g5ba17f9-14]
<tsimonq2> \o/
<valorie> where the heck are the notifications and announcements?
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Beta 2] has been updated (20170929)
<valorie> weeeeeeeeeeeeeeeeeeee
<valorie> magick
<krytarik> hahaha
<valorie> oh, updated
<valorie> um
<Ukikie> Looks like the undesired notification-daemon is still on every ISO...
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Artful Beta 2] has been updated (20170929)
<valorie> huh
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Artful Beta 2] has been updated (20170929)
<ginggs> would someone please bump 'force-badtest r-bioc-annotationhub/2.8.1-1build1' in adconrad's hints?
<ginggs> and 'force-badtest r-cran-surveillance/1.13.0-1build1' in vorlon's hints
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Beta 2] has been updated (20170929)
<acheronuk> ok. beta 2 images not really updated. really the daily iso, and someone needs to turn that channel notification off again until final release spins?
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Artful Beta 2] has been updated (20170929)
-queuebot:#ubuntu-release- Unapproved: ca-certificates-java (artful-proposed/main) [20170531+nmu1 => 20170531+nmu1ubuntu1] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Artful Beta 2] has been updated (20170929)
<LocutusOfBorg> infinity, slangasek, doko  ^^^ this should fix the armhf java installation failure (I  uploaded in debian deferred/1 queue, will sync if it reaches unstable)
-queuebot:#ubuntu-release- Unapproved: wxwidgets3.0 (artful-proposed/universe) [3.0.3.1+dfsg-1 => 3.0.3.1+dfsg2-1] (kubuntu) (sync)
<LocutusOfBorg> jbicha, ^^^ your wx free of webview
-queuebot:#ubuntu-release- Unapproved: r-cran-dplyr (artful-proposed/universe) [0.5.0-1ubuntu3 => 0.5.0-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-dplyr [source] (artful-proposed) [0.5.0-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: console-setup (artful-proposed/main) [1.166ubuntu5 => 1.166ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (artful-proposed) [17.10.8]
<tjaalton> juliank: hi, did you upload apt to zesty-proposed?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (artful-proposed) [1.402]
<juliank> tjaalton: Yes, I did. (It's a sync with stretch, but a local one for sru-review diffing)
<tjaalton> juliank: well the version string should have ~17.04.1 in it, like the previous upload
<tjaalton> and some bugs don't seem to have the usual sru header
<tjaalton> then again xenial doesn't
<juliank> tjaalton: As I wrote, the goal was to sync it to stretch and avoid having diverging version numbers. It's literally to the point where it can syncpackage'd
<tjaalton> okay
<juliank> The previous upload needed ~17.04.1 because it had the version in artful too
<tjaalton> right
<juliank> tjaalton: I think one bug might be missing the SRU headers, do you know which ones?
<tjaalton> 1690980, though it's almost good as-is
<juliank> tjaalton: It's a bit difficult because it will have SRUs for both apt and unattended-upgrades.
<tjaalton> I guess that's fine
<juliank> tjaalton: I'll add some details
<tjaalton> meaning that you can add package specific details there, yeah
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (zesty-proposed) [1.4.8]
<juliank> tjaalton: Should be good now
<juliank> Also fixed up the status meta data for xenial in the bug to  "In Progress" as it should be (it was only triaged)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.25]
<tjaalton> and now fix committed ;)
<juliank> tjaalton: thx
<juliank> I still gotta send in the patch I have for syncpackage that does not strip signatures from .dsc files, which is kind of pointless for me since I signed the .dsc once already :D
<juliank> Now I can syncpackage path-to-stretch.dsc when needed, yay!
-queuebot:#ubuntu-release- Unapproved: rejected ca-certificates-java [source] (artful-proposed) [20170531+nmu1ubuntu1]
<tjaalton> neat..
-queuebot:#ubuntu-release- Builds: 37 entries have been added, updated or disabled
<slangasek> tdaitx: I'd like you to confirm you're happy with LocutusOfBorg's ca-certificate upload currently in the queue, since you were working on this area
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20170925-0ubuntu1 => 16.10+17.10.20170929-0ubuntu1] (core)
<mdeslaur> slangasek: which queue? (ca-certificates)
<tdaitx> slangasek, could you point me to that?
<tdaitx> I already synced with doko about it, I added the right ca-certificate-java fix in debian #874434
<ubot5> Debian bug 874434 in ca-certificates-java "openjdk-8-jre-headless: uninstallable on armhf" [Grave,Open] http://bugs.debian.org/874434
<doko> Laney: release team follow-up in ballroom
<mdeslaur> oh, ca-certificate-java, nm
<tdaitx> and sent him an updated fix for openjdk-8
<doko> mdeslaur, slangasek: rejected, and working on it with tdaitx
<slangasek> mdeslaur, tdaitx: ah, already rejected? ok :)
<tdaitx> k, tks doko
<doko> apw: release team follow-up in ballroom
-queuebot:#ubuntu-release- Unapproved: gnome-software (artful-proposed/main) [3.26.0-0ubuntu2 => 3.26.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: juju-core (xenial-proposed/main) [2.0.2-0ubuntu0.16.04.2 => 2.2.4-0ubuntu0.16.04.1] (ubuntu-server)
<balloons> slangasek, tyhicks, ^^ juju core has been uploaded. Can you accept into proposed? We had to vendorize x/crypto, but everything else still builds. We embedded go-1.8 to build as discussed
-queuebot:#ubuntu-release- Unapproved: python-launchpadlib (artful-proposed/main) [1.10.4-1 => 1.10.5-1] (core) (sync)
<LocutusOfBorg> slangasek, the "fix" has been uploaded in Debian, as said on the bug reports, now java is installable again everywhere, and stuff has been given back successfully in armhf (Debian)
<LocutusOfBorg> if you have a better one, as you wish
<LocutusOfBorg> tdaitx, just please make sure it reaches artful quickly if possible, some packages/transitions are waiting for such armhf fix
<tdaitx> LocutusOfBorg, yeah, I know, I sent the right fix to debian yesterday, doko should upload that soon and then sync it to ubuntu
<LocutusOfBorg> mmm I don't find such patch :/
<LocutusOfBorg> not sure how I missed it
<LocutusOfBorg> even in spam I didn't get the email :/
<LocutusOfBorg> seems indeed a better approach thanks
-queuebot:#ubuntu-release- Unapproved: altermime (artful-proposed/universe) [0.3.10-8 => 0.3.10-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted altermime [sync] (artful-proposed) [0.3.10-9]
-queuebot:#ubuntu-release- Unapproved: foomatic-filters (artful-proposed/universe) [4.0.17-9 => 4.0.17-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted foomatic-filters [sync] (artful-proposed) [4.0.17-10]
-queuebot:#ubuntu-release- Unapproved: nss (artful-proposed/main) [2:3.32-1ubuntu2 => 2:3.32-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: python-py (artful-proposed/universe) [1.4.34-2ubuntu1 => 1.4.34-3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: calc-stats (artful-proposed/universe) [1.4-0ubuntu1 => 1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted calc-stats [source] (artful-proposed) [1.5-0ubuntu1]
-queuebot:#ubuntu-release- New binary: calc-stats [amd64] (artful-proposed/universe) [1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: autobahn-cpp (artful-proposed/universe) [0.2.1-2 => 0.2.1-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted autobahn-cpp [sync] (artful-proposed) [0.2.1-2.1]
-queuebot:#ubuntu-release- Unapproved: adwaita-icon-theme (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.0-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (artful-proposed/main) [1:3.25.91-0ubuntu1 => 1:3.25.91-0ubuntu2] (ubuntu-desktop)
<acheronuk> release team: some of the builds on http://iso.qa.ubuntu.com/qatracker/milestones/382/builds have been updated to the daily iso spin from today
<acheronuk> I guess this is an error
<acheronuk> our actual beta 2 remains untouched: http://cdimage.ubuntu.com/kubuntu/releases/artful/beta-2/
<valorie> to add to that -- I got emails saying that they needed testing
<valorie> so some switch didn't get flipped to Off
-queuebot:#ubuntu-release- Unapproved: evince (xenial-proposed/main) [3.18.2-1ubuntu4.1 => 3.18.2-1ubuntu4.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.3-0ubuntu2 => 3:11.0.3-0ubuntu3] (openstack, ubuntu-server)
<coreycb> bdmurray: hi, we have a high priority bug fix for horizon in zesty that I just uploaded. would we be able to promote that to zesty-proposed on top of 3:11.0.3-0ubuntu2 and we'll test both SRUs together?
<bdmurray> coreycb: probably, looking now
-queuebot:#ubuntu-release- Unapproved: lsvpd (artful-proposed/main) [1.7.8-0ubuntu1 => 1.7.8-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (artful-proposed) [1.7.8-0ubuntu2]
<bdmurray> coreycb: The regression potential seems to have been cut off but I'll accept it anyway.
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (zesty-proposed) [3:11.0.3-0ubuntu3]
<coreycb> bdmurray: thanks very much, i've updated the regression potential
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.462 => 2.463] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.463]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (artful-proposed/universe) [60-1 => 61-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [sync] (artful-proposed) [61-1]
#ubuntu-release 2017-09-30
-queuebot:#ubuntu-release- Unapproved: accepted python-launchpadlib [sync] (artful-proposed) [1.10.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-py [sync] (artful-proposed) [1.4.34-3]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (artful-proposed) [1.17.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (artful-proposed) [3.26.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (artful-proposed) [1:3.25.91-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [source] (artful-proposed) [16.10+17.10.20170929-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mono-tools [sync] (artful-proposed) [4.2-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted mono [source] (artful-proposed) [4.6.2.7+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcompris-qt [source] (artful-proposed) [0.81-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (artful-proposed) [1.166ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted jbig2dec [sync] (artful-proposed) [0.13-5]
-queuebot:#ubuntu-release- Unapproved: accepted wxwidgets3.0 [sync] (artful-proposed) [3.0.3.1+dfsg2-1]
-queuebot:#ubuntu-release- Unapproved: accepted pyjwt [sync] (artful-proposed) [1.4.2-1.1]
-queuebot:#ubuntu-release- Unapproved: qwtplot3d (artful-proposed/universe) [0.2.7+svn191-10.1 => 0.2.7+svn191+gcc7-1.0] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qwtplot3d [sync] (artful-proposed) [0.2.7+svn191+gcc7-1.0]
-queuebot:#ubuntu-release- Unapproved: arc-gui-clients (artful-proposed/universe) [0.4.6-3 => 0.4.6-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted arc-gui-clients [sync] (artful-proposed) [0.4.6-4]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (artful-proposed/universe) [17.10.2 => 17.10.3] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ca-certificates-java (artful-proposed/main) [20170531+nmu1 => 20170930] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libpng1.6 (artful-proposed/main) [1.6.32-3 => 1.6.34-1] (core) (sync)
<LocutusOfBorg> this should be the ca-certificates-java "fixed by doko"
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- Unapproved: bioperl (artful-proposed/universe) [1.7.1-2 => 1.7.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bioperl [sync] (artful-proposed) [1.7.1-3]
-queuebot:#ubuntu-release- Unapproved: font-manager (artful-proposed/universe) [0.7.3-1ubuntu1 => 0.7.3-1.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (artful-proposed/universe) [3.26.0-1ubuntu2 => 3.26.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: gnome-contacts (artful-proposed/universe) [3.25.4-0ubuntu1 => 3.26-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: file-roller (artful-proposed/main) [3.26.0-0ubuntu1 => 3.26.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: munin (artful-proposed/universe) [2.0.33-1 => 2.0.33-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted munin [sync] (artful-proposed) [2.0.33-3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (artful-proposed/universe) [0.79 => 0.80] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (artful-proposed/main) [8u144-b01-1 => 8u144-b01-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (artful-proposed) [3.26.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted font-manager [sync] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [sync] (artful-proposed) [8u144-b01-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (artful-proposed) [0.80]
-queuebot:#ubuntu-release- Unapproved: accepted file-roller [source] (artful-proposed) [3.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (artful-proposed) [17.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-contacts [sync] (artful-proposed) [3.26-1]
-queuebot:#ubuntu-release- Unapproved: abiword (artful-proposed/universe) [3.0.2-3 => 3.0.2-3ubuntu1] (desktop-extra)
 * tsimonq2 wonders why abiword isn't in the lubuntu packageset...
<tsimonq2> *shrug*
<tsimonq2> If it doesn't autoapprove, I'd like an approval please, it's important for Lubuntu :)
<mparillo> tsimonq2: I know Lubuntu-next installs LibreOffice, including Writer.
<tsimonq2> mparillo: I'm talking about stock LXDE Lubuntu here.
<valorie> aren't you in charge of the packageset contents?
<mparillo> So I am waaaay ahead -;)
<tsimonq2> valorie: No?
<valorie> I know that we add and drop things -- maybe ask acheronuk or clivejo how?
<acheronuk> kubuntu is different. we are a delegated team
<valorie> ok
<acheronuk> and seeds vs packageset are not the same
<valorie> ah
<valorie> my mistake
-queuebot:#ubuntu-release- Unapproved: accepted abiword [source] (artful-proposed) [3.0.2-3ubuntu1]
<tsimonq2> Thanks, whoever that was
<tsimonq2> jbicha: Thanks for the QA upload in Debian, that was my next step ;)
-queuebot:#ubuntu-release- Unapproved: ubuntu-themes (artful-proposed/main) [16.10+17.10.20170929-0ubuntu1 => 16.10+17.10.20170930-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-games-app (artful-proposed/universe) [3.26.0-1 => 3.26.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [sync] (artful-proposed) [3.26.1-1]
#ubuntu-release 2017-10-01
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (artful-proposed) [2.20.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fcitx-qimpanel (artful-proposed/universe) [2.1.2-3 => 2.1.3-1] (input-methods, ubuntu-desktop) (sync)
<tjaalton> could someone mark 389-ds-base autopkgtest on armhf ignored, upstream is going to remove support for 32bit anyway but I won't touch that before next cycle
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (artful-proposed/universe) [1.3.6.7-4 => 1.3.6.7-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ldc (artful-proposed/universe) [1:1.4.0-1ubuntu1 => 1:1.4.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: ldc [armhf] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: goobox (artful-proposed/universe) [3.4.2-4 => 3.4.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (artful-proposed/main) [1.2.10-0ubuntu1 => 1.2.10-0ubuntu2] (ubuntu-desktop)
<jbicha> I would have expected goobox & a few others from earlier today to have been auto-approved since they look unseeded
-queuebot:#ubuntu-release- Unapproved: accepted goobox [sync] (artful-proposed) [3.4.2-6]
<infinity> jbicha: There was a hung auto-accept.  Cleaned up.
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (artful-proposed) [1.3.6.7-5]
-queuebot:#ubuntu-release- Unapproved: accepted ldc [sync] (artful-proposed) [1:1.4.0-3]
-queuebot:#ubuntu-release- New binary: ldc [amd64] (artful-proposed/universe) [1:1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [ppc64el] (artful-proposed/universe) [1:1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [i386] (artful-proposed/universe) [1:1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [armhf] (artful-proposed/universe) [1:1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: binutils (artful-proposed/main) [2.29.1-3ubuntu1 => 2.29.1-4ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (artful-proposed) [1:1.4.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (artful-proposed) [1:1.4.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (artful-proposed) [1:1.4.0-3]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (artful-proposed) [1:1.4.0-3]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (artful-proposed) [1:1.4.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (artful-proposed) [1:1.4.0-3]
-queuebot:#ubuntu-release- New: accepted ldc [ppc64el] (artful-proposed) [1:1.4.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [ppc64el] (artful-proposed) [1:1.4.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (artful-proposed) [2.29.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (artful-proposed) [2:3.32-1ubuntu3]
<LocutusOfBorg> doko, FYI ldc is now good, except for sambamba
<LocutusOfBorg> and a sync of gtk-d/diet-ng
-queuebot:#ubuntu-release- Unapproved: pcmanfm (artful-proposed/universe) [1.2.5-3 => 1.2.5-3ubuntu1] (no packageset)
<tsimonq2> Can someone please approve that? It's not translation freeze yet :P ^^^^^^6
-queuebot:#ubuntu-release- Unapproved: unity-control-center (artful-proposed/universe) [15.04.0+17.10.20170814.1-0ubuntu2 => 15.04.0+17.10.20170930-0ubuntu1] (mythbuntu, ubuntukylin) (sync)
<infinity> tsimonq2: There's no such thing as "translation freeze", that would be counter-intuitive.
<infinity> tsimonq2: String freeze is for the *base* strings, so translations can catch up.
-queuebot:#ubuntu-release- Unapproved: accepted pcmanfm [source] (artful-proposed) [1.2.5-3ubuntu1]
<tsimonq2> infinity: Oh, fair :P
<tsimonq2> infinity: Makes sense.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (artful-proposed/main) [2.463 => 2.464] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted adwaita-icon-theme [source] (artful-proposed) [3.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [source] (artful-proposed) [16.10+17.10.20170930-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openvpn [source] (artful-proposed) [1.2.10-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (artful-proposed) [2.464]
-queuebot:#ubuntu-release- Unapproved: bijiben (artful-proposed/universe) [3.26.0-0.1 => 3.26.1-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (artful-proposed/main) [7.2.0-7ubuntu4 => 7.2.0-8ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (artful-proposed) [7.2.0-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: abiword (artful-proposed/universe) [3.0.2-3ubuntu1 => 3.0.2-4] (desktop-extra) (sync)
<tsimonq2> Please approve the abiword sync, the Ubuntu changes were upstreamed to Debian.
#ubuntu-release 2018-09-24
<apw> LocutusOfBorg, gone
<oSoMoN> good morning
<oSoMoN> could someone please ack https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/355442 to unblock the migration of libreoffice 6.1.1 ?
-queuebot:#ubuntu-release- New binary: gnome-session [amd64] (cosmic-proposed/main) [3.30.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1020.23] (kernel)
<Laney> oSoMoN: I was talking to doko about this at the sprint; is the bug on someone's radar?
<Laney> I'm not sure if the kernel team are waiting for some testing or something
<oSoMoN> Laney, it's on my radar
<oSoMoN> I really mean to get to the bottom of it, but I keep being distracted by other priorities
<oSoMoN> thanks Laney
<Laney> that's okay
<apw> oSoMoN, bug ?
<Laney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772
<ubot5> Ubuntu bug 1699772 in linux (Ubuntu Bionic) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,Incomplete]
<apw> oSoMoN, so broken on cosmic still is the issue?
<oSoMoN> yes
<apw> oSoMoN, thanks, will make sure this is on the right radars
<oSoMoN> and last time I checked it worked on debian testing
<oSoMoN> apw, thanks!
<Laney> ð
<juliank> Do we have an idea what's going on with makedumpfile?
<juliank> It seems to be crashing unpacking the kernel after triggering a reboot
<juliank> because the VM instead of 1.5GB, it suddenly only has 131 MB of RAM
<juliank> that's the autopkgtest on cosmic/amd64
<juliank> How does the nova instance reduce it's memory by 90% by rebooting?
<juliank> jbicha: What's going on with the network-manager retries?
<juliank> The fail reason is very clear, I don't see why you're retrying those
<juliank> That said, the fail reason is wrong :)
<juliank> debian/tests/nm:23: PyGIWarning: NetworkManager was imported without specifying a version first. Use gi.require_version('NetworkManager', '1.0') before import to ensure that the right version gets loaded.
<juliank> ^ it does that
<juliank> And line 23 imports "gi", nothing from the repository
<Laney> I just uploaded a fix for that, so make sure you are looking at the right version
<juliank> Laney: oh, good
<Laney> no idea about the other thing I'm afraid
<juliank> Laney: No idea why jbicha needed to retry this 4 times, though
<juliank> And yes I forgot to check the version pull-lp-source pulled is the version being tested :)
<Laney> juliank: indeed (but I already raised that in #ubuntu-desktop)
<juliank> ack
 * juliank retriggered ubuntu-make against the new apt to see if it works now
<mfo> sil2100, hi. just checking if it's possible for nodejs to migrate from bionic-proposed to -updated? (SRU in LP 1779863)  It's been verified, and afaik the one test-case failing (node-tap) has been marked to be ignored (as it's test-case specific problem.. plus patches for that were submitted in LP 1793612, but Steve mentioned it's not a priority now).  Thanks!
<ubot5> Launchpad bug 1779863 in nodejs (Debian) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Unknown,New] https://launchpad.net/bugs/1779863
<ubot5> Launchpad bug 1793612 in node-tap (Ubuntu Bionic) "node-tap in bionic fails autopkgtests due to timeouts" [Undecided,New] https://launchpad.net/bugs/1793612
-queuebot:#ubuntu-release- New: accepted gnome-session [amd64] (cosmic-proposed) [3.30.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted aom [sync] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-runtime [amd64] (cosmic-proposed) [4.7.3-2build1]
-queuebot:#ubuntu-release- New binary: aom [s390x] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aom [ppc64el] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aom [arm64] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aom [armhf] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aom [amd64] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aom [i386] (cosmic-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted aom [amd64] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted aom [armhf] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted aom [ppc64el] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted aom [arm64] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted aom [s390x] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted aom [i386] (cosmic-proposed) [1.0.0-2]
<tjaalton> could a member of the release team chime in on bug 1792873, I'd like to get an ack to upload it
<ubot5> bug 1792873 in mesa (Ubuntu) "FFE: 18.2.x for cosmic" [Medium,Triaged] https://launchpad.net/bugs/1792873
<sil2100> tjaalton: hmmm, it's already Triaged
<sil2100> tjaalton: I would notice it if it wasn't Triaged - since this basically means 'it's approved'
<tjaalton> ah, process error on my part then
<tjaalton> marked back to new
-queuebot:#ubuntu-release- New binary: equinox-bundles [amd64] (cosmic-proposed/universe) [4.7.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted equinox-bundles [amd64] (cosmic-proposed) [4.7.3-2]
<xnox> doko, can you please promote ruby-xmlrpc? it is standalone package now, part of libruby2.5 https://bugs.launchpad.net/ubuntu/+source/ruby-xmlrpc/+bug/1794091
<ubot5> Ubuntu bug 1794091 in ruby-xmlrpc (Ubuntu) "[MIR] ruby-xmlrpc" [Undecided,New]
<sil2100> tjaalton: thanks, will look at it after my quick SRU shift - btw. I was reviewing xorg-server in bionic just now
<sil2100> tjaalton: LP: #1789924 mentions a kernel task - is it required for the xorg-server bits to be relevant?
<ubot5> Launchpad bug 1789924 in xorg-server (Ubuntu Bionic) "Missing Intel GPU pci-id's" [Undecided,New] https://launchpad.net/bugs/1789924
<tjaalton> sil2100: they can be applied independently
<sil2100> tjaalton: I mean, can I accept xorg-server without the kernel part being released?
<sil2100> Ok
<tjaalton> sure
<sil2100> Thanks
<tjaalton> libdrm will be fixed once it's backported from cosmic, for instance, same for mesa
<sil2100> Ok, as long as they're all independent, I'll just fetch xorg-server for now
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (bionic-proposed) [2:1.19.6-1ubuntu4.1]
<tjaalton> thanks!
-queuebot:#ubuntu-release- Unapproved: rejected pcl [source] (bionic-proposed) [1.8.1+dfsg1-2ubuntu2.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (bionic-proposed) [1.8.1+dfsg1-2ubuntu2.18.04.1]
<sil2100> cpaelzer: hey!
<sil2100> cpaelzer: I'm looking at the open-iscsi upload in bionic right now, last comment from you I see you wanted to get some PPA-testing first
<sil2100> cpaelzer: is that still the case? Or did you already get the testing you wanted? (since it is in the queue alright)
-queuebot:#ubuntu-release- New binary: eclipse-platform-runtime [amd64] (cosmic-proposed/universe) [4.7.3-2build2] (no packageset)
-queuebot:#ubuntu-release- New sync: librouteros (cosmic-proposed/primary) [2.1.1-1]
-queuebot:#ubuntu-release- New sync: python-aioamqp (cosmic-proposed/primary) [0.11.0-1]
-queuebot:#ubuntu-release- New sync: python-grpc-tools (cosmic-proposed/primary) [1.14.1-1]
-queuebot:#ubuntu-release- New sync: python-grpcio (cosmic-proposed/primary) [1.15.0-1]
-queuebot:#ubuntu-release- New sync: sphinxcontrib-doxylink (cosmic-proposed/primary) [1.5-1]
-queuebot:#ubuntu-release- New sync: wikitrans (cosmic-proposed/primary) [1.3-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-runtime [amd64] (cosmic-proposed) [4.7.3-2build2]
-queuebot:#ubuntu-release- New: accepted python-aioamqp [sync] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [sync] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted wikitrans [sync] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted librouteros [sync] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: rejected sphinxcontrib-doxylink [sync] (cosmic-proposed) [1.5-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [sync] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New binary: librouteros [amd64] (cosmic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wikitrans [amd64] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [s390x] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [ppc64el] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-aioamqp [amd64] (cosmic-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpc-tools [s390x] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [i386] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpc-tools [ppc64el] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [armhf] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [amd64] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpcio [arm64] (cosmic-proposed/universe) [1.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-platform-ui [amd64] (cosmic-proposed/universe) [4.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eclipse-platform-resources [amd64] (cosmic-proposed/universe) [4.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted eclipse-platform-resources [amd64] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [amd64] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted librouteros [amd64] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [arm64] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [i386] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [s390x] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [amd64] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [ppc64el] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted python-grpcio [armhf] (cosmic-proposed) [1.15.0-1]
-queuebot:#ubuntu-release- New: accepted wikitrans [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted python-aioamqp [amd64] (cosmic-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New binary: python-grpc-tools [armhf] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: restrictedpython [amd64] (cosmic-proposed/universe) [4.0~b3-1] (zope)
-queuebot:#ubuntu-release- New binary: python-grpc-tools [arm64] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
<doko> xnox: needs bug subscriber. server team?
<xnox> doko, yes
<doko> cpaelzer: ^^^
-queuebot:#ubuntu-release- New binary: python-grpc-tools [i386] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-grpc-tools [amd64] (cosmic-proposed/universe) [1.14.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [amd64] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [armhf] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [ppc64el] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [arm64] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [i386] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New: accepted python-grpc-tools [s390x] (cosmic-proposed) [1.14.1-1]
-queuebot:#ubuntu-release- New binary: eclipse-platform-text [amd64] (cosmic-proposed/universe) [4.7.3-2] (no packageset)
<xnox> doko, cpaelzer - can you please subscribe server team bug subscriber to ruby-xmlrpc ; it's a component (bundled gem) of ruby2.5 (main, server)
<cpaelzer> xnox: I can't
<cpaelzer> powersj: can consider it
<cpaelzer> powersj: ^^
-queuebot:#ubuntu-release- New: accepted restrictedpython [amd64] (cosmic-proposed) [4.0~b3-1]
-queuebot:#ubuntu-release- New binary: dds [s390x] (cosmic-proposed/universe) [2.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [s390x] (cosmic-proposed/universe) [0.2.2+dfsg1-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: dds [amd64] (cosmic-proposed/universe) [2.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [amd64] (cosmic-proposed/universe) [0.2.2+dfsg1-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: dds [i386] (cosmic-proposed/universe) [2.9.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [arm64] (cosmic-proposed/universe) [0.2.2+dfsg1-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libopenshot [armhf] (cosmic-proposed/universe) [0.2.2+dfsg1-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: libopenshot [i386] (cosmic-proposed/universe) [0.2.2+dfsg1-1] (ubuntustudio)
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-multi-monitors (cosmic-proposed/primary) [0.00~git20171014.1.df5d6e4-1]
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: Beta Freeze | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis.
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (cosmic-proposed/main) [3.30.0-1 => 3.30.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gedit (cosmic-proposed/main) [3.30.0-1 => 3.30.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gedit-plugins (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gedit-plugins [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-multi-monitors (cosmic-proposed/primary) [0.00~git20180920.1.0ca053f-1]
-queuebot:#ubuntu-release- Unapproved: swt-gtk (cosmic-proposed/universe) [3.8.2-5 => 3.8.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted swt-gtk [sync] (cosmic-proposed) [3.8.2-6]
-queuebot:#ubuntu-release- Unapproved: libcrypt-ssleay-perl (cosmic-proposed/universe) [0.73.06-1 => 0.73.06-1build1] (no packageset)
<jbicha> oh freeze time
-queuebot:#ubuntu-release- Unapproved: accepted libcrypt-ssleay-perl [source] (cosmic-proposed) [0.73.06-1build1]
#ubuntu-release 2018-09-25
<handsome_feng> quit
-queuebot:#ubuntu-release- Unapproved: python-flake8 (cosmic-proposed/universe) [3.5.0-1 => 3.5.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-flake8 [source] (cosmic-proposed) [3.5.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.36.3 => 0.40~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: xfce4-battery-plugin (cosmic-proposed/universe) [1.1.0-1 => 1.1.1-1] (xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: xfce4-cpufreq-plugin (cosmic-proposed/universe) [1.2.0-1 => 1.2.1-1] (xubuntu) (sync)
<rbasak> infinity: I was going to upload mysql-5.7 this morning - to revert the incorrect sync, and that should land the latest MRE (includes a bunch of CVE fixes) into the release pocket, currently blocked because the sync caused ac omponent mismatch.
<rbasak> infinity: so consider that a freeze exception request, or do you wnat me to wait?
<rbasak> Admittedly it will fire off a pile of reverse dep8 tests that will take time to migrate so you may not want that.
<rbasak> (and occasionally failures and general pain - though mysql dep8 is pretty good nowadays as we disable flaky tests after sending bugs for them upstream)
-queuebot:#ubuntu-release- Unapproved: racket-mode (cosmic-proposed/universe) [20180908+0+e8850c6-1ubuntu1 => 20180919git0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted racket-mode [sync] (cosmic-proposed) [20180919git0-1]
<LocutusOfBorg> ^^ this one is an internal vlc library, the soname changed, but the code looks like ABI safe... anyhow, I didn't see new features
-queuebot:#ubuntu-release- Unapproved: liblivemedia (cosmic-proposed/universe) [2018.08.05-1 => 2018.09.18-1] (kubuntu) (sync)
<LocutusOfBorg> ^^ this one actually :p
-queuebot:#ubuntu-release- New binary: django-mailman3 [amd64] (cosmic-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted django-mailman3 [amd64] (cosmic-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: rejected gnome-shell-extension-multi-monitors [sync] (cosmic-proposed) [0.00~git20171014.1.df5d6e4-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-text [amd64] (cosmic-proposed) [4.7.3-2]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-multi-monitors [sync] (cosmic-proposed) [0.00~git20180920.1.0ca053f-1]
-queuebot:#ubuntu-release- New: accepted dds [amd64] (cosmic-proposed) [2.9.0-3]
-queuebot:#ubuntu-release- New: accepted dds [s390x] (cosmic-proposed) [2.9.0-3]
-queuebot:#ubuntu-release- New: accepted libopenshot [arm64] (cosmic-proposed) [0.2.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [i386] (cosmic-proposed) [0.2.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted dds [i386] (cosmic-proposed) [2.9.0-3]
-queuebot:#ubuntu-release- New: accepted libopenshot [armhf] (cosmic-proposed) [0.2.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [amd64] (cosmic-proposed) [0.2.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [s390x] (cosmic-proposed) [0.2.2+dfsg1-1]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-multi-monitors [amd64] (cosmic-proposed/universe) [0.00~git20180920.1.0ca053f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postorius [amd64] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libnet-ssleay-perl (cosmic-proposed/main) [1.85-2ubuntu1 => 1.85-2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: stunnel4 (cosmic-proposed/universe) [3:5.44-1ubuntu3 => 3:5.44-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stunnel4 [source] (cosmic-proposed) [3:5.44-1ubuntu4]
<LocutusOfBorg> xnox, shouldn't libnet-ssleay-perl just go back in sync with debian? I don't think a no-change rebuild will fix anything
-queuebot:#ubuntu-release- Unapproved: libnet-ssleay-perl (cosmic-proposed/main) [1.85-2ubuntu1 => 1.85-2.1~build1] (core)
<xnox> LocutusOfBorg, you are wrong, as I have patches uploaded in libnet-ssleay-perl before I uploaded openssl1.1.1 and yes a rebuild will fix autopkgtest.
-queuebot:#ubuntu-release- Unapproved: liblivemedia (cosmic-proposed/universe) [2018.08.05-1 => 2018.09.18-1] (kubuntu) (sync)
<xnox> LocutusOfBorg, and no, it cannot go back in sync, because debian's and ubuntu's openssl 1.1.1 are different, and thus need different test suite expectations.
<LocutusOfBorg> ack, so please reject 1.85-2.1~build1
<xnox> LocutusOfBorg, i'm not an archive admin. Why did you upload a package and drop my delta, without talking to me, cause I hold TIL?
<xnox> that's not the process we follow when merging and dropping deltas....
<LocutusOfBorg> ehm I saw after that you did upload it (because of unapproved)
<LocutusOfBorg> I was just going to help in openssl
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-multi-monitors [amd64] (cosmic-proposed) [0.00~git20180920.1.0ca053f-1]
-queuebot:#ubuntu-release- New: accepted postorius [amd64] (cosmic-proposed) [1.2.2-2]
<xnox> LocutusOfBorg, please don't help with openssl. 1.85-2.1~build1 is very odd version number given that 2.1 is not in debian.
<LocutusOfBorg> I owned the previous openssl merge, so I care about the new one migrate :)
<LocutusOfBorg> I even had talks in security channel about the new one
<xnox> LocutusOfBorg, you stole last openssl merge from me without talking?! =)
<LocutusOfBorg> anyway, I'm happy to give it to you *forever* :D
<xnox> LocutusOfBorg, Did you not see https://launchpad.net/ubuntu/+source/libnet-ssleay-perl/1.85-2ubuntu1 since 23rd of September?
<LocutusOfBorg> xnox, I didn't see the "ubuntu2" one
<LocutusOfBorg> you dropped the patch, so reintroducing it seemed to be the right thing to do?
<xnox> LocutusOfBorg, but dropping the ubuntu1 delta is wrong, and you didn't talk to me about it.
<xnox> LocutusOfBorg, no, i dropped it in preporation for openssl 1.1.1.... which is not bumping security levels, unlike debian.
<xnox> LocutusOfBorg, never drop patches without talking to the last uploader TIL.
<LocutusOfBorg> ok
<xnox> LocutusOfBorg, seriously, not the first time, when you try to be helpful, and actively harming things.
<LocutusOfBorg> but.... how long will that delta last? will we have a new openssl transition after cosmic release, bumping security levels?
<xnox> LocutusOfBorg, please read openssl 1.1.1 changelog in ubuntu.
<xnox> the FFe
<xnox> and check the ppa:xnox/ubuntu/openssl
<xnox> LocutusOfBorg, no, we will not bump security levels like debian did. as it breaks internet.
<xnox> LocutusOfBorg, we want to mix&match clients between xenial, bionic, and cosmic and be able to talk to each other over any TLS protocols.
<xnox> arbitrarily bumping minimum requirements for existing certificate sizes is not helpful.
<LocutusOfBorg> why is debian doing this? I would like to ask them to revert the change?
<LocutusOfBorg> internet won't heal by itself just because debian does enforce stuff
<xnox> read the mega-RC bug about that in debian with multiples of blocking bugs on top of that
<LocutusOfBorg> it might work with chrome, but not with debian
<LocutusOfBorg> yep, I discussed this with -hardened already, better look for new messages then
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907015
<ubot5> Debian bug 907015 in src:openssl "openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed" [Serious,Open]
<xnox> the way i'm uploading openssl 1.1.1 into ubuntu avoids all that.
<xnox> but our and debian timelines are different.
<LocutusOfBorg> the bug seems to not say "we break internet", but rather "we break reverse-deps", but I might be read it wrongly probably
<xnox> i think openssl maintainers in debian do want to ship it with bumped min versions, but they have more time until release to fix that.
<LocutusOfBorg> so no backport for new openssl
<LocutusOfBorg> for debian I mean, bad thing
<xnox> LocutusOfBorg, one needs to dig into individual bugs. e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907528 client fails to connect
<ubot5> Debian bug 907528 in synergy "synergy: low grade TLS certificate generation, now unusable in unstable" [Grave,Open]
<xnox> well, if they backout openssl changes, like done in ubuntu package, it would be backportable.
<LocutusOfBorg> hello apw, can you please reject libnet-ssleay-perl 1.85-2.1~build1?
<LocutusOfBorg> xnox, they don't maintain backport with such huges changes...
<LocutusOfBorg> anyway, thanks for the explanation, I won't waste your time anymore, I go fixing other things
-queuebot:#ubuntu-release- Unapproved: rejected libnet-ssleay-perl [source] (cosmic-proposed) [1.85-2.1~build1]
<apw> LocutusOfBorg, ^
<LocutusOfBorg> <3
<xnox> apw, thanks!
<ginggs> would someone please 'force-badtest pandas/0.23.3-1fakesync1ubuntu1' ? - i believe it has regressed in release http://autopkgtest.ubuntu.com/packages/p/pandas/cosmic/amd64
<ginggs> it slipped through the cracks in debian too https://ci.debian.net/packages/p/pandas/testing/amd64/ - i suspect it was the python2.7 upload
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (cosmic-proposed/universe) [1.0.1+dfsg-1ubuntu1 => 1.0.2+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-openssl [source] (cosmic-proposed) [1.0.2+dfsg-1ubuntu1]
<ginggs> xnox: you stole my r-cran-openssl merge! :D
<xnox> ginggs, true =) did not drop delta ;-)
<ginggs> xnox: good man!
-queuebot:#ubuntu-release- Unapproved: python2.7 (cosmic-proposed/main) [2.7.15-4ubuntu1 => 2.7.15-4ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.0-6 => 3.7.0-6build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.6 (cosmic-proposed/main) [3.6.6-4 => 3.6.6-4build1] (core)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (cosmic-proposed/main) [2.5.1-5ubuntu3 => 2.5.1-5ubuntu4] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: qbittorrent (cosmic-proposed/universe) [4.0.3-1build1 => 4.1.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qbittorrent [sync] (cosmic-proposed) [4.1.3-1]
-queuebot:#ubuntu-release- Unapproved: gvfs (cosmic-proposed/main) [1.38.0-2ubuntu1 => 1.38.0-2ubuntu2] (desktop-core)
<jibel> infinity, latest desktop image is broken. I filed bug 1794280
<ubot5> bug 1794280 in gdm3 (Ubuntu) "gdm doesn't start on a fresh installation of Cosmic Desktop" [Undecided,New] https://launchpad.net/bugs/1794280
<xnox> jibel, what language is "Aucun affichage disponible" ?
<xnox> also with virtmanager i had to lately use a better video card to get it going =/ however if install worked... gdm should work...
<apw> xnox, french ?
<xnox> ah, yes, true.
 * xnox fails at operating google
<jibel> xnox, french
<jibel> it means "no display available"
-queuebot:#ubuntu-release- Unapproved: xorg-lts-transitional (cosmic-proposed/universe) [3:14.3 => 3:14.4] (ubuntukylin)
<xnox> jibel, my understanding was that the issue around gdm3 failing to appear was fixed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1786872
<ubot5> Ubuntu bug 1786872 in gdm3 (Ubuntu) "[regression] Cosmic login screen never appears on about 50% of boots" [High,Fix released]
<xnox> jibel, does rebooting at all help? or as cpaelzer was debugging earlier in another ticket, even restarting gdm3 might eventually work.
<jibel> xnox, no it's reproducible, I tried another graphics driver too
<jibel> I didn't try to restart gdm3 only though
<xnox> ok
<xnox> might be something new, as the new gdm3 is in.
<xnox> jibel, systemd autopkgtest used to test gdm3 comming up, but i dropped that, due to above mentioned bug report blocking systemd for most of the cosmic release cycle.
<xnox> well there were other issues tooo....
-queuebot:#ubuntu-release- Unapproved: graphicsmagick (cosmic-proposed/universe) [1.3.30-1 => 1.3.30+hg15796-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (cosmic-proposed) [2.7.15-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.0-6build1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.6-4build1]
-queuebot:#ubuntu-release- Unapproved: swt4-gtk (cosmic-proposed/universe) [4.6.3-2 => 4.7.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [source] (cosmic-proposed) [2.5.1-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: yelp-xsl (cosmic-proposed/main) [3.30.0-1 => 3.30.1-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted swt4-gtk [sync] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- Unapproved: gnumeric (cosmic-proposed/universe) [1.12.41-1 => 1.12.43-1] (desktop-extra) (sync)
<jibel> xnox, completely new installation and the machine boots
<xnox> charming
<jibel> well, it booted on second boot and rebooted by itself on first ...
<infinity> rbasak: No one's stopping you from uploading.
-queuebot:#ubuntu-release- Unapproved: accepted libnet-ssleay-perl [source] (cosmic-proposed) [1.85-2ubuntu2]
<rbasak> infinity: perhaps but without an FFe that violates the freeze, no? Do you actually want it, or shall I wait?
<infinity> rbasak: Are we confusing two freezes now? :P
<infinity> rbasak: If it violates *feature* freeze, file a bug and explain why.
<rbasak> Oh yeah, sorry.
<rbasak> An Fe then :)
<infinity> rbasak: If it violates beta freeze, it'll just sit in the queue.  No big.
<rbasak> OK
<infinity> (Or I might let it out of the queue and let britney block it)
-queuebot:#ubuntu-release- Unapproved: mailman3 (cosmic-proposed/universe) [3.1.1-10ubuntu1 => 3.2.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mailman3 [source] (cosmic-proposed) [3.2.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: easyspice (cosmic-proposed/multiverse) [0.6.8-2.1build1 => 0.6.8-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted easyspice [sync] (cosmic-proposed) [0.6.8-3]
-queuebot:#ubuntu-release- New sync: golang-github-wellington-go-libsass (cosmic-proposed/primary) [0.9.2+git20180624.615eaa4-1]
-queuebot:#ubuntu-release- New sync: golang-github-bep-go-tocss (cosmic-proposed/primary) [0.5.0-1]
-queuebot:#ubuntu-release- Unapproved: mailman-hyperkitty (cosmic-proposed/universe) [1.1.0-7 => 1.1.0-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mailman-hyperkitty [sync] (cosmic-proposed) [1.1.0-8]
-queuebot:#ubuntu-release- Unapproved: gnome-builder (cosmic-proposed/universe) [3.30.0-1ubuntu1 => 3.30.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Cosmic Beta] (20101020ubuntu552) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Cosmic Beta] (20101020ubuntu552) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Cosmic Beta] (20101020ubuntu552) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Cosmic Beta] (20101020ubuntu552) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Cosmic Beta] (20101020ubuntu552) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Cosmic Beta] (20101020ubuntu552) has been added
<infinity> jibel: I'm spinning beta builds now, which will still include that bug (I assume).  If the fix is in gdm, only Ubuntu will need a respin.  If it's elsewhere, whee.  But I trust your team to dig to the bottom of it.
-queuebot:#ubuntu-release- Unapproved: activemq (cosmic-proposed/universe) [5.15.4-2 => 5.15.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted activemq [sync] (cosmic-proposed) [5.15.6-1]
-queuebot:#ubuntu-release- Unapproved: strongswan (cosmic-proposed/main) [5.6.3-1ubuntu1 => 5.6.3-1ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu1 => 1.1.1-1ubuntu2] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (cosmic-proposed/main) [2.059-1 => 2.060-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: mailman-suite (cosmic-proposed/universe) [0+20170523-16 => 0+20180916-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mailman-suite [sync] (cosmic-proposed) [0+20180916-1]
-queuebot:#ubuntu-release- Unapproved: cinder (cosmic-proposed/main) [2:13.0.0-0ubuntu2 => 2:13.0.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: hyperkitty [amd64] (cosmic-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.0-1~18.04 => 3.7.0-7] (no packageset)
<jibel> infinity, k, I'll see if it happens again with the new image
-queuebot:#ubuntu-release- New: accepted golang-github-bep-go-tocss [sync] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted hyperkitty [amd64] (cosmic-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-wellington-go-libsass [sync] (cosmic-proposed) [0.9.2+git20180624.615eaa4-1]
-queuebot:#ubuntu-release- Unapproved: accepted libio-socket-ssl-perl [sync] (cosmic-proposed) [2.060-3]
-queuebot:#ubuntu-release- Unapproved: python-gnupg (cosmic-proposed/universe) [0.4.3-1 => 0.4.3-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: golang-github-wellington-go-libsass [amd64] (cosmic-proposed/universe) [0.9.2+git20180624.615eaa4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-wellington-go-libsass [amd64] (cosmic-proposed) [0.9.2+git20180624.615eaa4-1]
-queuebot:#ubuntu-release- Unapproved: mysql-5.7 (cosmic-proposed/main) [5.7.23-1 => 5.7.23-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (cosmic-proposed) [1.1.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-gnupg [source] (cosmic-proposed) [0.4.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (cosmic-proposed/main) [18.04.1-0ubuntu1 => 18.10.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: golang-github-bep-go-tocss [amd64] (cosmic-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Unapproved: hugo (cosmic-proposed/universe) [0.47.1-1 => 0.47.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hugo [sync] (cosmic-proposed) [0.47.1-2]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Cosmic Beta] (20180925) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Cosmic Beta] (20180925.1) has been added
<tjaalton> infinity: hi, ok to upload mesa 18.2.1 now that the FFE is approved? there are two new binaries to allow "native" Direct3D for wine. I believe this fixes a crasher on virtualbox guest
<tjaalton> i mean the new version fixes the crasher, not the new binaries which are just for new functionality
<tjaalton> and that xorg-lts-transitional update would unblock x-x-v-amdgpu
<tjaalton> which is already in debian testing
-queuebot:#ubuntu-release- Unapproved: gnome-games-app (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (no packageset) (sync)
<tjaalton> hmm, guess I'll just upload mesa, since the ffe is approved. it'll end up on the queue anyway aiui
-queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (cosmic-proposed/universe) [3.28.5-1 => 3.30.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.0-0ubuntu3 => 2:13.0.0-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Cosmic Beta] (20180925) has been added
<wxl> um lubuntu has a livefs fail on i386 but no log?? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/cosmic/lubuntu/+build/146084
<cjwatson> That can happen if the builder fails in such a way that means buildd-manager can't fetch the log at the end of the build.
<cjwatson> Probably best to just re-request the build.
<wxl> cjwatson: i would but it's not even listed. none of the i386 are it seems, except for netboot, base, and xubuntu
-queuebot:#ubuntu-release- New sync: os-autoinst (cosmic-proposed/primary) [4.5.1527308405.8b586d5-1]
<Eickmeyer> infinity: I just got a fail mail about the last image for Studio, but no context. Should I be worried?
<Eickmeyer> Nvm, just read the backlog here.
<Eickmeyer> wxl: I got the same for amd64 of Studio.
<slangasek> wxl: if there are manifest mismatches for what the flavors plan to release, that seems like something we should also sort out
-queuebot:#ubuntu-release- New: accepted os-autoinst [sync] (cosmic-proposed) [4.5.1527308405.8b586d5-1]
<wxl> slangasek: given our FFe lubuntu may have some, but i don't think that really applies to the other flavors. and that's not necessarily related, no?
<slangasek> wxl: I mean the iso tracker manifest
<slangasek> if you're expecting to release i386 images for 18.10 and you don't have a button for that, we should figure that out :)
<wxl> slangasek: what i'm saying it nearly all flavors don't have a button for that
<slangasek> nearly all flavors aren't releasing it
<wxl> it seemed to me that Eickmeyer was sort of suggesting studio was expecting to release i386, or at least surprised it wasn't there
<wxl> i think perhaps the assumption was that no one's doing it, so we're not doing it, but it's been in our dailies
<slangasek> he was saying that the amd64 ubuntustudio build failed with the same problem as the lubuntu i386
<wxl> oh huh ok i read that wrong. weird.
<slangasek> anyway, until the initial build succeeds, there's no retry button on the milestone page; that's the only issue
<Eickmeyer> wxl: No, not expecting to release i386, but got a fail mail about amd64 20189025 image.
<Eickmeyer> But no log.
<slangasek> so I'll just poke the button on the daily page
<wxl> anywho we plan to release i386 unless we don't have sufficient testers
<Eickmeyer> slangasek is right.
<wxl> and if we don't, i would vote that we stop doing them altogether as well
<Eickmeyer> So, pretty much a different problem.
<wxl> i'm not about to fight a losing battle (see ppc)
<wxl> yeah sorry got confused there, Eickmeyer. my bad
<Eickmeyer> No worries.
<Eickmeyer> I was confused too.
<slangasek> anyway I've manually triggered some rebuilds
-queuebot:#ubuntu-release- New binary: os-autoinst [s390x] (cosmic-proposed/universe) [4.5.1527308405.8b586d5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: os-autoinst [ppc64el] (cosmic-proposed/universe) [4.5.1527308405.8b586d5-1] (no packageset)
<slangasek> tjaalton: xorg-lts-transitional in cosmic is creating xserver-xorg-video-ati-hwe-18.04-dbg and xserver-xorg-video-radeon-hwe-18.04-dbg binary packages that depend on the NBS xserver-xorg-video-radeon-dbg... and which didn't exist at all in bionic, so surely shouldn't be around for transitional purposes
-queuebot:#ubuntu-release- Unapproved: astroid (cosmic-proposed/main) [2.0.4-1 => 2.0.4-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted astroid [sync] (cosmic-proposed) [2.0.4-2]
-queuebot:#ubuntu-release- Unapproved: rejected python3.7 [source] (bionic-proposed) [3.7.0-7]
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.0-6build1 => 3.7.0-7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.0-7]
<tjaalton> slangasek: how's that possible? the previous upload dropped them
<slangasek> ah? let's see
<tjaalton> slangasek: oh, if you mean that -hwe-18.04 doesn't exist in bionic then that's true, for some time still
<slangasek> tjaalton: I'm working from http://people.canonical.com/~ubuntu-archive/nbs.html
<tjaalton> slangasek: ok, so those are from 3:14.2, you can drop them
<tjaalton> .3 was uploaded last week to unblock x-x-v-ati which it did
<tjaalton> didn't realize old binaries would still be around
<slangasek> tjaalton: were they not dropped from debian/control? I'm not sure why nbs isn't showing them as removable
<tjaalton> slangasek: hmm, looks like the source package still had the old d/control, which doesn't seem to be autogenerated during source build, d'oh
<slangasek> ok
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Cosmic Beta] (20180925.1) has been added
<wxl> thx slangasek whatever you did fixed the problem :)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu4 => 2.02+dfsg1-5ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.9 => 1.10] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (cosmic-proposed/main) [1.106 => 1.107] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Cosmic Beta] (20180925.1) has been added
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.5]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.6]
-queuebot:#ubuntu-release- Unapproved: mesa (cosmic-proposed/main) [18.1.5-1ubuntu1 => 18.2.1-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.5 => 2.02-2ubuntu8.5] (core)
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (cosmic-proposed/universe) [2.1.1-0ubuntu1 => 2.1.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-openssl [source] (cosmic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (bionic-proposed) [3.0.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: groovy (cosmic-proposed/universe) [2.4.15-1ubuntu1 => 2.4.15-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted groovy [source] (cosmic-proposed) [2.4.15-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.5 => 2.02-2ubuntu8.5] (core)
#ubuntu-release 2018-09-26
<tsimonq2> infinity, slangasek: I'm drained of energy being under the weather but Lubuntu has this seed issue we just can't seem to work out that's left over from the whole split seed thing. jbicha thinks it's tasksel, which very well could be the case because the darn package hasn't been touched since Artful, and I've only gotten as far as to see it doesn't reflect the Bazaar -> Git move. wxl can't make
<tsimonq2> heads or tails of `ubuntu-seeds.pl` and I need to prioritize my health, but whatever the root cause is, it's a Release Blocker for Lubuntu. I understand it's likely too late for the Beta, fine, but for the final images someone should go through and port that over.
<tsimonq2> Xubuntu will probably see effects soon, if Xubuntu Core didn't exist before Artful, and we will too because the Platform seed was switched over. Please, can I get some help here?
<tsimonq2> Whatever it is, it's causing packages to exist which should exist in the dailies, e.g.. in the case of xfsprogs not coming in at all.
<tsimonq2> (er, my wording is off, it is causing packages to exist in a case where this is occurong)
<tsimonq2> *occurring
-queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [17.12.1-0ubuntu6 => 18.06.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (cosmic-proposed) [18.06.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-builder (cosmic-proposed/universe) [3.30.0-1ubuntu1 => 3.30.1-2ubuntu1] (desktop-extra)
<slangasek> tsimonq2: tasksel uploaded
-queuebot:#ubuntu-release- Unapproved: tasksel (cosmic-proposed/main) [3.34ubuntu11 => 3.34ubuntu12] (core)
-queuebot:#ubuntu-release- Unapproved: rejected liblivemedia [sync] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (cosmic-proposed) [1.38.0-2ubuntu2]
<tsimonq2> slangasek: many thanks
-queuebot:#ubuntu-release- Unapproved: rejected gnome-builder [source] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (cosmic-proposed) [2:13.0.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.0-0ubuntu4]
<jbicha> slangasek: new gnome-builder is going to fail its build tests on i386 so I don't know, maybe you want to reject it too
<slangasek> jbicha: well, if a fixed upload was imminent I might; but the other reject was simply because it was superseded before it made it through the queue
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (cosmic-proposed) [3.30.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.36 => 2.408.37] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: apturl (bionic-proposed/main) [0.5.2ubuntu14.1 => 0.5.2ubuntu14.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mir (cosmic-proposed/main) [0.32.1-0ubuntu1 => 1.0.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: colord (cosmic-release/main) [1.3.3-2build1 => 1.4.3-3] (core) (sync)
<doko> xnox: looks like all the openssl related autopkg tests need a retrigger against all-proposed
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (cosmic-proposed/universe) [1.1.5-0ubuntu1 => 1.1.6-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: pylint (cosmic-proposed/universe) [1.9.2-1 => 2.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pylint [sync] (cosmic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [source] (cosmic-proposed) [1.0.0-0ubuntu1]
<doko> Laney: http://autopkgtest.ubuntu.com/packages/c/cross-toolchain-base/cosmic/amd64  any idea why it run under three hours in some cases, and above 12 hours in others?
<Laney> doko: not really, are you sure it's not a bug in the package itself that it sometimes gets into a bad state?
<Laney> if you look at the "--security-groups" value at the top of each log you can see which cloud it ran on, maybe there's a correlation there
-queuebot:#ubuntu-release- Unapproved: ukui-indicators (cosmic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (ubuntukylin)
<doko> I wouldn't know why. it's just a rebuild for one cross toolchain
<Laney> and I guess maybe look at what happens in the logs differently between the good and bad cases
<Laney> might give us some hints
<doko> no, both lcy and lgw involved in both short and long builds
<doko> I could add some timestamps in the build log to see if a particular package just builds slowly
<xnox> doko, whilst it looks like python3.6 and 3.7 will be fine, i don't think retries will help in 2.7 case =( https://paste.ubuntu.com/p/zz6dm5Nj9P/
<doko> xnox: will update to the branch later today. there are some new openssl related changes
<doko> fyi, ruby2.5 ftbfs on amd64
<xnox> doko, well, it doesn't =)
<xnox> doko, https://bugs.launchpad.net/ubuntu/+source/ruby2.5/+bug/1794059 after 4 retries it built....
<ubot5> Ubuntu bug 1794059 in strongswan (Ubuntu) "Slow IO on intel arches in builders, causes FTBFS" [Undecided,Confirmed]
<xnox> affects ruby2.5 too
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1020.23]
<cascardo> we are also seeing lots of timeouts on ADT, and that's preventing our latest cosmic kernel to migrate
<xnox> doko, right, and i think i want python3.6 update too, the stuff that uses SSL_CTX_set_post_handshake_auth@OPENSSL_1_1_1 1.1.1 symbol. I see patches for that in master, 3.7 and 3.6. But not 2.7 =( https://bugs.python.org/issue34670
<xnox> and that makes the python gain a >= 1.1.1 dep too
<tdaitx> need an archive admin to remove gradle-debian-helper 2.0.1 from -proposed, it's blocking groovy and I actually have a merge request for gradle 2.0.1ubuntu1 (LP: #1794122) but groovy needs to go first
<ubot5> Launchpad bug 1794122 in gradle-debian-helper (Ubuntu) "Please merge gradle-debian-helper 2.0.1 from Debian" [Undecided,New] https://launchpad.net/bugs/1794122
-queuebot:#ubuntu-release- Unapproved: packagekit (cosmic-proposed/main) [1.1.10-1ubuntu5 => 1.1.10-1ubuntu6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu8 => 239-7ubuntu9] (core)
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (cosmic-proposed/main) [1.7-0ubuntu6 => 1.7-0ubuntu7] (core)
<fossfreedom_> Quick question for the 18.10 iso's  - at the end of the install I see "Please remove the installation medium, then reboot" - in 18.04 you also were advised to press enter to reboot.  Is this a deliberate change?  Just wondering if the QA tracker scripts needs updating
<doko> RAOF: yaml-cpp needs a MIR
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-137.163] (core, kernel)
<xnox> fossfreedom_, there are two messages.
<xnox> fossfreedom_, the message you see - means that plymouth has failed on your system.
<xnox> fossfreedom_, we added this one as a fallback, when the other one does not work.
<fossfreedom_> ah - makes more sense
<xnox> fossfreedom_, previously people saw black screen or corrupted screen and complained that "no message appeared"
<xnox> fossfreedom_, this is now "fixed"
<maltris> Cheers! I am interested in when this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789653 gets merged into xenial-updates? Verification seems to be there. Is there anything missing I can contribute?
<ubot5> Ubuntu bug 1789653 in linux (Ubuntu) "regression with EXT4 file systems and meta_bg flag" [Medium,In progress]
<fossfreedom_> xnox: should I raise an issue on maybe plymouth - or is this being tracked?
<xnox> fossfreedom_, no, there is no issue. and everything is working as expected.
<xnox> fossfreedom_, we had a laptop during last release sprint which would fail to show shutdown splash half of the time; hence we added this extra message - meaning a user gets a message with an instruction always now.
-queuebot:#ubuntu-release- Unapproved: python3.6 (cosmic-proposed/main) [3.6.6-4build1 => 3.6.6-4ubuntu1] (core)
<fossfreedom_> xnox: cheers
-queuebot:#ubuntu-release- Unapproved: gnome-usage (cosmic-proposed/universe) [3.28.0-2 => 3.30.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pipewire (cosmic-proposed/universe) [0.2.3-1 => 0.2.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-usage [sync] (cosmic-proposed) [3.30.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted pipewire [sync] (cosmic-proposed) [0.2.3-3]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-workspaces-to-dock (cosmic-proposed/universe) [48-1 => 48-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-workspaces-to-dock [sync] (cosmic-proposed) [48-2]
-queuebot:#ubuntu-release- New: accepted os-autoinst [ppc64el] (cosmic-proposed) [4.5.1527308405.8b586d5-1]
-queuebot:#ubuntu-release- New: accepted os-autoinst [s390x] (cosmic-proposed) [4.5.1527308405.8b586d5-1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.6-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-bep-go-tocss [amd64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- Unapproved: python2.7 (cosmic-proposed/main) [2.7.15-4ubuntu2 => 2.7.15-4ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: udisks2 (cosmic-proposed/main) [2.7.6-3ubuntu2 => 2.7.6-3ubuntu3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (cosmic-proposed) [2.7.15-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: mate-indicator-applet (cosmic-proposed/universe) [1.20.1-1 => 1.20.1-2ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.0-7 => 3.7.0-7ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.0-7ubuntu1]
<mitya57> Wimpress: ^^ 1.20.1-2ubuntu0 is a semantically invalid version number, you probably meant 1.20.1-1ubuntu1
<Wimpress> mitya57: Can you reject it?
<Wimpress> xnox: Please can you reject mate-indicator-applet 1.20.1-2ubuntu0 and I'll reupload with the correct version.
 * mitya57 canât reject it, just noticed it in the log
<xnox> Wimpress, no i cannot reject that either, you need an archive admin.
<xnox> !archive-admin please remove.... oh wait there is not archive-admin highligh =)
<ubot5> xnox: I am only a bot, please don't think I'm intelligent :)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (cosmic-proposed/main) [2:10.3.0-0ubuntu2 => 2:10.3.0-0ubuntu3] (edubuntu, ubuntu-cloud, ubuntu-server)
<cpaelzer> ah right that is unapproved now due to the freeze
<Wimpress> I need an update mate-indicator-applet in cosmic. It fixes a serious issue.
<Wimpress> Happy to reload with a correct version for the deb if an admin can reject the recent upload.
-queuebot:#ubuntu-release- Unapproved: mate-desktop (cosmic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.3-2] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: marco (cosmic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.2-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-panel (cosmic-proposed/universe) [1.20.1-3ubuntu1 => 1.20.3-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-backgrounds (cosmic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.0-2] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-themes (cosmic-proposed/universe) [3.22.16-4ubuntu1 => 3.22.18-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (cosmic-proposed/universe) [28ubuntu4 => 28ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (cosmic-proposed/universe) [1.20.2-2ubuntu1 => 1.20.3-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross-ports [source] (cosmic-proposed) [28ubuntu5]
-queuebot:#ubuntu-release- Unapproved: mate-power-manager (cosmic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.2-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: atril (cosmic-proposed/universe) [1.20.1-2ubuntu2 => 1.20.2-1] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: eom (cosmic-proposed/universe) [1.20.0-2ubuntu1 => 1.20.1-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-utils (cosmic-proposed/universe) [1.20.0-0ubuntu1 => 1.20.1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: pluma (cosmic-proposed/universe) [1.20.1-3ubuntu1 => 1.20.2-1] (ubuntu-mate, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (cosmic-proposed/universe) [1.20.1-1 => 1.20.2-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: strongswan (cosmic-proposed/main) [5.6.3-1ubuntu1 => 5.6.3-1ubuntu2] (ubuntu-server)
<Wimpress> Laney: You are an archive admin, right?
<Laney> no
<Wimpress> #sadface
<Laney> tell me about it
<Wimpress> I have a face. It looks sad.
-queuebot:#ubuntu-release- Unapproved: networkd-dispatcher (cosmic-proposed/main) [1.7-0ubuntu6 => 1.7-0ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: nginx (cosmic-proposed/main) [1.15.3-0ubuntu1 => 1.15.4-0ubuntu1] (ubuntu-server)
<Wimpress> didrocks You are an archive admin, right?
<teward> if someone could Approve the NGINX upload to proposed, that'd be great, it got an FFe approval from sil2100 in the bug https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1794321
<ubot5> Ubuntu bug 1794321 in nginx (Ubuntu) "[FFe Needed] Update NGINX in Cosmic to 1.15.4 for bugfixes" [Undecided,Triaged]
<apw> Wimpress, you are looking fora  reject ?
<Wimpress> apw: Yes please. Could you reject mate-indicator-applet 1.20.1-2ubuntu0.
<Wimpress> And I'll upload again with the correct deb version.
<cyphermox> could someone in the SRU team please review netplan.io and ledmon in the bionic unapproved queue?
-queuebot:#ubuntu-release- Unapproved: rejected mate-indicator-applet [source] (cosmic-proposed) [1.20.1-2ubuntu0]
<Wimpress> apw: Thank you.
-queuebot:#ubuntu-release- Unapproved: amavisd-new (cosmic-proposed/main) [1:2.11.0-1ubuntu1 => 1:2.11.0-1ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mate-indicator-applet (cosmic-proposed/universe) [1.20.1-1 => 1.20.1-1ubuntu1] (ubuntu-mate)
<Wimpress> cyphermox: Please could you accept mate-indicator-applet 1.20.1-1ubuntu1?
<Wimpress> It include a critical fix for Ubuntu MATE 18.10. For which I'll need to respin the iso.
<cyphermox> Wimpress: sorry, I don't have that kind of access
<Wimpress> cyphermox: OK. Can you suggest someone I can seek assistance from?
<cyphermox> you need someone in the release team, if you say it's a critical fix (and it certainly sounds plausible given it's mate-indicator-applet), then it should be fine to land
<cyphermox> depends who's on
<jbicha> please accept tasksel/cosmic since it tries to fix an important issue for Lubuntu
-queuebot:#ubuntu-release- Unapproved: mate-dock-applet (cosmic-proposed/universe) [0.86-2 => 0.87-1] (ubuntu-mate) (sync)
<apw> Wimpress, i can have a look at that
<jbicha> I don't know if it's worth respinning everything just for that but at least it can be ready if we do need a respin
<Wimpress> apw: Thank you!
<cyphermox> jbicha: at least it will be available, doesn't necessarily require a respin
<apw> Wimpress, if i read this right the existing package is utterly broken ... right ?
<jbicha> oh I see, tasksel isn't seeded on the desktop images
<cyphermox> jbicha: well, it's a bit more complicated than that, but yeah ;)
-queuebot:#ubuntu-release- Unapproved: accepted mate-indicator-applet [source] (cosmic-proposed) [1.20.1-1ubuntu1]
<teward> apw: any chance while you're in there that you can do an accept on nginx/cosmic since it already got its FFe approval?
<Wimpress> apw: Thanks
<teward> if not, that's fine just thought I'd ask :)
-queuebot:#ubuntu-release- Unapproved: unity (cosmic-proposed/universe) [7.5.0+18.10.20180827-0ubuntu1 => 7.5.0+18.10.20180926.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (cosmic-proposed) [7.5.0+18.10.20180926.2-0ubuntu1]
<apw> teward, normally that would be a slam dunk i am sure, but we are in beta-freeze through thursday
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Cosmic Beta] has been marked as ready
<infinity> jbicha: tasksel isn't even on (most) media.
<infinity> jbicha: Oh, you got there.
<infinity> tsimonq2: From your (not entirely clear) description of your problem, I'm not sure how you think tasksel could relate at all, since it's not involved in either the building or installation of desktop dailies.
<teward> apw: so then I have to wait to Thursday though nginx isn't on the seeds that I'm aware of?
<infinity> teward: It's seeded in server.
<teward> huh that must be a recent change
<teward> infinity: missed that, but i see it now
<teward> thanks i'll wait
<apw> right, would have auto-accepted if it wasn't seeded
<teward> infinity: apw: none of these issues it's fixing are major enough to break beta freeze, however after beta freeze if we could get the fixes in that'd be great
<teward> (I missed the beta freeze announcement whoops?:)
<infinity> teward: Yeah, it'll get in.
<teward> +1 thanks.  (I'll have to see when it was added to the seeds...)
<teward> (since apparently I wasn't aware of that or missed it (or forgot because I"m overworked))
<tjaalton> infinity: mesa on the queue fixes virtualbox guest not booting up properly, would be nice to have that in the beta if possible
<infinity> tjaalton: That means respinning literally every image.
<infinity> tjaalton: If it's just virtualbox, my carefactor is low.
<tjaalton> ok
<jibel> infinity, desktop team carefactor is rather high
<infinity> jibel: Is this the bug you filed?  (which was qemu, not vbox...)
<jibel> infinity, it's bug 1792932
<ubot5> bug 1792932 in xorg-server (Ubuntu Cosmic) "Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed." [High,Triaged] https://launchpad.net/bugs/1792932
-queuebot:#ubuntu-release- Unapproved: gnome-builder (cosmic-proposed/universe) [3.30.1-2ubuntu1 => 3.30.1-2ubuntu2] (desktop-extra)
<infinity> And a lovely 3.4MB diff.
<LocutusOfBorg> infinity, if this can make you feel better, mesa in the queue switches to llvm-7, so llvm-6 can go in universe from main
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (cosmic-proposed) [18.2.1-1ubuntu1]
<infinity> LocutusOfBorg: I know.
<LocutusOfBorg> does it make you feel better? :)
<LocutusOfBorg> thanks <3
 * LocutusOfBorg crosses  fingers
<tjaalton> once it's built it'll end up in NEW because of libd3dadapter*
<tjaalton> and yeah thanks
<tjaalton> also, xorg-lts-transitionals would allow x-x-v-amdgpu to migrate
-queuebot:#ubuntu-release- Unapproved: accepted xorg-lts-transitional [source] (cosmic-proposed) [3:14.4]
<LocutusOfBorg> infinity, is it possible to see ldc migrate?
<LocutusOfBorg> it should need libundead removal on armhf (no reverse deps, it has been broken since forever)
<LocutusOfBorg> and sambamba kick out from release
<LocutusOfBorg> this release has full arm64 working support
<LocutusOfBorg> while armhf is a no-go (and it has never been working, since no rdep has been working, or compiling test code)
<willcooke> infinity, the problem we have is that a lot of beta testers will do their testing on Virtualbox and if that's broken out of the box, that's going to affect the reach of our testing.  We can make sure the iso tests are back to the state they are in now a few hours after a new image
<tjaalton> willcooke: accepted already ;)
 * willcooke winds his neck in
<willcooke> thank you very much
<infinity> tjaalton: Accepted to -proposed, not migrated.
<infinity> willcooke: So, the concern with migrating it is that it's on *every* image, not just Ubuntu.
<tjaalton> infinity: you mean -amdgpu?
<tjaalton> oh
<infinity> willcooke: So, do you have people willing to help out re-testing flavours if we let it migrate and respin the world later today?
<willcooke> infinity, I personally sign up to iso test every image
<tjaalton> right, nothing has migrated yet
<willcooke> infinity, yeah I can get that sorted
<infinity> willcooke: In that case, I'll unblock it if/when it passes britney/adt testing.
<willcooke> infinity, thank you
 * willcooke readies a whole load of VMs
<infinity> willcooke, jibel: Did anyone make headway on the "gdm no come up" bug?
<infinity> If we're respinnig the world, that would be nice to nail down too.
<willcooke> jibel is looking at that one now I think
<jibel> infinity, I'm the only who reproduce this bug for the moment, so less a priority until its understood
<infinity> jibel: Oh, so maybe we just need to disable the bit that turns on the webcam and refuses to boot if it sees you?
<jibel> infinity, yeah or I should try showing your face to check if it boots
<sil2100> jibel: were you testing that on real hardware or kvm?
<infinity> kvm.
 * sil2100 tries
<infinity> At least, the log he posted is very qemu.
<infinity> It was also on an Opteron, which may or may not relate.
-queuebot:#ubuntu-release- New binary: mesa [amd64] (cosmic-proposed/main) [18.2.1-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.9 => 1.10] (lubuntu)
-queuebot:#ubuntu-release- New: accepted mesa [amd64] (cosmic-proposed) [18.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-36.39] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.4]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1021.24] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1025.26] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.13]
<Wimpress> infinity: I'm waiting on mate-indicator-applet to promote from proposed. It fixes a serious issue in Ubuntu MATE 18.10
<Wimpress> I see the arm builders are delayed.
<Wimpress> Which is why mate-indicator-applet is not promoting from proposed.
<infinity> Wimpress: Scored up.
<cjwatson> ARM build queues should clear shortly.
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-160.210] (core, kernel)
<tjaalton> qemu worked fine here fwiw, also with new mesa
<cjwatson> (Or maybe not.  Investigating with IS.)
-queuebot:#ubuntu-release- Unapproved: gdm3 (cosmic-proposed/main) [3.30.0-0ubuntu2 => 3.30.1-1ubuntu1] (ubuntu-desktop) (sync)
<sil2100> jibel: huh, I think I reproduced your issue on my kvm
<sil2100> jibel: first boot after installation, saw plymouth loading, then it turned into a black screen with the console cursor blinking on top and nothing
<sil2100> jibel: it's been like this since 2 minutes already
<infinity> sil2100: That's definitely his bug.
<Wimpress> infinity: Cheers
<infinity> willcooke: Is that gdm3 upload suspected to address the issue, or just a random hail mary "well, maybe a new upstream?"
<infinity> Or just someone staging a post-beta merge.
<infinity> Wimpress: Not that scoring up will do any good until scalingstack is picked up off the floor.
<Laney> The last one.
<infinity> Laney: Kay.
<Laney> It does have some fixes that might affect this bug, but until someone's tested that, I wouldn't apply any particular urgency to it.
<infinity> Gah.  Yanking on the little pull-tab to un-wax my Babybel succeeded in nothing except to pull the string out.  Now my cheese is stuck forever in a little wax prison.
<infinity> THIS IS RELEASE CRITICAL.
<infinity> SOMEONE SAVE MY CHEESE.
 * Wimpress moves infinity's cheese
<infinity> Nevermind, crisis averted.  I remembered that knives exist.
<willcooke> That was a close one
<sil2100> phew
<willcooke> infinity, I've let the flavours know what's going on.
<teward> you actually made me laugh today, infinity, thanks for that xD  (I needed something to cheer me up it's a dreary day here)
<sil2100> ...cheese flavours?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-160.210]
<infinity> teward: I'm glad my personal breakfast anguish could bring you joy.
<sil2100> It was no laughing matter, the release was at risk here
<infinity> Well, the release of my cheese, at any rate.
<sil2100> A release is a release
<sil2100> !
<sil2100> jibel: hm, gdm doesn't come up for me at all, even after 15 minutes
<teward> infinity: sorry, it doesn't take much to amuse me on a crazy dark and dreary day xD
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (cosmic-proposed/universe) [0.181 => 0.182] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-36.39] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-36.39~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1025.26]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-36.39]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1021.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-36.39]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.10]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (cosmic-proposed) [0.182]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-36.39~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-137.163]
<cjwatson> scalingstack is better now
-queuebot:#ubuntu-release- Unapproved: hyperkitty (cosmic-proposed/universe) [1.2.1-2 => 1.2.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hyperkitty [sync] (cosmic-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- Unapproved: androguard (cosmic-proposed/universe) [3.1.0~rc2-2 => 3.2.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.2-0ubuntu0.18.04.2 => 2.56.3-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted androguard [sync] (cosmic-proposed) [3.2.1-1]
<willcooke> infinity, Do you know of any other fixes that might go in for the same respin?  The flavours are planning who to get to do the testing
<willcooke> also, any ideas when the images will pop out?
<infinity> willcooke: I refreshed a couple of stale metas, but the only big thing will be mesa, I think.
<willcooke> infinity, got it thanks
<infinity> willcooke: Images won't be for a long while.  mesa's got a lot of testing it needs to pass.
<flocculant> willcooke: bit early for 'are we there yet' :p
<infinity> willcooke: And it still needs to build on arm*, due to the above scalingstack oops.
<flocculant> infinity: thanks :)
<willcooke> I need to know if I can start on my beer before or after testing
-queuebot:#ubuntu-release- Unapproved: zapping (cosmic-proposed/universe) [0.10~cvs6-13 => 0.10~cvs6-14] (no packageset) (sync)
<infinity> willcooke: It's never the wrong time for beer.
<willcooke> Sounds like tomorrow morning my time might be good enough
<willcooke> for testing, not beer
<infinity> What did I just say?
<flocculant> morning beer is good :p
<teward> infinity: by extension, then, it's never the wrong time for booze.  *takes a swig from the flask he has*
 * willcooke makes plans for the release sprint 
-queuebot:#ubuntu-release- Unapproved: accepted zapping [sync] (cosmic-proposed) [0.10~cvs6-14]
-queuebot:#ubuntu-release- Unapproved: developers-reference (cosmic-proposed/universe) [3.4.20 => 3.4.21] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted developers-reference [sync] (cosmic-proposed) [3.4.21]
<infinity> wxl: Fixed your live-common seed issue.
<infinity> wxl: (See the last commit on the lubuntu seeds)
<wxl> infinity: you are the man. in return, i've concocted a game plan to get the shortlist of TB candidates.
<infinity> wxl: Does it involve following Mark from country to country and poking him every 5 minutes?
<wxl> infinity: not quite. but almost.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1021.22~16.04.1] (no packageset)
<wxl> jbicha: you did a test on the lubuntu live image and included bug 1794440 in your report but 18.10 doesn't have lxterminal
<ubot5> bug 1794440 in lxterminal (Ubuntu) "Crash with vte-0.54 when closing a tab with the X button" [Undecided,New] https://launchpad.net/bugs/1794440
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1025.26~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1025.26~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1021.22~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-137.163~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: limnoria (cosmic-proposed/universe) [2018.06.25-1 => 2018.09.09-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted limnoria [sync] (cosmic-proposed) [2018.09.09-1]
-queuebot:#ubuntu-release- Unapproved: jenkins-job-builder (cosmic-proposed/universe) [2.0.3-3 => 2.5.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jenkins-job-builder [sync] (cosmic-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- Unapproved: pylama (cosmic-proposed/universe) [7.4.3-1 => 7.4.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pygments (cosmic-proposed/main) [2.2.0+dfsg-1ubuntu1 => 2.2.0+dfsg-2] (edubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pylama [sync] (cosmic-proposed) [7.4.3-2]
<wxl> jbicha: i'm just going to delete your result.
-queuebot:#ubuntu-release- Unapproved: stress-ng (cosmic-proposed/universe) [0.09.40-1 => 0.09.41-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (cosmic-proposed) [0.09.41-1]
-queuebot:#ubuntu-release- Unapproved: popularity-contest (cosmic-proposed/main) [1.67ubuntu1 => 1.67ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted popularity-contest [source] (cosmic-proposed) [1.67ubuntu2]
<jbicha> wxl: sorry about that, does Lubuntu have someone that could look at that issue though?
<wxl> jbicha: for 18.10 we're not really supporting LXDE.
<wxl> get the clone link from https://phab.lubuntu.me/source/lubuntu-artwork/
<wxl> this one doesn't follow the norm
<jbicha> wxl: does that mean I can sync over https://launchpad.net/ubuntu/+source/lxterminal/0.3.1-2ubuntu1 ?
<jbicha> (meaning can I drop that change?)
<wxl> jbicha: as i said, we're not really supporting it, so unless someone is planning on backporting it for bionic or before, we're kind of out of the loop
<wxl> jbicha: that said, i'd put the decision into the hands of ubuntu devs as a whole. my 2Â¢ is that it seems reasonable
<infinity> wxl: I'd say that, as part of dropping support going forward for LXDE, it would be good to push any useful deltas to Debian and sync over the Ubuntu packages, so you can wash your hands of it.
<jbicha> done :)
<infinity> wxl: Just leaving delta cruft around unmaintained isn't helpful.
<wxl> ^^ ahem @tsimonq2
-queuebot:#ubuntu-release- Unapproved: lxterminal (cosmic-proposed/universe) [0.3.1-2ubuntu2 => 0.3.2-1] (no packageset) (sync)
 * tsimonq2 reads scrollback
<jbicha> context was bug 1794440
<ubot5> bug 1794440 in lxterminal (Ubuntu) "Crash with vte-0.54 when closing a tab with the X button" [Undecided,Fix released] https://launchpad.net/bugs/1794440
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.5]
-queuebot:#ubuntu-release- Unapproved: accepted lxterminal [sync] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.5]
<tsimonq2> infinity, jbicha: Lubuntu as a flavor team no longer cares about LXDE (and thus, LXTerminal) at all in Cosmic+ with the exception of following best practice in making sure fixes are in devel before SRUing them to releases we support. So please use your best judgment as Ubuntu Developers, but it's also "not our problem" anymore (specifically) unless it's also an SRU-justifiable problem in the
<tsimonq2> stable release.
<tsimonq2> tl;dr, JFDI.
<infinity> tsimonq2: Leaving a bunch of deltas around and declaring "not our problem" is pretty hostile behaviour.
<wxl> tsimonq2: i think what i'm reading from infinity is that we go through all the LXDE packages and and push any Ubuntu deltas to Debian in the effort of cleaning up our mess
<infinity> tsimonq2: That's what I was driving at above.  If you want to walk away from a set of packages, please leave them in a state where others don't have to run around trying to figure out how to unstick them.
<infinity> (no automated process will do those merges, after all)
<tsimonq2> infinity: Let me clarify; maintainance of the packages in Universe in general is no longer our problem as a team. If there's some stuff we didn't clean up, please do ping me about it, but if you have clear justification, go ahead. I guess I haven't looked through the deltas we have left behind but if I recall we're talking single digits, if that.
<tsimonq2> wxl: Works for me.
<infinity> tsimonq2: Sure, I haven't done an audit, this just came up because of lxterminal.  If it's single-digits, I'd love the digit to be 0. ;)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1021.22] (no packageset)
<tsimonq2> Apologies, I have a bit of a spaghetti brain right now, what wxl says is what I agree with. Perhaps wxl can follow up with LStranger in Debian?
<tsimonq2> I mean no hostility. :)
<tsimonq2> infinity: But yes, we are agreed there.
<wxl> suffice it to say we'll put it on the TODO list but i think we're up against the wall right now. so until cosmic is out, i think it would be best to just ask if there are questions. after that we can do a more formal and complete audit.
<wxl> does that work, infinity ?
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1021.22]
<tsimonq2> That.
<infinity> wxl: Yeah, my carefactor for deltas in cosmic is low, since we're past FF anyway, it's going forward, I don't want some old-lubuntu package to go unmerged for 2 years because "no one cares anymore".  Resolving deltas and syncing makes that go away.
<wxl> yeah, no. we don't want to roll that way at all, either.
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-137.163~14.04.1]
-queuebot:#ubuntu-release- Unapproved: python-pbr (cosmic-proposed/main) [4.2.0-0ubuntu2 => 4.2.0-0ubuntu3] (ubuntu-desktop, ubuntu-server) (sync)
<infinity> jbicha: Still around?
<jbicha> yes
<infinity> jbicha: You're TIL on pygobject it seems.  What's the point in python3-gi-cairo if python3-gi depends on cairo? :P
<infinity> jbicha: (Or, put another way, I think maybe you messed up, because python3-gi now depends on cairo when it didn't used to, pulling a bunch of X stuff into the base system)
<infinity> jbicha: I think that's responsible for the bulk of this: http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
-queuebot:#ubuntu-release- Unapproved: pyaes (cosmic-proposed/universe) [1.6.1-1ubuntu1 => 1.6.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pyaes [sync] (cosmic-proposed) [1.6.1-2]
-queuebot:#ubuntu-release- Unapproved: python-datrie (cosmic-proposed/universe) [0.7.1-1ubuntu2 => 0.7.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: fail2ban (cosmic-proposed/universe) [0.10.2-2 => 0.10.2-2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: restrictedpython (cosmic-proposed/universe) [4.0~b3-1 => 4.0~b3-2] (zope) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fail2ban [sync] (cosmic-proposed) [0.10.2-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-datrie [sync] (cosmic-proposed) [0.7.1-2]
-queuebot:#ubuntu-release- Unapproved: tss2 (cosmic-proposed/universe) [1045-1.1 => 1045-1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tss2 [sync] (cosmic-proposed) [1045-1.2]
<jbicha> well I didn't cause it but I'm still investigating. One interesting change in 3.29 was that we switched to pybuild
<jbicha> the new dep showed up in 3.29.2 but it took a while for that to migrate out of -proposed
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.37]
-queuebot:#ubuntu-release- New source: golang-1.10 (trusty-proposed/primary) [1.10.4-2ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: golang-1.10 (xenial-proposed/universe) [1.10-1ubuntu1~16.04.1 => 1.10.4-2ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-1.10 (bionic-proposed/main) [1.10.1-1ubuntu2 => 1.10.4-2ubuntu1~18.04.1] (kubuntu, ubuntu-desktop)
<mwhudson> [1.10-1ubuntu1~16.04.1 => 1.10.4-2ubuntu1~16.04.1 ??
<mwhudson> oh backports
<valorie> so is the respin happening?
<infinity> valorie: Waiting on mesa autopkgtests.
<valorie> ok
<valorie> I guess there is always tonight to run tests
<acheronuk> valorie: and I can do some in the morning UK time
<infinity> Though I may short circuit that soon if the tests look plausibly okay on enough arches.
<wxl> this isn't the "vbox" respin, right?
<infinity> wxl: It is.
<wxl> huh. just booted in vbox.
<infinity> You're clearly special.
<acheronuk> valorie: oh, autotests :D
<wxl> clearly :)
<valorie> we <3 autotests
<valorie> right?
<acheronuk> when they pass and are quick!
<valorie> amen to that
<infinity> Not unlike kidney stones.
<infinity> That said, it probably won't surprise anyone that mesa has a few rdeps, and I think it's important they actually get tested.
-queuebot:#ubuntu-release- Unapproved: celery (cosmic-proposed/universe) [4.2.1-0ubuntu3 => 4.2.1-1fakesync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted celery [source] (cosmic-proposed) [4.2.1-1fakesync1]
<wxl> oh now i get it the "vbox bug" is a ubiquity-related bug it seems. no problem with calamares.
<RAOF> doko: Urgh, I thought I picked a yaml library already in main. Ok, filing.
-queuebot:#ubuntu-release- Unapproved: dokuwiki (cosmic-proposed/universe) [0.0.20180422.a-1 => 0.0.20180422.a-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dokuwiki [sync] (cosmic-proposed) [0.0.20180422.a-2]
#ubuntu-release 2018-09-27
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (cosmic-proposed/main) [2.22.2-1 => 2.22.2-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: evolution (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (cosmic-proposed/main) [2.64.0-2 => 2.64.1-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libdazzle (cosmic-proposed/main) [3.30.0-2 => 3.30.1-1] (ubuntu-desktop) (sync)
<cpaelzer> anybody around here that could unblock ocfs2 via accepting https://code.launchpad.net/~paelzer/britney/hints-ubuntu-ocfs2-cosmic-bump/+merge/355482
-queuebot:#ubuntu-release- Unapproved: pylint-django (cosmic-proposed/universe) [0.11-1 => 2.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: pylint2 (cosmic-proposed/primary) [1.9.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted pylint-django [sync] (cosmic-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- Unapproved: pytest-pylint (cosmic-proposed/universe) [0.9.0-2ubuntu3 => 0.12.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pytest-pylint [sync] (cosmic-proposed) [0.12.3-1]
-queuebot:#ubuntu-release- Unapproved: gnome-mines (cosmic-proposed/main) [1:3.30.0-1 => 1:3.30.1.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: pylint (cosmic-proposed/universe) [2.1.1-1 => 2.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pylint [sync] (cosmic-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New sync: pylint2 (cosmic-proposed/primary) [1.9.2-2]
<valorie> dang it, still no respin?
<infinity> valorie: There was a hiccup with some kde autopkgtests, it seems.  They're passing on retry now.
<valorie> cool
<valorie> too late for me though
<valorie> nearly midnight here
<valorie> I guess the europeans will have to do the testing
<infinity> I think they promised they would anyway.
<infinity> I'm going to respin in a few minutes, actually, when mesa publishes (it's migrated)
<tjaalton> \o/
<valorie> yay!
<wxl> still planning on releasing thursdady @infinity ?
<infinity> wxl: Don't see why not.  Thursday has 23 hours left in it for me.  More for Hawaii.
<infinity> (is "thursdady" a nickname for Odin?)
<wxl> don't make me slap you
<wxl> instead i'll quote you: "we're releasing no earlier than midnight thursday, hawaii time" XD
<infinity> I said no such thing.
<infinity> Now if you said "no later than", that might work.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Cosmic Beta] has been updated (20180927)
<wxl> ah, paraphrase/quote what's the difference XD
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Cosmic Beta] has been updated (20180927)
<jibel> infinity, the "black screen on boot" issue could be the plymouth crash in bug 1794292
<ubot5> bug 1794292 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in /sbin/plymouthd:11 in ply_renderer_set_handler_for_input_source -> ply_keyboard_stop_watching_for_renderer_input -> ply_keyboard_stop_watching_for_input -> ply_device_manager_deactivate_keyboards -> on_deactivate" [High,Confirmed] https://launchpad.net/bugs/1794292
<infinity> jibel: Could be.  Definitely too late to sort that one.
<infinity> jibel: But respins for the mesa thing are in progress.
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Cosmic Beta] has been updated (20180927)
<jibel> right
<jibel> I still haven't found what triggers it
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Cosmic Beta] has been updated (20180927)
<LocutusOfBorg> please accept llvm-toolchain-7, it brings back the ocaml binding, and fixes a nasty bug with the clang sanitizer
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (cosmic-proposed/main) [1:7-2 => 1:7-3] (kubuntu, ubuntu-desktop) (sync)
 * willcooke starts iso testing
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (cosmic-proposed/main) [3.29.92-1ubuntu2 => 3.29.92-1ubuntu3] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ukui-panel (cosmic-proposed/universe) [1.1.3-0ubuntu1 => 1.1.4-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ukui-panel (cosmic-proposed/universe) [1.1.3-0ubuntu1 => 1.1.4-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Unapproved: libxkbcommon (bionic-proposed/main) [0.8.0-1 => 0.8.2-1~ubuntu18.04.1] (core, xorg)
<handsome_feng> mapreri: Thanks! :)
<mapreri> o/
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Cosmic Beta] has been updated (20180927)
-queuebot:#ubuntu-release- Unapproved: unity-greeter (cosmic-proposed/universe) [18.04.0+18.04.20180314.1-0ubuntu2 => 18.04.0+18.10.20180926-0ubuntu1] (mythbuntu) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Cosmic Beta] has been updated (20180927)
<mapreri> I could do with somebody processing src:pylint2 from new, btw.
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Cosmic Beta] has been updated (20180927)
<LocutusOfBorg> hello, is it possible to demote llvm-toolchain-6.0 from main to universe?
<LocutusOfBorg> doko, ^^ maybe you can?
-queuebot:#ubuntu-release- Unapproved: celery (cosmic-proposed/universe) [4.2.1-1fakesync1 => 4.2.1-2fakesync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted celery [source] (cosmic-proposed) [4.2.1-2fakesync1]
-queuebot:#ubuntu-release- Unapproved: libguestfs (bionic-proposed/universe) [1:1.36.13-1ubuntu3.1 => 1:1.36.13-1ubuntu3.2] (no packageset)
<doko> LocutusOfBorg: please could you figure out why so many llvm 7 packages want to promote? more than want demote in 6
<doko> e.g. lldb
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.0-7ubuntu1 => 3.7.1~rc1-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.6 (cosmic-proposed/main) [3.6.6-4ubuntu1 => 3.6.7~rc1-1] (core)
-queuebot:#ubuntu-release- New: rejected pylint2 [sync] (cosmic-proposed) [1.9.2-2]
-queuebot:#ubuntu-release- New: accepted pylint2 [sync] (cosmic-proposed) [1.9.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.7~rc1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.1~rc1-1]
-queuebot:#ubuntu-release- Unapproved: accepted atril [sync] (cosmic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-mines [sync] (cosmic-proposed) [1:3.30.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [sync] (cosmic-proposed) [2.64.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-backgrounds [sync] (cosmic-proposed) [1.20.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-dock-applet [sync] (cosmic-proposed) [0.87-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-power-manager [sync] (cosmic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-themes [sync] (cosmic-proposed) [3.22.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted pluma [sync] (cosmic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [sync] (cosmic-proposed) [4.2.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted eom [sync] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdazzle [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [sync] (cosmic-proposed) [1.20.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-screensaver [sync] (cosmic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted pygments [sync] (cosmic-proposed) [2.2.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: rejected ukui-panel [sync] (cosmic-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-greeter [sync] (cosmic-proposed) [18.04.0+18.10.20180926-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [sync] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [sync] (cosmic-proposed) [1.20.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted restrictedpython [sync] (cosmic-proposed) [4.0~b3-2]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [sync] (cosmic-proposed) [1:7-3]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-panel [sync] (cosmic-proposed) [1.1.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-utils [sync] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted marco [sync] (cosmic-proposed) [1.20.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop [sync] (cosmic-proposed) [1.20.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted ostree [source] (bionic-proposed) [2018.8-0ubuntu0.1]
<LocutusOfBorg> doko, where do you see it? lldb is generic... lldb-7? liblldb? which one?
<LocutusOfBorg> https://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<LocutusOfBorg> you mean there?
<LocutusOfBorg> please let me know, I'll be afk soon
<LocutusOfBorg> I need to understand the logic for that page... something in main requires lldb?
-queuebot:#ubuntu-release- Unapproved: iwyu (cosmic-proposed/universe) [6.0-1 => 6.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted iwyu [sync] (cosmic-proposed) [6.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.4]
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (bionic-proposed) [1.0.1-0ubuntu0.1]
<LocutusOfBorg> can any AA please parse this to me?
<LocutusOfBorg>  Binary only movements to main
<LocutusOfBorg>  -----------------------------
<LocutusOfBorg>  o libc++-7-dev libc++1-7 libc++abi-7-dev libc++abi1-7 liblld-7 liblld-7-dev libomp-7-dev libomp-7-doc libomp5-7 lld-7 llvm-7 llvm-7-dev llvm-7-doc llvm-7-examples llvm-7-runtime{llvm-toolchain-7}
<LocutusOfBorg>    [Reverse-Depends: Rescued from llvm-toolchain-7, libc++-7-dev, libc++1-7, liblld-7-dev, libomp-7-dev, llvm-7, llvm-7-dev, llvm-7-examples]
<LocutusOfBorg> nothing in main depends on any of the above libraries
<LocutusOfBorg> can it be something in -proposed?
<sil2100> cjwatson: hmm, maybe you'll know a bit more about this - ubuntustudio image build has failed because of the livefs build failing, but there's no build logs of it:
<sil2100> cjwatson: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/cosmic/ubuntustudio/+build/146192
<sil2100> cjwatson: I vaguely remember something like this before
<mapreri> handsome_feng: for the fun of it, I've now filed a bug against that package :P
<cjwatson> sil2100: That happens when the builder dies, the buildd-manager loses network connectivity to it, or something along those lines.  Our logs are inconclusive in this case and you should probably just re-request the build
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [s390x] (cosmic-proposed/main) [1:7-3] (kubuntu, ubuntu-desktop)
<sil2100> cjwatson: ok, thanks
-queuebot:#ubuntu-release- Unapproved: accepted metacity [source] (bionic-proposed) [1:3.28.0-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (bionic-proposed) [3.28.0-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.6]
<cpaelzer> sil2100: are you on SRU duty?
<cpaelzer> wha was it rejected ... looking for mails
<cpaelzer> sil2100: the message I got via mail is cut off
<cpaelzer> the .changes file comes with 2 bugs that se...
<cpaelzer> how does this continue ?
<sil2100> cpaelzer: I continued on the bug ;)
<sil2100> (stupid sru tooling)
<cpaelzer> ok, reading there then ...
<sil2100> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1789551/comments/20
<ubot5> Ubuntu bug 1789551 in qemu (Ubuntu Bionic) "qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads" [High,Triaged]
<sil2100> cpaelzer: I can't review something that I can't have access to + the same for the tools, they won't be able to track the verification of those bugs
<mapreri> handsome_feng: since BTS is currently not completely working and you didn't receive the report, https://bugs.debian.org/909729
<ubot5> Debian bug 909729 in src:ukui-menus "ukui-menus: don't build-dep on all python3 versions without building for them all" [Important,Open]
<cpaelzer> sil2100: the code is all upstream now, I think I can make the bugs public now
<cpaelzer> sil2100: when IBM started things were partially secret still
<cpaelzer> sil2100: both are public now
<cpaelzer> sil2100: can you review it that way and accept from rejected
<sil2100> cpaelzer: ok, thanks! I can, yes
<cpaelzer> I happened to learn by bdmurray last week that "accept from rejected" is a thing that exists
<sil2100> (if Brian fixed the bug we had with sru-review for rejected reviews)
<cpaelzer> sil2100: if there is anything else with it ping me and we will sort it out
<cpaelzer> sil2100: he tested with one of my bugs and it got accepted - not sure if he uploaded the fix thou
<bdmurray> sil2100: I did!
<bdmurray> sil2100: its fixed in r1188
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.6-1ubuntu4.1~16.04.1]
<cpaelzer> general SRU question to you guys then, if a partner opened things as a private bug and other than in this case does not want it to become public what am I supposed to do then on the SRU upload?
<cpaelzer> not mention the bug at all sounds stupid
<bdmurray> Make a public bug without any private info?
<cpaelzer> with some projects we created secondary bugs holding the public info and referring in the SRU to that - is that the preferred way?
<sil2100> bdmurray: \o/
<cpaelzer> bdmurray: ok your answer sounds like mine with 505 of the words :-)
<cpaelzer> thanks
<sil2100> Aaaaa, ok, we have a problem, the rejected queue has 2 uploads with the same version number
<cpaelzer> sil2100: I can dput the same thing again if that helps sil2100
<sil2100> cpaelzer: if you have it handy, please do, if not I can manually review it and approve through LP
<sil2100> But that's usually error-prone
<cpaelzer> it is all here, let me re-dput it
<sil2100> Thanks!
<acheronuk> sil2100: FYI, there is new KDE plasma point release SRU on the way
 * acheronuk hides
<acheronuk> will be testing ppa builds 1st, so maybe not for a day or 2
<acheronuk> just giving fair warning ;)
<cpaelzer> sil2100: took a minute to make sure this would not accidentially be a "different" 7.6 on my system - uploaded again
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.5 => 1:2.11+dfsg-1ubuntu7.6] (ubuntu-server, virt)
<cpaelzer> here it is thanks queuebot
-queuebot:#ubuntu-release- New binary: llvm-toolchain-7 [ppc64el] (cosmic-proposed/main) [1:7-3] (kubuntu, ubuntu-desktop)
<sil2100> Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.6]
<cpaelzer> sil2100: thank you
-queuebot:#ubuntu-release- Unapproved: mediawiki (cosmic-proposed/universe) [1:1.31.1-2 => 1:1.31.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mediawiki [sync] (cosmic-proposed) [1:1.31.1-3]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Cosmic Beta] has been marked as ready
<ahasenack> is there a page that marks the state of these builds? Which ones are ready, etc?
 * ahasenack checks the iso tracker
<ahasenack> yep
<sil2100> infinity: hey! I cancelled the stuck re-build request of the failed build of ubuntustudio and kicked a new one
<sil2100> infinity: hopefully this time the builder won't die
-queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu0.16.04.16 => 2:4.3.11+dfsg-0ubuntu0.16.04.17] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: libsdl2 (cosmic-proposed/universe) [2.0.8+dfsg1-2ubuntu1 => 2.0.8+dfsg1-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Cosmic Beta] has been marked as ready
<LocutusOfBorg> libsdl2 is again multiarch ready ^^
 * LocutusOfBorg would like to see ghc blacklisted
<LocutusOfBorg> cjwatson, ^^
<cjwatson> auto-sync is in dry-run mode anyway, so that doesn't seem necessary
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Cosmic Beta] has been updated (20180927.1)
<LocutusOfBorg> cjwatson, I'm thinking wrt cosmic+1 and somebody syncing it "by mistake"
<cjwatson> That seems like it would better be considered closer to the time
<cjwatson> Anyway, it's pretty easy for any archive admin to do that nowadays, since it's a straightforward pair of sync-blacklist entries
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.8 => 1:18.10.9] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.5 => 2.02-2ubuntu8.6] (core)
-queuebot:#ubuntu-release- Unapproved: linux-azure (cosmic-proposed/main) [4.15.0-1018.18 => 4.18.0-1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (cosmic-proposed/main) [4.15.0.1018.18 => 4.18.0.1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (cosmic-proposed/main) [4.15.0-1018.18 => 4.18.0-1002.2] (kernel) (sync)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [ppc64el] (cosmic-proposed) [1:7-3]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-7 [s390x] (cosmic-proposed) [1:7-3]
<infinity> willcooke: Apparently, while I was napping, studio didn't build for infra reasons.  It exists now, but cutting it close.  Do you still have an army (is the army you?) ready to help?
 * willcooke flexes
<willcooke> infinity, no worries, we're about done on everything else
<willcooke> sil2100 said he might help as well
<willcooke> I'm downloading now
<infinity> willcooke: You're my favourite manager-who-doesn't-manage-me ever.
<willcooke> You're my favourite too
<Laney> What.
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2017c-0ubuntu0.16.04 => 2018e-0ubuntu0.16.04] (core)
<willcooke> <furtive glances>
<infinity> slangasek: ^-- That's your way of saying my "I'll do it today" wasn't soon enough? :P
<slangasek> infinity: yeah you have more important things to do and I haven't been able to context switch away from it
<tsimonq2> infinity: I think we're officially wrapping up shop for i386 in Lubuntu then. ENOTESTERS.
<infinity> slangasek: Fair enough.  Enjoy testing it. :)
<infinity> slangasek: Also, don't forget the ESM archive.
<slangasek> infinity: testing? :P
<infinity> Yep.
<infinity> Testing good.
<tsimonq2> (Well, besides jibel, but that isn't "active community interest" as much as it is jibel being nice.)
<slangasek> infinity: I will follow https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
<infinity> slangasek: Oh, that was pitti's testing.  Maybe I should update it.  "if the package is different, you win" seems like a poor test.
<slangasek> infinity: if you want me to do a different test, then yes, you should update it ;)
<infinity> slangasek: My testing method is basically to spawn schroots for every supported release, update to current, check a current and future date output for a control TZ (say, my own), then past/current/future, crossing DST boundaries for changed TZs.  Record results.  Update to proposed.  Repeat.  See if results are expected.
<infinity> slangasek: Basically, it means actually understanding upstream's changes, not just blindly updating and calling it good.
<slangasek> k
<infinity> slangasek: And yeah, please do precise ESM too.  Or I can $later, but it's much easier to do them all in bulk.
-queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2017c-0ubuntu0.14.04 => 2018e-0ubuntu0.14.04] (core)
<slangasek> infinity: I'm not sure I'm able to upload to precise-esm, given the failures I've gotten before trying to process ESM kernel SRUs
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2018d-1 => 2018e-0ubuntu0.18.04] (core)
<infinity> slangasek: Toss it in a PPA of your own, and I'll take it from there.
<infinity> slangasek: Just so all your uploads match.
<slangasek> ok
<infinity> slangasek: (And test it from said PPA too before the hand-off)
<slangasek> though I probably /ought/ to have ESM ppa publishing rights
<infinity> slangasek: But also, we should fix the part where you might not have ESM access.  You should.
 * slangasek nos
<slangasek> nods
<infinity> slangasek: You do...
<infinity> Latest members
<infinity>     Steve Langasek
<infinity>     Åukasz Zemczak
<infinity>     Canonical Kernel Security Team
<slangasek> ok, possibly fixed since last time I tried to do a kernel?
<infinity> Steve Langasek 2018-03-16 â Approved
<infinity> Maybe?
<slangasek> wasn't that long ago that I tried
<slangasek> so I don't know why the kernel publishing failed
<infinity> slangasek: Oh, maybe it was kernel process that tripped you up, with kernel-team-owned ESM PPAs on the way to the final PPA?
<slangasek> yeah must be
<infinity> slangasek: I'm just looking at *the* ESM PPA here.
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Cosmic Beta] has been marked as ready
<apw> slangasek, you short permissions on the 'proposed' ppa for ESM ?
<apw> slangasek, no should be ok there too
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnumeric [sync] (cosmic-proposed) [1.12.43-1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (cosmic-proposed) [5.6.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-cpufreq-plugin [sync] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gedit [sync] (cosmic-proposed) [3.30.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-battery-plugin [sync] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted liblivemedia [sync] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted yelp-xsl [sync] (cosmic-proposed) [3.30.1-1]
<slangasek> apw: ok, we'll see what happens next time I try to process an esm kernel
-queuebot:#ubuntu-release- New binary: liblivemedia [s390x] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [ppc64el] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [arm64] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [armhf] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [i386] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblivemedia [amd64] (cosmic-proposed/universe) [2018.09.18-1] (kubuntu)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: equinox-framework (cosmic-proposed/universe) [4.7.3-2 => 4.7.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted equinox-framework [sync] (cosmic-proposed) [4.7.3-3]
-queuebot:#ubuntu-release- Unapproved: libequinox-osgi-java (cosmic-proposed/universe) [3.9.1-1 => 3.9.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libequinox-osgi-java [sync] (cosmic-proposed) [3.9.1-2]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.4 => 0.130ubuntu3.5] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.6 => 1.93.7] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (bionic-proposed) [3.0.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: pytest-qt (cosmic-proposed/universe) [2.3.1-1ubuntu1 => 2.3.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pytest-qt [sync] (cosmic-proposed) [2.3.1-2]
-queuebot:#ubuntu-release- Unapproved: protobuf (cosmic-proposed/main) [3.0.0-9.1ubuntu3 => 3.0.0-9.2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<tsimonq2> infinity: Looks like some people pulled through for i386.
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Cosmic Beta] has been marked as ready
<willcooke> infinity, studio testing all done, will be marked ready shortly
<willcooke> (I think)
<cyphermox> sil2100: bdmurray: either of you could have a look at the bionic queue? there's a lot of stuff in there (though I'm mostly interested in netplan.io, ledmon, grub2, grub2-signed, initramfs-tools)
<cyphermox> ^ or anyone on the SRU team, for that matter
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Cosmic Beta] has been marked as ready
<sil2100> cyphermox: didn't manage to get to those yet!
<sil2100> cyphermox: let me fetch one from the list then
<sil2100> cyphermox: I'll look at netplan
<sil2100> Love the number of bugs fixed, the bug tabs were popping up for ages!
-queuebot:#ubuntu-release- Unapproved: qemu (cosmic-proposed/main) [1:2.12+dfsg-3ubuntu6 => 1:2.12+dfsg-3ubuntu7] (ubuntu-server, virt)
<fossfreedom> hi all - whilst testing the budgie beta I noticed that our ubiquity slideshow request hasn't been reviewed.  Is the two outstanding merge requests (ubuntu and UBudgie) on anyone's radar?
<willcooke> fossfreedom, I'm updating the Ubuntu slideshow images right now, so I can nudge somone tomorrow
<fossfreedom> thx
<sil2100> cyphermox: ok, so some bugs are missing SRU information right now for netplan - the doc-only ones I could basically let in as is but there's some that I'd need to know more about, with detailed testing and regression potential
<sil2100> cyphermox: those would be: LP: #1736965, LP: #1736975, LP: #1747455, LP: #1768798, LP: #1771704 and LP: #1786726
<ubot5> Launchpad bug 1736965 in nplan (Ubuntu) ""netplan apply" does not set file mode, umask 077 causes systemd-networkd to be unable to start" [Undecided,Confirmed] https://launchpad.net/bugs/1736965
<ubot5> Launchpad bug 1736975 in netplan "netplan does not bring up anonymous bridge on boot" [Medium,In progress] https://launchpad.net/bugs/1736975
<ubot5> Launchpad bug 1747455 in netplan "netplan does not support defining route with scope 'link'" [Undecided,Fix committed] https://launchpad.net/bugs/1747455
<ubot5> Launchpad bug 1768798 in netplan.io (Ubuntu) "netplan try: terminal does not echo keypresses after ^C during wait " [High,Fix released] https://launchpad.net/bugs/1768798
<ubot5> Launchpad bug 1771704 in netplan "support for ipv4 link-local addressing" [Medium,In progress] https://launchpad.net/bugs/1771704
<sil2100> Also, LP: #1768560 seems to be linked in the changelog but it's a duplicate
<ubot5> Launchpad bug 1736965 in nplan (Ubuntu) "duplicate for #1768560 "netplan apply" does not set file mode, umask 077 causes systemd-networkd to be unable to start" [Undecided,Confirmed] https://launchpad.net/bugs/1736965
<jbicha> slangasek: do my comments on bug 1788256 satisfy your concerns?
<ubot5> bug 1788256 in fonts-noto-color-emoji (Ubuntu Bionic) "Update fonts-noto-color-emoji to 20180810 release for Unicode 11" [Low,New] https://launchpad.net/bugs/1788256
<tsimonq2> lubuntu-meta update coming down the pike; should go in immediately after the Beta if possible.
<sil2100> cyphermox: grub2/grub2-signed I can't review as there's already one in -proposed, it's still aging
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (bionic-proposed) [0.130ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (trusty-proposed) [0.7.5-0ubuntu1.23]
<tsimonq2> fossfreedom: Oh, I just noticed this in scrollback. I have gone ahead and merged your MP and Wimpress's MP, but I'll leave it to Will to upload.
-queuebot:#ubuntu-release- Unapproved: groovy (cosmic-proposed/universe) [2.4.15-3ubuntu1 => 2.4.15-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted groovy [source] (cosmic-proposed) [2.4.15-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0~pre1+git20180411-2ubuntu2 => 4.7.0~pre2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (cosmic-proposed) [4.7.0~pre2-0ubuntu1]
<Wimpress> sil2100: cyphermox: Do you have an ETA for the beta release?
<infinity> Wimpress: They might, but they'd be wrong.
<infinity> sil2100: Since sil2100 isn't driving it, and cyphermox isn't on the release team at all. :P
<infinity> Wimpress: Anyhow, it'll be a few hours, just waiting on some mirror settling and dotting and crossing various letters.
<infinity> Wimpress: Basically, my EOD (it's 2pm here now)
<acheronuk> ah. just enough time to have a good panic about release notes.....
<sil2100> :D
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2018e-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.10 => 1.11] (lubuntu)
<Wimpress> infinity: Thanks.
-queuebot:#ubuntu-release- Unapproved: lubuntu-artwork (cosmic-proposed/universe) [1.7 => 1.8] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2018e-0ubuntu0.16.04]
<cyphermox> sil2100: grub2/grub2-signed in unapproved includes the changes in -proposed.
<cyphermox> (dannf gave his go-ahead)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (trusty-proposed) [2018e-0ubuntu0.14.04]
<bdmurray> slangasek: Could you have a look at the verification of bug 1787649? I don't want to do the whole thing myself.
<ubot5> bug 1787649 in ubuntu-release-upgrader (Ubuntu Bionic) "ubuntu-release-upgrader crashed with SystemError: E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages." [High,Fix committed] https://launchpad.net/bugs/1787649
<tsimonq2> infinity: Can I safely assume e.g. Lubuntu images will be under http://cdimage.ubuntu.com/lubuntu/releases/cosmic/beta/ when they're ready?
<infinity> tsimonq2: That seems like a fair assumption.
<tsimonq2> infinity: Wonderful.
-queuebot:#ubuntu-release- Unapproved: apparmor (cosmic-proposed/main) [2.12-4ubuntu7 => 2.12-4ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (cosmic-proposed) [1.107]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu5]
-queuebot:#ubuntu-release- Unapproved: rejected lubuntu-meta [source] (cosmic-proposed) [1.10]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (cosmic-proposed) [1.11]
-queuebot:#ubuntu-release- Unapproved: accepted tasksel [source] (cosmic-proposed) [3.34ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (cosmic-proposed) [18.10.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gradle-debian-helper (cosmic-proposed/universe) [1.6ubuntu1 => 2.0.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gradle-debian-helper [source] (cosmic-proposed) [2.0.1build1]
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (cosmic-proposed/universe) [1.1.5-0ubuntu1 => 1.1.6-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: colord (cosmic-release/main) [1.3.3-2build1 => 1.4.3-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (cosmic-proposed/universe) [3.28.5-1 => 3.30.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: ukui-indicators (cosmic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu5 => 2.02+dfsg1-5ubuntu5] (core)
-queuebot:#ubuntu-release- New: accepted liblivemedia [amd64] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [armhf] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [ppc64el] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [arm64] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [s390x] (cosmic-proposed) [2018.09.18-1]
-queuebot:#ubuntu-release- New: accepted liblivemedia [i386] (cosmic-proposed) [2018.09.18-1]
<wxl> cjwatson: can you puhleeeeeeez help lubuntu fix their isolinux logos. they seem in every way correct, but they just don't display.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.6]
<wxl> ^^^ or if anyone else has any clues. (infinity?)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.7]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.6 => 2.02-2ubuntu8.6] (core)
<infinity> wxl: Ask me on a day that isn't today, and maybe I can have a look.  But Colin might beat me to it.
<wxl> infinity: i've ping around here a couple times to no avail, so hopefully someone gets to it XD
<Wimpress> wxl Compare with Ubuntu MATE. Colin helped us get the resolutions correct sometime back.
<wxl> Wimpress: i'm pretty sure i actually got so far as comparing the freaking headers on the darn images.
<wxl> Wimpress: also was your problem no display at all or poor resolution?
<xnox> wxl, i'd fix isolinux by dropping it in favor of grub only iso =) without any logos
<wxl> xnox is that an option?
<wxl> like is someone else doing that?
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (cosmic-proposed/main) [2.540 => 2.541] (desktop-core)
<xnox> i think we all agree isolinux is crap on isos, and kind of useless in the uefi / modern hardware world.
<xnox> and is now more harmful, than useful.
<wxl> well afaik it doesn't get used in uefi boots
<wxl> right?
<xnox> even on i386, and even for lubuntu
<wxl> so let's get everyone to go that direction. i'm all for it!
<xnox> correct uefi boots are grub only; and imho non-uefi should be the same
<xnox> but like we moan about it each time at release time; rather than at like archive opening =)
<wxl> well i think the former is a statement of fact while the latter is, at this point, a matter of opinion. currently a non-uefi boot is, unfortunately, an isolinux boot
<slangasek> and it's a much nicer experience than grub on uefi
<slangasek> which is why there's not much enthusiasm for switching
<wxl> because of the language support or what?
<xnox> grub is non-graphical
<wxl> because as far as theming and boot options, both should be able to support the same thing unless i'm missing something
<wxl> wait i thought you could theme grub?
<xnox> ha
<xnox> if by theme, you mean change colors on ascii characters -> yes
<wxl> https://www.gnu.org/software/grub/manual/grub/html_node/Theme-file-format.html
<wxl> i mean i'vre never tried to do this before so i just may be missing something, but it seems like there's support for everything everyone could possibly want
<xnox> slangasek, to me isolinux is odd; given that normal ubuntu machines do not boot like that.
<slangasek> language support. keyboard support. extended options support.
<slangasek> it is odd, sure
<wxl> seems there is at least some il18n support
<xnox> slangasek, what do you like about isolinux, and what should i fix? the Fn key norton-commander pop-ups?
<xnox> yeah, grub-menus are less flexible like that, unless we build a massive tree of boot options
<slangasek> xnox: it's not a question about "what I like"; the x86 BIOS boot with isolinux is a designed experience, the UEFI GRUB one is not
<wxl> given the future is UEFI, i think maybe it might be wise to start focusing on building for it/
<tsimonq2> Whatever we end up with, I really think that the locale selection on first boot is very valuable.
<xnox> slangasek, i think out of the 18.04 release sprint, the desire came out "why do we not have Maybe-ubiquity" as the first uefi option
<xnox> slangasek, which times-out and boots to the same "maybe ubiquity" screen with "try" or "install" buttons
<wxl> yeah i think that's a reasonable concern, tsimonq2. while grub supports translated strings it's not clear how to select your language
<xnox> well, it's nicer to choose language in ubiquity screen..... i thought.
<tsimonq2> wxl: We don't have Ubiquity :))
<tsimonq2> er, xnox ^
<xnox> ah
<xnox> yes
<wxl> that's true.. but you can't check the disk or memtest with ubiquity
<xnox> i forgot.
<xnox> i should try to use that btw.
<tsimonq2> Plus, what about with e.g. Kubuntu where you boot up and have to select the desktop icon?
<tsimonq2> (Much like Lubuntu.)
<slangasek> xnox: choosing keyboard in ubiquity doesn't work right today
<tsimonq2> If I speak Arabic, I won't know what to do. :P
<xnox> slangasek, yeah, true
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.6 => 2.02-2ubuntu8.6] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-tweaks (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tweaks [sync] (cosmic-proposed) [3.30.1-1]
<xnox> slangasek, sounds like isolinux should be replaced by something nice - like plymouth in the initramfs that can do language/keyboard stuff. and is highdpi aware.
<xnox> and it can bind-mount a different /proc/cmdline
<xnox> or like write out options in /run
<xnox> slangasek, i hate that both isolinux and grub are non-highdpi; the first highdpi thing is plymouth.
<slangasek> xnox: petitboot-uefi
<xnox> yes!
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Cosmic Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Cosmic Beta] has been marked as ready
<xnox> slangasek, is that a thing? or a troll? or i need to implement it?
<slangasek> xnox: troll
-queuebot:#ubuntu-release- Unapproved: sakura (cosmic-proposed/universe) [3.6.0-1ubuntu1 => 3.6.0-3] (no packageset) (sync)
<slangasek> please select all of the lines on your IRC screen that contain pictures of "troll"
-queuebot:#ubuntu-release- Unapproved: accepted sakura [sync] (cosmic-proposed) [3.6.0-3]
<vorlon> perhaps this helps
-queuebot:#ubuntu-release- Unapproved: libsecret (cosmic-proposed/main) [0.18.6-2 => 0.18.6-3] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: ibus-pinyin (cosmic-proposed/universe) [1.5.0-4 => 1.5.0-5] (input-methods, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: evolution-ews (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: evince (cosmic-proposed/main) [3.30.0-2 => 3.30.0-3] (ubuntu-desktop) (sync)
<tsimonq2> infinity: How's publishing coming?
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [sync] (cosmic-proposed) [3.30.1-1]
<infinity> tsimonq2: Hashy hashy disky disky networky networky.
<tsimonq2> infinity: Sounds fun.
<infinity> Thrill-a-minute.
<xnox> infinity, what about typy typy? all done that?
<infinity> xnox: It's more cutty pastey.
<xnox> hehe
-queuebot:#ubuntu-release- Unapproved: pycodestyle (cosmic-proposed/universe) [2.4.0-0ubuntu1 => 2.4.0-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (cosmic-proposed/universe) [0.83 => 0.84] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu5 => 2.02+dfsg1-5ubuntu5] (core)
#ubuntu-release 2018-09-28
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.1, Cosmic Beta | Archive: Feature Freeze | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis.
-queuebot:#ubuntu-release- Builds: 28 entries have been added, updated or disabled
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu5]
-queuebot:#ubuntu-release- Unapproved: elementary-xfce (cosmic-proposed/universe) [0.13-1 => 0.13.1-1] (xubuntu) (sync)
<handsome_feng> mapreri: Thanks, we will deal with that soon.
-queuebot:#ubuntu-release- Unapproved: vala-panel (cosmic-proposed/universe) [0.3.65-0ubuntu1 => 0.4.63+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: vala-panel-appmenu (cosmic-proposed/universe) [0.6.94+repack1-2 => 0.7.1+dfsg1-1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (cosmic-proposed/universe) [18.04.11 => 18.10.1] (ubuntu-mate)
<wxl> keep an eye out for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908924
<ubot5> Debian bug 908924 in src:linux "dma_direct_map_sg: overflow on USB access after upgrade to kernel 4.18" [Important,Open]
-queuebot:#ubuntu-release- Unapproved: krita (cosmic-proposed/universe) [1:4.1.1+dfsg-2 => 1:4.1.3+dfsg-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: vlc (cosmic-proposed/universe) [3.0.4-2 => 3.0.4-2build1] (kubuntu, mozilla)
-queuebot:#ubuntu-release- Unapproved: 389-ds-base (cosmic-proposed/universe) [1.4.0.15-2 => 1.4.0.16-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (cosmic-proposed) [1.4.0.16-1]
<LocutusOfBorg> tjaalton, ^^ I really think we should apply the two line patch to fix the unfixed CVE for it https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908859
<ubot5> Debian bug 908859 in src:389-ds-base "389-ds-base: CVE-2018-14638" [Grave,Open]
<LocutusOfBorg> maybe you have reasons for not closing that bug?
<tjaalton> maybe because I missed that
<tjaalton> there should be .17 soon anyway
<handsome_feng> Hi, Is it possible for someone in release team unblock the ukui-screensaver(1.1.2-0ubuntu1 to 2.0.0-0ubuntu1) and ukui-panel(1.1.3-0ubuntu1 to 1.1.4-1) in the proposed archive?
<cjwatson> wxl: incorrect PCX colour space
<cjwatson> $ file data/cosmic/lubuntu.pcx
<cjwatson> data/cosmic/lubuntu.pcx: PCX ver. 3.0 image data bounding box [0, 0] - [639, 479], 3 planes each of 8-bit colour, 300 x 300 dpi, RLE compressed
<cjwatson> $ mogrify -colors 256 data/cosmic/lubuntu.pcx
<cjwatson> $ file data/cosmic/lubuntu.pcx
<cjwatson> data/cosmic/lubuntu.pcx: PCX ver. 3.0 image data bounding box [0, 0] - [639, 479], 8-bit colour, 300 x 300 dpi, RLE compressed
<cjwatson> $ bzr ci -m 'Reduce lubuntu.pcx to 256 colours so that gfxboot will display it.'
<cjwatson> (fixed)
<LocutusOfBorg> thanks tjaalton :)
-queuebot:#ubuntu-release- Unapproved: evince (cosmic-proposed/main) [3.30.0-2 => 3.30.0-3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted amavisd-new [source] (cosmic-proposed) [1:2.11.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (cosmic-proposed) [3.30.1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (cosmic-proposed) [1.15.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [source] (cosmic-proposed) [2.22.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (cosmic-proposed) [3.30.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (cosmic-proposed) [2:10.3.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (cosmic-proposed) [3.29.92-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected evince [sync] (cosmic-proposed) [3.30.0-3]
-queuebot:#ubuntu-release- Unapproved: guiqwt (cosmic-proposed/universe) [3.0.3-2ubuntu2 => 3.0.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted guiqwt [sync] (cosmic-proposed) [3.0.3-3]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (cosmic-proposed) [1.1.10-1ubuntu6]
<tjaalton> an archive admin should remove armhf binaries of: 389-ds-base, 389-ds-base-dev, 389-ds-base-libs
<tjaalton> i386 got dropped earlier but forgot about these
<tjaalton> also, NEW queue has stuff I need, spirv-tools and vulkan-*
<tjaalton> debian NEW takes forever..
-queuebot:#ubuntu-release- Unapproved: bubblewrap (cosmic-proposed/universe) [0.3.0-1 => 0.3.1-1ubuntu1] (ubuntugnome)
<Laney> bah
<Laney> that packageset should go away
-queuebot:#ubuntu-release- Unapproved: accepted bubblewrap [source] (cosmic-proposed) [0.3.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (cosmic-proposed) [0.84]
-queuebot:#ubuntu-release- Unapproved: orocos-kdl (cosmic-proposed/universe) [1.4.0-4build1 => 1.4.0-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted orocos-kdl [sync] (cosmic-proposed) [1.4.0-6]
-queuebot:#ubuntu-release- Unapproved: ros-geometry2 (cosmic-proposed/universe) [0.6.2-7 => 0.6.2-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ros-geometry2 [sync] (cosmic-proposed) [0.6.2-8]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (cosmic-proposed/universe) [0.84 => 0.85] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (cosmic-proposed) [0.85]
<Laney> dropping the freeze block
-queuebot:#ubuntu-release- Unapproved: gnome-maps (cosmic-proposed/universe) [3.30.0-1 => 3.30.1-1] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: flameshot (cosmic-proposed/universe) [0.6.0-1 => 0.6.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flameshot [sync] (cosmic-proposed) [0.6.0-4]
-queuebot:#ubuntu-release- Unapproved: krita (cosmic-proposed/universe) [1:4.1.1+dfsg-2 => 1:4.1.3+dfsg-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: numix-icon-theme-circle (cosmic-proposed/universe) [18.08.29-1 => 18.09.19-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted numix-icon-theme-circle [sync] (cosmic-proposed) [18.09.19-1]
 * Laney slaps the systemd autopkgtest
<acheronuk> jbicha: you synced krita when it is already in the unapproved queue
<Laney> easy to do, won't cause any harm
<acheronuk> yeah. just FYI
<jbicha> sorry, I didn't see it until afterwards
-queuebot:#ubuntu-release- Unapproved: brisk-menu (cosmic-proposed/universe) [0.5.0-7ubuntu1 => 0.5.0-8ubuntu1] (ubuntu-mate)
<Wimpress> I have a big pile of MATE package sync and bug in cosmic-proposed.
<Wimpress> ETA for when stuff will start getting promoted?
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.3ubuntu0.1 => 1.6.5] (core)
<jbicha> Wimpress: I think a lot of them just migrated?
<Wimpress> Ooh. Excellent.
<Wimpress> Mucho bug fixes ð
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.27 => 1.2.28] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-mines (bionic-proposed/main) [1:3.28.0-1 => 1:3.28.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (cosmic-proposed/main) [4.15.0-1023.23 => 4.18.0-1001.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (cosmic-proposed/main) [4.15.0.1023.23 => 4.18.0.1001.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: bubblewrap (cosmic-proposed/universe) [0.3.1-1ubuntu1 => 0.3.1-1ubuntu2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted bubblewrap [source] (cosmic-proposed) [0.3.1-1ubuntu2]
<cyphermox> hey, can someone on the SRU team please review the grub2 amd64 / arm64 binaries that are currently in unapproved for bionic?
<cyphermox> (specifically for UEFI signing)
-queuebot:#ubuntu-release- Unapproved: flatpak-builder (bionic-proposed/universe) [0.10.9-1 => 0.10.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.1 => 1.37~18.04.2] (core)
<wxl> cjwatson: if i haven't told you recent, i love you.
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (cosmic-proposed) [4.18.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (cosmic-proposed) [4.18.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (cosmic-proposed) [4.18.0.1002.2]
<cjwatson> wxl: np :)
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu3 => 1:3.26.4-0ubuntu4] (ubuntu-desktop)
<wxl> cjwatson: one more question: don't see any changes in ~ubuntu-cdimage/debian-cd/ubuntu. should i mogrify and resubmit so we don't run into problems again?
<cjwatson> wxl: no - there's a cron job that pushes there from the production branch
<cjwatson> let me see if it's broken
<wxl> cjwatson: ah, ok. cool. i figured you might know what you were doing but i wanted to be sure ;)
<cjwatson> Hm.  It did seem to be lagging, but it worked when I ran it by hand ... not sure what was going on there
<cjwatson> wxl: Anyway, it's up to date now
<wxl> cjwatson: so i see! hopefully we'll see it fixed in our dailies which will be building relatively soon. thanks again
-queuebot:#ubuntu-release- Unapproved: linux-azure (cosmic-release/main) [4.18.0-1002.2 => 4.15.0-1023.24] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-tweak (cosmic-proposed/universe) [18.04.16-2 => 18.10.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-hud (cosmic-proposed/universe) [18.04.8-0ubuntu1 => 18.10.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (cosmic-release) [4.15.0-1023.24]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.40~18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (cosmic-release/main) [4.18.0.1002.2 => 4.15.0.1023.23] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (cosmic-release) [4.15.0.1023.23]
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (cosmic-release/main) [4.18.0-1002.2 => 4.15.0-1023.24] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (cosmic-release) [4.15.0-1023.24]
-queuebot:#ubuntu-release- Unapproved: python-flake8 (cosmic-proposed/universe) [3.5.0-1ubuntu1 => 3.5.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-flake8 [sync] (cosmic-proposed) [3.5.0-2]
-queuebot:#ubuntu-release- Unapproved: pycodestyle (cosmic-proposed/universe) [2.4.0-0ubuntu1 => 2.4.0-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: bluedevil (cosmic-proposed/universe) [4:5.13.5-0ubuntu1 => 4:5.13.5-0ubuntu2] (kubuntu)
<LocutusOfBorg> who did approve libllvm-7-ocaml-dev into main? can you please put in universe? thanks
<LocutusOfBorg> any AA ^^
<jbicha> LocutusOfBorg: could you make it show up on https://people.canonical.com/~ubuntu-archive/component-mismatches.html ?
<jbicha> but https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0 used to be in main too
<xnox> jbicha, it is on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<xnox> jbicha, as it's in cosmic-proposed only
<xnox> Binary only movements to universe (unsubscribed)
<xnox> libllvm-7-ocaml-dev	llvm-toolchain-7
<jbicha> ok I see now
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (cosmic-proposed/main) [3.30.0-1ubuntu1 => 3.30.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (cosmic-proposed/main) [18.10.1-0ubuntu1 => 18.10.2-0ubuntu1] (ubuntu-desktop)
<LocutusOfBorg> jbicha, llvm 6 didn't have ocaml bindings AFAIR
<infinity> LocutusOfBorg: main sources get their binaries in main by default, it'll get demoted.
<infinity> LocutusOfBorg: There's no "who did approve" accusation required. :P
<infinity> (and demoted)
<LocutusOfBorg> it wasn't an accusation :) anyway, aren't them "accepted" manually? I mean, it was a new binary!
<LocutusOfBorg> thanks for fixing it :)
<infinity> LocutusOfBorg: Yes, it's manual, but the queue puts binaries in their parent components by default, and it's easier to just accept that and then check reports than it is to manually investigate where each one should go.
<xnox> also, it was autoincluded into main; until doko fixed the Extra-Excludes today.
<infinity> Oh, and that.  -dev packages are pulled in by default.
<jbicha> we have an override for llvm -dev packages so it was already in mismatches
<infinity> jbicha: Any movement on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909703 ?
<ubot5> Debian bug 909703 in python3-gi "python3-gi: Should not depend on python3-cairo" [Important,Open]
<infinity> jbicha: Should we just revert that commit in Ubuntu for now (does it have any adverse effects to do so)?
<jbicha> infinity: I don't have any update more than that bug. reverting is a bit messy as I got lintian warnings related to https://salsa.debian.org/gnome-team/pygobject/commit/1f59d60d8
<jbicha> infinity: could you promote woff2 to main?
<wxl> it seems the lubuntu images built but i don't see them on the iso tracker
<tsimonq2> infinity: Did you re-enable the cron job? :P
<flocculant> tsimonq2: xubuntu's image for today is there
<tsimonq2> hmmmm
<tsimonq2> Weird.
<infinity> tsimonq2: Yes.
<tsimonq2> Timeout on the image builder?
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/cosmic/lubuntu/+build/146304
<infinity> tsimonq2: ^-- It's still trying very hard.
<infinity> Blame L1TF.
<infinity> Always blame Intel.
<tsimonq2> Even if we can blame systemd? I like blaming systemd much more. :P
<infinity> After this past year, Lennart looks like a saint compared to Intel execs.
<tsimonq2> True.
<LocutusOfBorg> thanks infinity and xnox :)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (cosmic-proposed) [18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.541]
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (cosmic-proposed) [4:5.13.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (cosmic-proposed) [4.18.0-1001.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (cosmic-proposed) [18.10.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (cosmic-proposed) [3.30.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (cosmic-proposed) [4.18.0.1001.1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (cosmic-proposed) [2.12-4ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (cosmic-proposed) [2.7.6-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-artwork [source] (cosmic-proposed) [1.8]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu9]
-queuebot:#ubuntu-release- Unapproved: rejected strongswan [source] (cosmic-proposed) [5.6.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted brisk-menu [source] (cosmic-proposed) [0.5.0-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (cosmic-proposed) [1:3.26.4-0ubuntu4]
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (cosmic-proposed/main) [18.10.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: catfish (cosmic-proposed/universe) [1.4.6-0ubuntu1 => 1.4.6-1] (ubuntustudio, xubuntu) (sync)
-queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (cosmic-proposed/universe) [18.10.1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: libzstd (cosmic-proposed/main) [1.3.5+dfsg-1 => 1.3.5+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: brotli (xenial-proposed/universe) [0.3.0+dfsg-2ubuntu1 => 1.0.3-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pencil2d (cosmic-proposed/universe) [0.6.1.1-1 => 0.6.2-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pencil2d [sync] (cosmic-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- Unapproved: kannel (cosmic-proposed/universe) [1.4.4-5 => 1.4.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kannel [source] (cosmic-proposed) [1.4.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: httest (cosmic-proposed/universe) [2.4.18-1.1 => 2.4.23-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted httest [source] (cosmic-proposed) [2.4.23-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nim (cosmic-proposed/universe) [0.17.2-1ubuntu2 => 0.19.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nim [sync] (cosmic-proposed) [0.19.0-1]
-queuebot:#ubuntu-release- Unapproved: calibre (cosmic-proposed/universe) [3.31.0+dfsg-1 => 3.32.0+dfsg-1] (edubuntu, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (cosmic-proposed/main) [3.30.0-1 => 3.30.0-3] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-rbpdf (cosmic-proposed/universe) [1.19.0-1ubuntu1 => 1.19.5+ds.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-rbpdf [sync] (cosmic-proposed) [1.19.5+ds.1-1]
-queuebot:#ubuntu-release- Unapproved: entangle (cosmic-proposed/universe) [0.7.2-1ubuntu1 => 1.0-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: openshot-qt (cosmic-proposed/universe) [2.4.1+dfsg1-2 => 2.4.2+dfsg1-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: calibre (cosmic-proposed/universe) [3.31.0+dfsg-1 => 3.32.0+dfsg-1] (edubuntu, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-external-libunwind (cosmic-proposed/universe) [7.0.0+r1-4 => 8.1.0+r23-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-external-libunwind [sync] (cosmic-proposed) [8.1.0+r23-1]
#ubuntu-release 2018-09-29
-queuebot:#ubuntu-release- Unapproved: gnome-pkg-tools (cosmic-proposed/universe) [0.20.2ubuntu2 => 0.20.2ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-core (cosmic-proposed/universe) [1:8.1.0+r23-1~stage1.2 => 1:8.1.0+r23-1~stage1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-core [source] (cosmic-proposed) [1:8.1.0+r23-1~stage1.2ubuntu1]
-queuebot:#ubuntu-release- New source: woff2 (xenial-proposed/primary) [1.0.2-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: android-platform-system-core [armhf] (cosmic-proposed/universe) [1:8.1.0+r23-1~stage1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-system-core [i386] (cosmic-proposed/universe) [1:8.1.0+r23-1~stage1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-system-core [arm64] (cosmic-proposed/universe) [1:8.1.0+r23-1~stage1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: alpine (cosmic-proposed/universe) [2.21+dfsg1-1build2 => 2.21+dfsg1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: curl (cosmic-proposed/main) [7.61.0-1ubuntu1 => 7.61.0-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: bind9 (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu4 => 1:9.11.4+dfsg-3ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: dovecot (cosmic-proposed/main) [1:2.3.2.1-1ubuntu2 => 1:2.3.2.1-1ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: freelan (cosmic-proposed/universe) [2.0-8ubuntu1 => 2.0-8ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: jose (cosmic-proposed/universe) [10-2build1 => 10-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libnet-dns-sec-perl (cosmic-proposed/main) [1.09-1 => 1.09-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: lua-luaossl (cosmic-proposed/universe) [20161214-1build1 => 20161214-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nghttp2 (cosmic-proposed/main) [1.32.1-1 => 1.32.1-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (cosmic-proposed/main) [2.3-1 => 2.3-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: erlang (cosmic-proposed/main) [1:20.3.8.5+dfsg-1 => 1:20.3.8.5+dfsg-1build1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ldns (cosmic-proposed/main) [1.7.0-3ubuntu6 => 1.7.0-3ubuntu7] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mariadb-connector-c (cosmic-proposed/universe) [1:3.0.6-1 => 1:3.0.6-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: haproxy (cosmic-proposed/main) [1.8.13-2 => 1.8.13-2build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openssh-ssh1 (cosmic-proposed/universe) [1:7.5p1-10 => 1:7.5p1-10build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: links2 (cosmic-proposed/universe) [2.16-1 => 2.16-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freelan [source] (cosmic-proposed) [2.0-8ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted links2 [source] (cosmic-proposed) [2.16-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mariadb-connector-c [source] (cosmic-proposed) [1:3.0.6-1build1]
-queuebot:#ubuntu-release- Unapproved: devscripts (cosmic-proposed/main) [2.18.4 => 2.18.4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted jose [source] (cosmic-proposed) [10-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted openssh-ssh1 [source] (cosmic-proposed) [1:7.5p1-10build1]
-queuebot:#ubuntu-release- Unapproved: accepted lua-luaossl [source] (cosmic-proposed) [20161214-1build2]
-queuebot:#ubuntu-release- Unapproved: unbound (cosmic-proposed/main) [1.7.3-1 => 1.7.3-1build1] (ubuntu-server)
<xnox> all of the above gain >= 1.1.1 dep on libssl1.1 instead of present >= 1.1.0 thus imho, it is worth rebuilding these.
-queuebot:#ubuntu-release- Unapproved: accepted alpine [source] (cosmic-proposed) [2.21+dfsg1-1build3]
-queuebot:#ubuntu-release- New binary: android-platform-system-core [amd64] (cosmic-proposed/universe) [1:8.1.0+r23-1~stage1.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pychromecast (cosmic-proposed/universe) [1.0.3-1 => 2.3.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pychromecast [sync] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- Unapproved: git (cosmic-proposed/main) [1:2.17.1-1ubuntu2 => 1:2.19.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: git (cosmic-proposed/main) [1:2.17.1-1ubuntu2 => 1:2.19.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: dgit (cosmic-proposed/universe) [6.11 => 6.12] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dgit [sync] (cosmic-proposed) [6.12]
<LocutusOfBorg> hello, please reject libsdl2 from unapproved cosmic queue
<LocutusOfBorg> I have to work on it some more
-queuebot:#ubuntu-release- Unapproved: ukui-desktop-environment (cosmic-proposed/universe) [1.1.1 => 1.2.0] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: rejected libsdl2 [source] (cosmic-proposed) [2.0.8+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected git [source] (cosmic-proposed) [1:2.19.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (cosmic-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (ubuntukylin)
<bluesabre> Please approve/accept elementary-xfce, the default icon theme in Xubuntu
<bluesabre> Please also ack https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1794978
<ubot5> Ubuntu bug 1794978 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 18.10" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: evince (cosmic-proposed/main) [3.30.0-3 => 3.30.0-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gddrescue (cosmic-proposed/universe) [1.22-1 => 1.23-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gddrescue [sync] (cosmic-proposed) [1.23-1]
<Lin-Buo-Ren> Hello, I would like to ask why on Ubuntu 16.04 the libjpeg9-dev package in the universe component has `Supported: 3y` in `apt show` result while the default libjpeg-dev package in the main component has only `Supported: 9m`.
<LocutusOfBorg> Lin-Buo-Ren, probably because one is in main, the other in universe, even if both provided by the same source package
<LocutusOfBorg> no, libjpeg9 is another source package, in universe
<LocutusOfBorg> while libjpeg-dev is src:jpeg-turbo in main
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu4 => 1:3.26.4-0ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-websockets (cosmic-proposed/universe) [6.0-0ubuntu1 => 6.0-0.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-websockets [sync] (cosmic-proposed) [6.0-0.1]
-queuebot:#ubuntu-release- Unapproved: osinfo-db (cosmic-proposed/universe) [0.20180917-1 => 0.20180929-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted osinfo-db [sync] (cosmic-proposed) [0.20180929-1]
<Lin-Buo-Ren> @LocutusOfBorg the problem is rather in the package in main component has only 9 months of support period
<LocutusOfBorg> seems a bug... maybe juliank ^^ can enlighten us?
<juliank> I don't know
<juliank> Lin-Buo-Ren: libjpg9-dev has 9m in release, and 3y in updates pocket
<juliank> but I can't tell you why
-queuebot:#ubuntu-release- Unapproved: doublecmd (cosmic-proposed/universe) [0.8.3-1 => 0.8.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted doublecmd [sync] (cosmic-proposed) [0.8.4-2]
<juliank> Lin-Buo-Ren: FWIW, libjpeg8 has 5y
<vorlon> Lin-Buo-Ren, juliank, LocutusOfBorg: because the scripts that generated the Supported field were buggy, no one caught it before 16.04 release went out the door, and the release pocket doesn't ordinarily get republished so this was never corrected
<juliank> vorlon: thanks
<tsimonq2> vorlon: Wait, are you staying as vorlon? :)
<wxl> split the difference and go with vorlangasek
<tsimonq2> ahahaha
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> It works.
<wxl> cjwatson: current daily of lubuntu is still showing no logo in gfxboot :(
<vorlon> tsimonq2: yeah; I should probably ask for an access list change on #ubuntu-devel at some point ;)
<vorlon> well, LP #1795075 looks rather improbable
<ubot5> Launchpad bug 1795075 in casper (Ubuntu) "Ubuntu Live session requires login" [Undecided,New] https://launchpad.net/bugs/1795075
<tsimonq2> vorlon: Why not just get an Ubuntu IRC cloak on freenode? ;)
<tsimonq2> vorlon: https://wiki.ubuntu.com/IRC/Cloaks
<tsimonq2> vorlon: That way ACLs are managed by cloak which is somewhat independent of nick...
-queuebot:#ubuntu-release- Unapproved: mutter (cosmic-proposed/main) [3.30.0-1 => 3.30.0-4] (desktop-extra, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ansible (cosmic-proposed/universe) [2.6.4+dfsg-1 => 2.6.5+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ansible [sync] (cosmic-proposed) [2.6.5+dfsg-1]
#ubuntu-release 2018-09-30
-queuebot:#ubuntu-release- Unapproved: todotxt-cli (cosmic-proposed/universe) [2.10-5 => 2.11.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted todotxt-cli [sync] (cosmic-proposed) [2.11.0-2]
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (cosmic-proposed/universe) [1.13 => 1.14] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (cosmic-proposed/universe) [1.11 => 1.12] (lubuntu)
<Lin-Buo-Ren> @vorlon Thanks for the explanation.
<tsimonq2> Please reject lubuntu-default-settings 0.14 in favor of 0.15.
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (cosmic-proposed/universe) [1.13 => 1.15] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: mailman (cosmic-proposed/main) [1:2.1.27-1 => 1:2.1.29-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: freeipa (cosmic-proposed/universe) [4.7.0~pre2-0ubuntu1 => 4.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [sync] (cosmic-proposed) [4.7.0-1]
-queuebot:#ubuntu-release- Unapproved: r-cran-etm (cosmic-proposed/universe) [1.0.4-1 => 1.0.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-etm [sync] (cosmic-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- Unapproved: gedit-plugins (cosmic-proposed/universe) [3.30.1-1 => 3.30.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gedit-plugins [sync] (cosmic-proposed) [3.30.1-2]
-queuebot:#ubuntu-release- Unapproved: simple-scan (cosmic-proposed/main) [3.30.0-1 => 3.30.1.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gwaei (cosmic-proposed/universe) [3.6.2-3build1 => 3.6.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gwaei [sync] (cosmic-proposed) [3.6.2-4]
-queuebot:#ubuntu-release- Unapproved: uwsgi (cosmic-proposed/universe) [2.0.17.1-5 => 2.0.17.1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [sync] (cosmic-proposed) [2.0.17.1-6]
-queuebot:#ubuntu-release- Unapproved: squid3 (bionic-proposed/main) [3.5.27-1ubuntu1 => 3.5.27-1ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.01.f2dbc215fdb-0ubuntu1 => 10.4+git20180830.02.f2dbc215fdb-1] (personal-fossfreedom, ubuntu-budgie) (sync)
<tsimonq2> Oh, fun. So apparently I forgot to consider that Lubuntu is still doing i386 this cycle, and that revision 1995 on our debian-cd branch should probably be done to amd64 as well. >_>
<tsimonq2> MP incoming.
<tsimonq2> infinity, vorlon: Both of you reviewed the amd64 revision at one point; could I get some eyes on https://code.launchpad.net/~tsimonq2/debian-cd/i386-start-lubuntu/+merge/355894 ?
-queuebot:#ubuntu-release- Unapproved: variety (cosmic-proposed/universe) [0.6.9-1 => 0.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted variety [sync] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- Unapproved: quixote (cosmic-proposed/universe) [2.7~b2-1.1 => 2.7~b2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted quixote [sync] (cosmic-proposed) [2.7~b2-2]
-queuebot:#ubuntu-release- Unapproved: vino (cosmic-proposed/main) [3.22.0-3ubuntu3 => 3.22.0-4ubuntu1] (ubuntu-desktop)
#ubuntu-release 2019-09-23
-queuebot:#ubuntu-release- New sync: virtualbox-ext-pack (eoan-proposed/primary) [6.0.12-2]
<tjaalton> could I get an ack/nack on https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1844132 ?
<ubot5> Launchpad bug 1844132 in mesa (Ubuntu Eoan) "FFe: Mesa 19.2.0" [Undecided,Confirmed]
<seb128> +1 from desktop team on that since the new version is required for better ice lake support, new hardware working is always better
<seb128> (just giving my opinion for our team but that's not an ack since I'm not member of the r-t)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (disco-proposed) [240-6ubuntu5.7]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1045.47]
-queuebot:#ubuntu-release- New binary: gcab [s390x] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New binary: gcab [i386] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New binary: gcab [ppc64el] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New binary: gcab [amd64] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New binary: gcab [arm64] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New binary: gcab [armhf] (eoan-proposed/main) [1.2-5] (core)
-queuebot:#ubuntu-release- New: accepted gcab [amd64] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: accepted gcab [armhf] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: accepted gcab [ppc64el] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: accepted gcab [arm64] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: accepted gcab [s390x] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: accepted gcab [i386] (eoan-proposed) [1.2-5]
-queuebot:#ubuntu-release- New: rejected virtualbox-ext-pack [source] (eoan-proposed) [6.0.12-2~build1]
<tsimonq2> infinity: Lubuntu is looking to get one more default settings upload in prior to Beta.
<tsimonq2> As I understand it, Freeze is Soon.
<tsimonq2> It involves binary NEW processing but it will be fairly straightforward.
<infinity> tsimonq2: Freeze would be this afternoon or so, yeah.
<tsimonq2> infinity: https://phab.lubuntu.me/D45 and https://phab.lubuntu.me/D47 are the changes. Phabricator seems to hate image files (or at least their review tooling does) so I'm waiting on the OP to get me the originals so I can JFD an upload with both.
<tsimonq2> infinity: The other, more serious bug is bug 1842382 that I pinged about the other day.
<ubot5> bug 1842382 in linux (Ubuntu) "/proc/self/maps paths missing on live session (was vlc won't start; eoan 19.10 & bionic 18.04 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate dailies)" [High,In progress] https://launchpad.net/bugs/1842382
<infinity> tsimonq2: Yeah, Seth's working on that.  It won't be fixed for beta, I suspect.
<tsimonq2> Okay.
-queuebot:#ubuntu-release- Unapproved: openafs (bionic-proposed/universe) [1.8.0~pre5-1ubuntu1 => 1.8.0~pre5-1ubuntu1.1] (no packageset)
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Beta Freeze | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, cheque or beer | melius malum quod cognoscis
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Beta Freeze | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, cheque or gin | melius malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: python-caja (eoan-proposed/universe) [1.22.0-1 => 1.22.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (eoan-proposed/main) [2.26.0-1ubuntu1 => 2.26.1-1] (desktop-core) (sync)
#ubuntu-release 2019-09-24
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.415 => 1.416] (desktop-core, ubuntu-server)
<mwhudson> vorlon: you might want to look at that casper upload :)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.416]
<bittin_> Time to update to Beta 3.5
<bittin> infinity: Updating to the last 19.10 Beta images now :)
<bittin> and looking forward to last Beta on Thursday evening and RC and Stable release in October :)
<bittin_> Done :)
-queuebot:#ubuntu-release- Unapproved: dkimpy-milter (eoan-proposed/universe) [1.1.0-2 => 1.1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dkimpy-milter [sync] (eoan-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Eoan Beta] (20101020ubuntu586) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Eoan Beta] (20190924.1) has been added
<infinity> All images are now building for Beta.  Should be done in a few hours.
 * infinity goes to bed.
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Beta] (20190924.1) has been added
-queuebot:#ubuntu-release- Unapproved: stress-ng (eoan-proposed/universe) [0.10.05-1 => 0.10.06-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (eoan-proposed) [0.10.06-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-mipsen (eoan-proposed/universe) [7ubuntu1 => 7ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-mipsen [source] (eoan-proposed) [7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libclc (eoan-proposed/universe) [0.2.0+git20190306-2 => 0.2.0+git20190827-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libclc [sync] (eoan-proposed) [0.2.0+git20190827-1]
-queuebot:#ubuntu-release- Unapproved: pocketsphinx (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2 => 0.8.0+real5prealpha+1-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pocketsphinx [source] (eoan-proposed) [0.8.0+real5prealpha+1-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (disco-proposed) [2.8.0-0ubuntu5.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Beta] (20190924) has been added
-queuebot:#ubuntu-release- Unapproved: gamemode (eoan-proposed/universe) [1.5~git20190722.4ecac89-1build1 => 1.5~git20190722.4ecac89-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gamemode [source] (eoan-proposed) [1.5~git20190722.4ecac89-1build2]
<doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/b/binutils/20190924_072646_1d504@/log.gz
<doko> where does this comparison come from, dpkg --compare-versions 2.32.90.20190917-0ubuntu1 lt 4~c4ubuntu1 ?
<doko> E: Can not find version '4~c4ubuntu1' of package 'binutils'
<doko> E: Unable to find a source package for binutils
<doko> that's the version of the binutils-mipsen source package, not the binutils package
<cjwatson> I don't speak autopkgtest very well, but just from grepping that looks like:
<cjwatson> runner/autopkgtest:472:  dpkg --compare-versions "$ver" lt "$maxver" || maxver="$ver";
<cjwatson> (from my clone of https://salsa.debian.org/ci-team/autopkgtest)
<doko> hmm, this looks too clever. some binary packages are now built from binutils-mipsen, and not from binutils anymore. wondering if we should just ignore these failures and see if things go green again once everything migrated?
<doko> Laney: ^^^ ?
<Laney> maybe, I'll look later unless someone else can look first, sorry
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu3 => 0.09.25-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.57-0ubuntu2 => 0.09.57-0ubuntu3] (no packageset)
<doko> now LP: #1845157
<ubot5> Launchpad bug 1845157 in autopkgtest (Ubuntu) "runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions" [Undecided,New] https://launchpad.net/bugs/1845157
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.1.6-1ubuntu1 => 19.2.0~rc4-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1019.19] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: xorg-server (eoan-proposed/main) [2:1.20.5+git20190820-0ubuntu3 => 2:1.20.5+git20190820-0ubuntu4] (desktop-core, xorg)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1019.19]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1019.19~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1019.19~18.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-guide (eoan-proposed/universe) [18.04.5-0ubuntu1 => 19.10.0-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: linux-meta (eoan-proposed/main) [5.3.0.12.13 => 5.3.0.13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (eoan-proposed/main) [5.3.0-12.13 => 5.3.0-13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (eoan-proposed/restricted) [5.3.0-12.13 => 5.3.0-13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-12.13 => 5.3.0-13.14] (core, kernel) (sync)
<sforshee> doko, vorlon: a kernel is currently copying out to eoan-proposed to remove the binutils dependency
<apw> though we are in beta freeze
<apw> infinity, are you doing the beta, and do we have the britney block in place already ?
<apw> ahh yes, there they are, ok
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-rabbitmq (eoan-proposed/universe) [1:1.2.0-2.2 => 1:1.2.0-2.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-rabbitmq [source] (eoan-proposed) [1:1.2.0-2.2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu8 => 1:4.0+dfsg-0ubuntu9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (eoan-proposed/universe) [19.10.8 => 19.10.9] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: unity (eoan-proposed/universe) [7.5.0+19.04.20190827-0ubuntu1 => 7.5.0+19.10.20190924-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (eoan-proposed) [7.5.0+19.10.20190924-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-13.14]
<infinity> apw: Yeah.  If we respin, we can pick up the kernel.  I didn't pick it up last night, cause testing still seemed to be ongoing.
<apw> infinity, i'll get it reviewed then ...
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-12.13 => 5.3.0-13.14] (core, kernel) (sync)
<infinity> apw: Err.  By "the kernel", I mean -12, not -13.
<apw> -13 is -12 with a binutils breaking dep removed
<infinity> But with no rdep testing, so...
<infinity> I couldn't care less about the binutils thing.
<apw> infinity, i'll leave it on the queue for another day then
<cjwatson> infinity: Could you look at https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/373141 ?  Repairs my mistake from last week
<infinity> cjwatson: "This time I actually tested".
<cjwatson> I am professional
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.52 => 2.408.53] (desktop-core)
<cjwatson> infinity: thanks.  ^-
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (eoan-proposed/main) [147 => 148] (ubuntu-desktop)
<seb128> ^ updated slideshow for ubuntu and ubuntukylin, might be worth trying to get on beta if there is a respin
<seb128> willcooke, ^ fyi
<willcooke> thanks seb128!
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-rabbitmq (bionic-proposed/universe) [1:1.2.0-2.2 => 1:1.2.0-2.2ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-rabbitmq (disco-proposed/universe) [1:1.2.0-2.2 => 1:1.2.0-2.2ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-rabbitmq (xenial-proposed/universe) [1:1.2.0-2.1 => 1:1.2.0-2.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-impatience (eoan-proposed/universe) [0.4.5-3 => 0.4.5-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-impatience [source] (eoan-proposed) [0.4.5-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fwupdate (eoan-proposed/universe) [12-6 => 12-7] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gamemode (eoan-proposed/universe) [1.5~git20190722.4ecac89-1build2 => 1.5~git20190722.4ecac89-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gamemode [source] (eoan-proposed) [1.5~git20190722.4ecac89-1build3]
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.435 => 1.436] (core)
<mapreri> bdmurray, infinity: can I get LP: #1841619 approved or something?
<ubot5> Launchpad bug 1841619 in dehydrated (Ubuntu Disco) "dehydrated: Missing ID field for new registrations" [High,In progress] https://launchpad.net/bugs/1841619
<mapreri> RAOF: â
<bdmurray> mapreri: I can review that SRU
<mapreri> cool, tia
<mapreri> bdmurray: added a comment about me running the proposed package
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.436]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (eoan-proposed) [148]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (eoan-proposed) [2:1.20.5+git20190820-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.53]
-queuebot:#ubuntu-release- Unapproved: ccls (eoan-proposed/universe) [0.20190823-3ubuntu3 => 0.20190823-4ubuntu1] (no packageset)
<bdmurray> mapreri: "on my xenial servers"? There isn't a xenial task on the bug
-queuebot:#ubuntu-release- Unapproved: accepted ccls [source] (eoan-proposed) [0.20190823-4ubuntu1]
<mapreri> bdmurray: wellâ¦ I don't have yet updated them to bionic.â¦.  if you prefer I can also tell you that I run the very same package also on trusty :3
<mapreri> I do those, and debian (buster and stretch)
<bdmurray> Okay, I see the package doesn't exist in Xenial anyway so a task isn't needed.
<bdmurray> The test case could be improved so anybody unfamiliar with the software could verify it i.e. the Debian one looks good.
<mapreri> It's annoying to test, as you need to get on a machine reachable by the internet through a domain name, and register, and request a certificate, etc
-queuebot:#ubuntu-release- Unapproved: accepted dehydrated [source] (disco-proposed) [0.6.2-2ubuntu0.19.04.1]
<mapreri> thanks :)
<bdmurray> mapreri: re 18.04 is there any automated testing of the package? There are quite a few changes in this diff.
<mapreri> bdmurray: nothing automated, no.
<mapreri> bdmurray: I considered backporting the whole thing (with a version that is known to work well by many) to be much much safer than try to patch in everything neededâ¦
<bdmurray> mapreri: Okay, I'm just curious what kind of regression testing can / will be done.
<mapreri> bdmurray: from my side I'll (once again) install that updated package, request a new account, renew expiring certs
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (eoan-proposed/universe) [1:9~+rc5-1~exp1 => 1:9~+rc5-1~exp2~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dehydrated [source] (bionic-proposed) [0.6.2-2ubuntu0.18.04.1]
<mapreri> thank you!
 * mapreri â afk
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.7]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (disco-proposed) [0.31-0ubuntu1.2]
<bdmurray> ddstreet: bug 1759836 is missing SRU information in the description
<ubot5> bug 1759836 in bluez (Ubuntu Disco) "systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez" [Medium,In progress] https://launchpad.net/bugs/1759836
<ddstreet> bdmurray damn, sorry, will add it now
<bdmurray> ddstreet: okay, let me know
<ddstreet> bdmurray sorry again, i just updated description to add sru template info
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (disco-proposed) [1:3.1+dfsg-2ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: accepted bluez [source] (disco-proposed) [5.50-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted csh [source] (disco-proposed) [20110502-4ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted csh [source] (bionic-proposed) [20110502-3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (disco-proposed) [0.09.57-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-rabbitmq [source] (disco-proposed) [1:1.2.0-2.2ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: flatpak (disco-proposed/universe) [1.2.4-1 => 1.2.5-0ubuntu0.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: flatpak (bionic-proposed/universe) [1.0.8-0ubuntu0.18.04.1 => 1.0.9-0ubuntu0.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted bluez [source] (bionic-proposed) [5.48-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-rabbitmq [source] (bionic-proposed) [1:1.2.0-2.2ubuntu0.18.04.1]
<bdmurray> connor_k: the test case in bug 1839890 should say "install the version of openafs from -proposed" not build the package with a patch and install it
<ubot5> bug 1839890 in openafs (Ubuntu Bionic) "openafs 1.8.0~pre5-1ubuntu1 fails to build on 5.0 kernels" [Medium,In progress] https://launchpad.net/bugs/1839890
<connor_k> bdmurray, that was written before it entered -proposed :-) I'll update it
<bdmurray> connor_k: who was the audience for it then?
<connor_k> bdmurray, anyone that wanted to confirm my patch worked before it entered proposed
<bdmurray> connor_k: My guess is those people don't need instructions
-queuebot:#ubuntu-release- Unapproved: accepted openafs [source] (bionic-proposed) [1.8.0~pre5-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted v4l2loopback [source] (bionic-proposed) [0.10.0-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted nat-rtsp [source] (bionic-proposed) [0.7+1.g2ea3cb6-1ubuntu1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted xtables-addons [source] (bionic-proposed) [3.0-0.1ubuntu3]
<bdmurray> coreycb: Could you add some SRU inforamtion to bug 1782922?
<ubot5> bug 1782922 in keystone (Ubuntu Disco) "LDAP: changing user_id_attribute bricks group mapping" [Medium,Triaged] https://launchpad.net/bugs/1782922
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-rabbitmq [source] (xenial-proposed) [1:1.2.0-2.1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.27]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.16]
<coreycb> bdmurray: updated, thanks
-queuebot:#ubuntu-release- Unapproved: xe-guest-utilities (eoan-proposed/main) [7.10.0-0ubuntu1 => 7.10.0-0ubuntu2] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: efivar (eoan-proposed/main) [37-2ubuntu1 => 37-2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (eoan-proposed/main) [1:19.04.7 => 1:19.04.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted efivar [source] (eoan-proposed) [37-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (eoan-proposed) [19.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (eoan-proposed) [19.10.9]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (eoan-proposed) [1:19.04.8]
#ubuntu-release 2019-09-25
<Wimpress> Found a release critical issue in Ubuntu MATE 19.10.
<Wimpress> I have a suitable workaround, which is to seed cryptsetup to prevent Ubiquity automatically removing.
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (eoan-proposed/universe) [1.252 => 1.253] (ubuntu-mate)
<Wimpress> Could someone plase let that one ^ in please? I need to respin the Ubuntu MATE iso.
<Wimpress> If you could also let ubuntu-mate-artwork 19.10.9 through too, that would be great. New wallpaper in that, so would be good to have on the beta.
<infinity> Wimpress: That bug's been there since cosmic or disco...
<infinity> Wimpress: I'm going to find a proper solution to it, but I don't consider it beta critical.
<infinity> Wimpress: Also, I'm respinning later for an efivars bug, so no need to do it yourself.
<Wimpress> infinity: Thanks for taking a look.
<Wimpress> It has been fixed in the past.
<Wimpress> Ubuntu MATE is the only flavour exhibiting the issue.
<Wimpress> Any chance you can let that update meta package in for the time being.
<infinity> Wimpress: Uhh.  MATE is very much not the only flavour with the cryptsetup issue.
<Wimpress> The issue is a post-install `apt autoremove` will remove cryptsetup and then the system won't come up on reboot.
<infinity> Wimpress: Yes.  That's not specific to MATE.
<Wimpress> infinity: Well, we've tested several flavours this evening.
<infinity> Not very well, then?
<Wimpress> Well enough to demonstrate that the issue isn't present in Ubuntu, Xubuntu and Kubuntu.
<infinity> I mean, I know for a fact it's in Ubuntu and Xubuntu.
<Wimpress> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1841672
<ubot5> Launchpad bug 1841672 in livecd-rootfs (Ubuntu Eoan) "CryptSetup packages should not be removed by `apt-get autoremove` on system installed with encryption and LVM" [Undecided,Triaged]
<infinity> Kubuntu has the same workaround you're about to do here.
<Wimpress> https://bugs.launchpad.net/ubuntu/eoan/+source/ubuntu-mate-meta/+bug/1801629
<ubot5> Launchpad bug 1801629 in ubuntu-mate-meta (Ubuntu Eoan) "direct dependencies of ubiquity should not be autoremovable" [Critical,Fix committed]
<Wimpress> Those bugs have some background.
<Wimpress> Ahh, interesting about Kubuntu.
<Wimpress> So, is that a no on the workaround meta package?
<infinity> Anyhow, I'll let it in like this for now.
<Wimpress> Cheers. Much appreciated.
<infinity> Nah, if you want to do this for now, whatevs.  But we need to fix it in ubiquity to get it fixed properly.
<infinity> (and in calamares, for the weirdos that use that)
<infinity> Basically, the short answer is that "if we install on lvm, crypt, btrfs, etc, we should mark those packages manually installed".
<Wimpress> Yeah, I realise a proper fix is required. Was just trying to find a way to prevent unexpected breakage.
<Wimpress> infinity: Right.
<infinity> But I will reiterate that this bug has been there for two cycles, so people just fail at testing, apparently.
<Wimpress> https://git.launchpad.net/livecd-rootfs/commit/?id=b2db5bf3658f33dfaf3261bdc73f41be72acd374
<Wimpress> That was an attempt to fix the issue.
<infinity> I know.
<Wimpress> With people claiming the issue was fixed.
<Wimpress> And Ubuntu MATE 19.04 is fine.
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (eoan-proposed) [1.253]
-queuebot:#ubuntu-release- Unapproved: accepted xe-guest-utilities [source] (eoan-proposed) [7.10.0-0ubuntu2]
<infinity> People claim a lot of things.  I'll be doing a deep dive on it later this week.
<infinity> Oh, 19.04 might have been fine because we broke it differently.  Right.
<infinity> Then we unbroke it.
<infinity> Which returns it to broken.
<infinity> Anyhow.  Will sort later.  Don't worry about your respins.  I'll do them before bed.
<Wimpress> infinity: Thank you.
<Wimpress> infinity: I confirm the Xubuntu 19.10 daily is not affected.
<Wimpress> Just retested it.
<infinity> How bizarre.
<Wimpress> ikr
<Wimpress> Ubuntu Desktop 19.10 daily is also not affected.
-queuebot:#ubuntu-release- Unapproved: wlcs (eoan-proposed/universe) [1.1.0-0ubuntu2 => 1.1.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wlcs [source] (eoan-proposed) [1.1.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-budgie-meta (eoan-proposed/universe) [0.51 => 0.52] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (eoan-proposed) [0.52]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-meta (eoan-proposed/universe) [0.38 => 0.39] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (eoan-proposed) [0.39]
-queuebot:#ubuntu-release- Unapproved: debian-keyring (eoan-proposed/universe) [2019.08.23 => 2019.09.24] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-keyring [sync] (eoan-proposed) [2019.09.24]
-queuebot:#ubuntu-release- Unapproved: tiff (eoan-proposed/main) [4.0.10+git190818-1 => 4.0.10+git190903-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.9 => 19.10.10] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (eoan-proposed) [19.10.10]
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.9 => 19.10.10] (core)
<vorlon> infinity: ^^ beta-critical; out-of-date udebs. including apt-setup, which is needed to restore i386 foreign-arch on amd64.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Eoan Beta] has been updated (20190925)
<vorlon> (self-reviewing and accepting)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.10]
<jibel> FYI, 2 showstoppers on ubuntu desktop right now for beta: bug 1844509 and bug 1845198
<ubot5> bug 1844509 in ubiquity (Ubuntu Eoan) "ubiquity-dm fails to start" [Critical,Confirmed] https://launchpad.net/bugs/1844509
<ubot5> bug 1845198 in gnome-shell (Ubuntu Eoan) "GNOME Shell seemingly locked up at login" [Critical,Confirmed] https://launchpad.net/bugs/1845198
<infinity> vorlon: If only that had happened before I pressed the mass rebuild button. :/
<infinity> Oh well.
 * infinity cancels them all.
<infinity> vorlon: Aaand, broken X gives you an FTBFS.  Fixing.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.4]
<infinity> jibel: I'll build fresh ISOs with the other bits that have landed anyway.  If either bug mysteriously goes away, you can side-eye that really hard.  Otherwise, I'll expect fixes when I wake up. :P
-queuebot:#ubuntu-release- Unapproved: bolt (eoan-proposed/main) [0.8-3~ubuntu3 => 0.8-4] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (eoan-proposed/universe) [8.0.1-1 => 9.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (eoan-proposed) [9.0.0-0ubuntu1]
<tjaalton> infinity: broken X?
<infinity> tjaalton: FTBFS on amd64, making it uninstallable on !amd64.
-queuebot:#ubuntu-release- Unapproved: intel-opencl-clang (eoan-proposed/universe) [8.0.1-0ubuntu2 => 9.0.0-0ubuntu1] (no packageset)
<tjaalton> huh
-queuebot:#ubuntu-release- Unapproved: accepted intel-opencl-clang [source] (eoan-proposed) [9.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libgdata (eoan-proposed/main) [0.17.11-1 => 0.17.11-3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [i386] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [ppc64el] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
<infinity> tjaalton: To be clear, I didn't "fix" anything, I just deleted it from -proposed. :P
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [amd64] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
<infinity> tjaalton: Feel free to actually upload a fix.
<tjaalton> I don't understand what would break it
<tjaalton> as if it didn't hit build-indep:
<tjaalton> I only added a new patch in the new version
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [armhf] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [arm64] (eoan-proposed/universe) [9.0.0-0ubuntu1] (no packageset)
<infinity> tjaalton: Could be debhelper's fault, I suppose.
<tjaalton> yeah
<tjaalton> the patch is semi-urgent only for a bionic sru, so I'll try to figure out what caused this
<tjaalton> should happen on debian too
<tjaalton> and does
<Laney> were those cancelled livefs builds on purpose?
<Laney> infinity:
<cjwatson> Laney: IRC from 05:30 UTC
<Laney> ah yes, thanks
<Laney> something is really wrong with page up/page down in my irssi/tmux
<Laney> it only pages up half the screen, and then when I page down it's replaced by different contents
<apw> Laney, that almost feels familiar ... is that a ncurses based thing?  i am sure i saw something similar in mutt for a little while recently
<Laney> yeah
<Laney> (I think anwyay)
<Laney> I've not tried mutt inside tmux though
<Laney> it looks like this bug which people are reporting in WSL: https://github.com/Maximus5/ConEmu/issues/1444
-queuebot:#ubuntu-release- Unapproved: mir (eoan-proposed/main) [1.4.0-0ubuntu2 => 1.4.0-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: thunderbird (eoan-proposed/main) [1:68.0+build6-0ubuntu1 => 1:68.1.0+build3-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: enigmail (eoan-proposed/universe) [2:2.0.12+ds1-1 => 2:2.1.2-0ubuntu1] (mozilla)
-queuebot:#ubuntu-release- Unapproved: mozilla-devscripts (eoan-proposed/universe) [0.53 => 0.53-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mozilla-devscripts [source] (eoan-proposed) [0.53-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] has been updated (20190925.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Beta] has been updated (20190925)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Beta] has been updated (20190925)
<rbalint> infinity, Laney: could you please merge https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/373126 to let systemd in? the armhf issue is not a regression from 241
-queuebot:#ubuntu-release- Unapproved: apt (disco-proposed/main) [1.8.3 => 1.8.4] (core)
<mdeslaur> could someone please release python-django? it's a security update and all tests are now passing
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Beta] has been updated (20190925)
<infinity> rbalint: We're in the middle of a freeze, systemd isn't going in anyway.
<infinity> mdeslaur: Can it wait until Thursday?
<mdeslaur> infinity: sure
<mdeslaur> infinity: what's thursday?
<infinity> mdeslaur: Beta.
<mdeslaur> oh sure, no rush
-queuebot:#ubuntu-release- Unapproved: libdrm (eoan-proposed/main) [2.4.99-1 => 2.4.99-1ubuntu1] (core, xorg)
<rbalint> infinity, there is a granted FFe for 242, but i can understand if you consider it too late now (LP: #1843755)
<ubot5> Launchpad bug 1843755 in systemd (Ubuntu) "[FFe] Please accept systemd 242 to Eoan" [Undecided,Confirmed] https://launchpad.net/bugs/1843755
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.3 => 1:0.5.2.4] (desktop-core, ubuntu-server)
<rbalint> infinity, so do you consider the FFe not applying anymore? then i need to switch to cherry-pick mode for eoan
-queuebot:#ubuntu-release- Unapproved: qbittorrent (eoan-proposed/universe) [4.1.6-1 => 4.1.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qbittorrent [sync] (eoan-proposed) [4.1.7-1]
-queuebot:#ubuntu-release- Unapproved: dino-im (eoan-proposed/universe) [0.0.git20190909.9950742-1 => 0.0.git20190916.f746ce7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dino-im [sync] (eoan-proposed) [0.0.git20190916.f746ce7-1]
<santa_> dear release wizards,
<santa_> I have seen you deleteted the latest xorg-server upload (..ubuntu4) I guess because it failed to build for amd64
<apw> santa_, "FTBFS on amd64; breaks the world"
<santa_> the ubuntu3 version also fails, I have been investigating this issue and I plan to continue this afternoon. if you don't have any objections I plan to send a mail to ubuntu-devel explaining all the thing
<santa_> (once I get all the data)
<tjaalton> santa_: it's because of debhelper
<tjaalton> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941128
<ubot5> Debian bug 941128 in debhelper "xorg-server FTBFS" [Important,Open]
<LocutusOfBorg> please reject llvm in unapproved
<LocutusOfBorg> a new version will be syncd later
<santa_> tjaalton: ah, you are here, you are one of the persons I was expecting to talk to. I know it's debhelper. I also bisected the thing and found the offending commit
<tjaalton> cool
<tjaalton> which one?
<santa_> let me see...
<santa_> 2fd94649173464628cd732ee20834bb634fc62a2 "Rewrite sequence handling..."
<tjaalton> as I feared
<santa_> I found also another possible issue, this one with xorg-server itself
<tjaalton> ok?
<santa_> as you probably already know the xorg-server fails because of the source code tar.gz generation
<tjaalton> yes
<tjaalton> binary-indep is skipped
<tjaalton> err, build-indep
-queuebot:#ubuntu-release- Unapproved: psi-plus (eoan-proposed/universe) [1.4.554-3 => 1.4.554-3ubuntu1] (no packageset)
<LocutusOfBorg> isn't this an RC bug in Debian too?
<tjaalton> already filed
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debhelper&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
<LocutusOfBorg> I can't see...
<tjaalton> well, the severity could be bumped maybe
-queuebot:#ubuntu-release- Unapproved: accepted psi-plus [source] (eoan-proposed) [1.4.554-3ubuntu1]
<LocutusOfBorg> doko, ^^ another dh_dwz sadness
<santa_> I know. I checked with "dh build --no-act". in any case that made me look why that source code generation was done in the first place, so doing some "archeology" I found the debian bug requesting to do that...
<santa_> (lets see if I find the link haha)
<santa_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730552
<ubot5> Debian bug 730552 in src:xorg-server "provide xserver-xorg-source package for building 3rd party software (e.g. VNC) reusing XOrg codebase" [Wishlist,Fixed]
<tjaalton> yes, and?
<santa_> so apparently the guy in charge of the tigervnc wanted the source code patched and autoreconfed
<santa_> so if you open the diff he submitted you will see the source code generation happens _after_ the patching and autoreconf
<santa_> and back then, the xorg package wasn't using dh yet
<tjaalton> alright
<santa_> so if you look @ a recent xorg-server build log, for example: https://launchpadlibrarian.net/440421585/buildlog_ubuntu-eoan-amd64.xorg-server_2%3A1.20.5+git20190820-0ubuntu3_BUILDING.txt.gz
<tjaalton> yes I know
<tjaalton> they had 3y to complain ;)
<santa_> you will see the .tar.gz source generation happens before the patching and autoreconf
-queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.0.0~b1~git2019080709.0a0d55d8a-0ubuntu1 => 2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu1] (openstack, ubuntu-server)
<santa_> yes they had time to complain, I just wanted this to be known
<tjaalton> notified the person who did the conversion to dh (not me, actually)
<santa_> also I tought you might want to fix it, which could fix the FTBFS along
<santa_> of course if there's an underlying debhelper issue (it seems to me there is) that would be nice to get it fixed
<santa_> tjaalton: I could try to fix the source .tar.gz generation this afternoon if you are interested
<santa_> and test tigervnc build against it
<tjaalton> feel free
<santa_> ack. of course not an excuse to not fix debhelper
-queuebot:#ubuntu-release- Unapproved: openjdk-8 (eoan-proposed/universe) [8u232-b04-0ubuntu5 => 8u232-b04-0ubuntu6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-8 [source] (eoan-proposed) [8u232-b04-0ubuntu6]
<seb128> can the enigmail  in the queue be approved? it's a version compatible with tb 68 (which is what we have currently in eoan-proposed)
-queuebot:#ubuntu-release- Unapproved: grubzfs-testsuite (eoan-proposed/universe) [0.4 => 0.4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grubzfs-testsuite [source] (eoan-proposed) [0.4.1]
<seb128> apw, ^ can you do enigmail? or is there anyone in that tz to ping for reviews atm?
<apw> /
<apw> seb128, /me has a look
<rbalint> infinity, Laney: could you please at lease merge the systemd hints?
<seb128> apw, thx
<apw> seb128, a 1.5Mb diff ... lovely
<seb128> apw, right, well what we currently have in the archive doesn't work with the new tb
<seb128> and it's universe
<seb128> so just trust upstream and Olivier for the packaging? ;)
<apw> but a 1.5Mb diff
<seb128> I know, sorry :/
<seb128> apw, option B is to delete enigmal from eoan...
<apw> seb128, don't tempt me :)
<seb128> :)
<Laney> rbalint: I'm spinning a few plates, I will look soon
<Laney> you have other release team members in here too though
<rbalint> Laney, thanks, and their help is also welcome
<apw> seb128, see pm
<seb128> apw, I didn't get any, lack of ircnick auth?
<apw> lack of ability to use cut-n-paste it seems
<apw> oSoMoN, engimail> hey, what changed with this .js that we can include it now?
<oSoMoN> apw, the debian maintainer claims that embedding OpenPGP.js is not DFSG-compatible, but I don't see why, he says it's a binary blob, but it clearly isn't, and he hasn't responded to my questions thus far
<oSoMoN> the file isn't even minified
<apw> oSoMoN, that much is obvious from its 40K lines ...
<oSoMoN> it might not be shipped exactly as distributed upstream, but the source is there for anyone to read and inspect, so I don't see a problem with it
<oSoMoN> apw, my plan is to unblock the transition with this upload, and when the debian maintainer gets around to updating his package, we can sync back
-queuebot:#ubuntu-release- Unapproved: cinder (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu3] (openstack, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (eoan-proposed/main) [19.10.1-0ubuntu1 => 19.10.2-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (eoan-proposed/main) [1.16.0-3 => 1.16.1-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (eoan-proposed/main) [1.16.0-4 => 1.16.1-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gosa (eoan-proposed/universe) [2.7.4+reloaded3-9 => 2.7.4+reloaded3-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-compress-java (eoan-proposed/universe) [1.18-2 => 1.18-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libextractor (eoan-proposed/universe) [1:1.9-1 => 1:1.9-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libstb (eoan-proposed/universe) [0.0~git20190617.5.c72a95d-2 => 0.0~git20190817.1.052dce1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-compress-java [sync] (eoan-proposed) [1.18-3]
-queuebot:#ubuntu-release- Unapproved: accepted libstb [sync] (eoan-proposed) [0.0~git20190817.1.052dce1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libextractor [sync] (eoan-proposed) [1:1.9-2]
-queuebot:#ubuntu-release- Unapproved: accepted gosa [sync] (eoan-proposed) [2.7.4+reloaded3-10]
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.10 => 19.10.11] (core)
<Laney> That's for one of the RC bugs for beta
<Laney> rbalint: Now I'll look at your branch
-queuebot:#ubuntu-release- Unapproved: grub-installer (eoan-proposed/main) [1.128ubuntu12 => 1.128ubuntu13] (core)
<vorlon> Laney: I've just merged rbalint's branch
<vorlon> (with a fixup)
<vorlon> he had also pinged me directly
<Laney> oh right
<vorlon> rbalint: ^^ I specifically didn't drop the badtest hint for linux-oem-osp1/5.0.0-1019.21 because it's still referenced in update_excuses for migration of build-essential
<xnox> vorlon:  can you please accept https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1838525 into eoan-proposed?
<ubot5> Launchpad bug 1838525 in debian-installer (Ubuntu) "LVM setup fails to install grub on virtio storage" [Undecided,Confirmed]
<vorlon> xnox: looking.  does this require a d-i and a ubiquity respin?
<vorlon> accepted
<vorlon> probably not a d-i respin I guess, since grub-installer isn't in the initrd
<vorlon> and this only affects the classic server ISO?
-queuebot:#ubuntu-release- Unapproved: accepted grub-installer [source] (eoan-proposed) [1.128ubuntu13]
<xnox> vorlon:  reported on classic server ISO only, thus will need server iso respin.
<xnox> vorlon:  i wouldn't expect desktop to be affected as much, as I believe we run grub-installer differently and /run should be mounted in /target
<xnox> but not verified.
<xnox> on desktop, we need to install/preserve cryptsetup-initramfs packages anyway..... not sure if juliank did it yet or not
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (eoan-proposed) [19.10.11]
<vorlon> xnox: "we run grub-installer differently" - then could this change have a side effect of *un*mounting /run from target before other things are done with it?
<vorlon> xnox: cryptsetup-initramfs> I saw ubuntu-mate-meta got an upload yesterday by Wimpress that looked like a workaround for this issue
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.10 => 19.10.11] (core)
<Wimpress> vorlon: Yes, a workaround. Not a fix. Happy to revert it.
<Wimpress> When the underlying issue is resolved.
<Laney> juliank: guess you can try the ssl cert stuff now
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (eoan-proposed) [19.10.2-0ubuntu1]
<Laney> if and when there's a respin, that ubiquity should get into it
<Laney> feel free to re-upload it if you need to respin ubiquity itself, it's pushed to master
<Laney> see you
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (eoan-proposed/main) [19.10.2-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (eoan-proposed/universe) [1:9~+rc5-1~exp1 => 1:9-1] (no packageset) (sync)
<juliank> Laney: will play tomorrow
<juliank> xnox: we have a problem on desktop with cryptsetup being autoremoved that's being tracked and that was worked around in mata
<juliank> * mate
<juliank> (ubuntu-mate core, desktop started depeending on cryptsetup, ugh)
<juliank> xnox: apparently it's infinity's turn to investigate that cryptsetup further
<infinity> rbalint: By "we're in a freeze", I meant beta freeze.  As in, your urgency to migrate systemd won't make it migrate until after I'm done with beta anyway.
-queuebot:#ubuntu-release- Unapproved: rejected llvm-toolchain-9 [source] (eoan-proposed) [1:9~+rc5-1~exp2~build1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.11]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-9 [sync] (eoan-proposed) [1:9-1]
-queuebot:#ubuntu-release- Unapproved: python-blazarclient (eoan-proposed/main) [2.1.0-0ubuntu2 => 2.2.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-castellan (eoan-proposed/main) [1.3.0-0ubuntu1 => 1.3.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-ceilometermiddleware (eoan-proposed/universe) [1.3.0-0ubuntu2 => 1.5.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-cinderclient (eoan-proposed/main) [1:4.2.1-0ubuntu2 => 1:5.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glance-store (eoan-proposed/main) [0.29.1-0ubuntu1 => 1.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (eoan-proposed/main) [1:2.16.0-0ubuntu2 => 1:2.17.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-ironic-lib (eoan-proposed/universe) [2.18.0-0ubuntu1 => 2.21.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-ironic-lib [source] (eoan-proposed) [2.21.0-0ubuntu1]
<vorlon> RAOF: you appear to have promoted libxml++2.6 to main without a team subscriber
<vorlon> cpaelzer__: ^^ you appear to have signed off on the MIR without a team subscriber
-queuebot:#ubuntu-release- Unapproved: iptables (eoan-proposed/main) [1.8.3-2ubuntu4 => 1.8.3-2ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted iptables [source] (eoan-proposed) [1.8.3-2ubuntu5]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (eoan-proposed/main) [3.15.0-0ubuntu1 => 3.17.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-keystoneclient (eoan-proposed/main) [1:3.20.0-0ubuntu2 => 1:3.21.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-manilaclient (eoan-proposed/main) [1.27.0-0ubuntu3 => 1.29.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-monascaclient (eoan-proposed/main) [1.15.0-0ubuntu1 => 1.16.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-neutron-lib (eoan-proposed/main) [1.29.0-0ubuntu1 => 1.29.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-novaclient (eoan-proposed/main) [2:14.2.0-0ubuntu1 => 2:15.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-octavia-lib (eoan-proposed/universe) [1.2.0-0ubuntu1 => 1.4.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-octavia-lib [source] (eoan-proposed) [1.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-octaviaclient (eoan-proposed/main) [1.9.0-0ubuntu1 => 1.10.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-ironicclient (eoan-proposed/main) [2.8.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (eoan-proposed) [19.10.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-os-brick (eoan-proposed/main) [2.9.1-0ubuntu3 => 2.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-ken (eoan-proposed/main) [0.4.0-0ubuntu1 => 0.4.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-vif (eoan-proposed/main) [1.15.1-0ubuntu2 => 1.17.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-win (eoan-proposed/main) [4.3.0-0ubuntu1 => 4.3.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-osc-lib (eoan-proposed/main) [1.13.0-0ubuntu1 => 1.14.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.cache (eoan-proposed/main) [1.36.0-0ubuntu1 => 1.37.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.concurrency (eoan-proposed/main) [3.29.1-0ubuntu2 => 3.30.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-api-ref (eoan-proposed/universe) [1.6.1+dfsg1-0ubuntu2 => 1.6.2+dfsg1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-os-api-ref [source] (eoan-proposed) [1.6.2+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-openstacksdk (eoan-proposed/main) [0.31.1-0ubuntu2 => 0.36.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-openstackdocstheme (eoan-proposed/universe) [1.30.0-0ubuntu3 => 1.31.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-zunclient (eoan-proposed/universe) [3.3.0-0ubuntu2 => 3.5.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-zunclient [source] (eoan-proposed) [3.5.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.db (eoan-proposed/main) [5.0.1-0ubuntu1 => 5.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.i18n (eoan-proposed/main) [3.23.1-0ubuntu2 => 3.24.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.config (eoan-proposed/main) [1:6.11.0-0ubuntu1 => 1:6.11.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.context (eoan-proposed/main) [1:2.22.1-0ubuntu2 => 1:2.23.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-look (eoan-proposed/universe) [0.65 => 0.66] (ubuntustudio)
<Eickmeyer> ^ Just a wallpaper
<Eickmeyer> infinity, vorlon: ^
<vorlon> Eickmeyer: are you asking for a respin for beta?
<Eickmeyer> vorlon: I wasn't, but if it's not too much trouble to get that in, that'd be nice.
<Eickmeyer> I only got the needed .svg yesterday, sadly.
<vorlon> ok.  the delta to debian/ubuntustudio-wallpapers-disco.install looks wrong fwiw
<Eickmeyer> Really? That's odd.
<Eickmeyer> I didn't even touch that file.
<Eickmeyer> vorlon: If that's the case, is there anything I need to do?
<vorlon> Eickmeyer: you should probably fix that and reupload
<Eickmeyer> vorlon: ack, will do. Feel free to reject, I'll take a look at what's going on.
-queuebot:#ubuntu-release- Unapproved: rejected ubuntustudio-look [source] (eoan-proposed) [0.66]
-queuebot:#ubuntu-release- Unapproved: python-oslo.privsep (eoan-proposed/main) [1.33.1-0ubuntu2 => 1.33.3-0ubuntu1] (ubuntu-server)
<vorlon> seb128: syncing a new upstream version of libarchive that drops a binary package that has reverse-build-dependencies hardly seems like a feature-freeze-appropriate change
-queuebot:#ubuntu-release- Unapproved: python-oslo.log (eoan-proposed/main) [3.44.0-0ubuntu4 => 3.44.1-0ubuntu1] (openstack, ubuntu-server)
<vorlon> seb128: so, can you please follow up on mtree-netbsd so that we can remove the NBS bsdtar?
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.log [source] (eoan-proposed) [3.44.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (eoan-proposed/main) [3.38.0-0ubuntu3 => 3.38.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-openstackclient (eoan-proposed/main) [3.19.0-0ubuntu2 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.serialization (eoan-proposed/main) [2.29.1-0ubuntu3 => 2.29.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.rootwrap (eoan-proposed/main) [5.16.0-0ubuntu2 => 5.16.1-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> vorlon: found the problem, absolutely right, there should've been no diff on that file. Reuploading.
-queuebot:#ubuntu-release- Unapproved: python-oslo.reports (eoan-proposed/main) [1.29.2-0ubuntu2 => 1.30.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-look (eoan-proposed/universe) [0.65 => 0.66] (ubuntustudio)
<Eickmeyer> vorlon: ^ There it is.
<seb128> vorlon, ups, sorry about that, will fix it, thanks for pointing it out!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-look [source] (eoan-proposed) [0.66]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.rootwrap [source] (eoan-proposed) [5.16.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: devscripts (eoan-proposed/main) [2.19.6 => 2.19.6ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: mtree-netbsd (eoan-proposed/universe) [20180822-4 => 20180822-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mtree-netbsd [source] (eoan-proposed) [20180822-4ubuntu1]
<seb128> vorlon, fixed, sorry for overlooking that it had a reverse-build-depends; I'm not sure that I agree that the dropping of an old transitional binary with 1 rdepends is worth ffe paperwork though (or worth adding a delta to reverse the removal over Debian instead of just fixing the rdepends)
<vorlon> seb128: thanks for following through!  ok, I didn't check that it was transitional - though clearly there were still references to it, so that's the important part to clean up
<seb128> yeah, I looked at rdepends, should have checked with -b as well, my fault
<seb128> it should be all good now so we can move on :-)
-queuebot:#ubuntu-release- Unapproved: accepted python-caja [source] (eoan-proposed) [1.22.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: backblaze-b2 (eoan-proposed/universe) [1.3.8-2 => 1.3.8-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted backblaze-b2 [source] (eoan-proposed) [1.3.8-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.10 => 20101020ubuntu543.11] (core)
-queuebot:#ubuntu-release- New: accepted virtualbox-ext-pack [sync] (eoan-proposed) [6.0.12-2]
-queuebot:#ubuntu-release- New binary: virtualbox-ext-pack [amd64] (eoan-proposed/none) [6.0.12-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-keystoneclient [source] (eoan-proposed) [1:3.21.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (disco-proposed) [6.0.6-1ubuntu1.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (bionic-proposed) [5.2.32-1~ubuntu18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (xenial-proposed) [5.1.38-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: buildstream (eoan-proposed/universe) [1.2.4-1 => 1.2.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildstream [source] (eoan-proposed) [1.2.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-castellan [source] (eoan-proposed) [1.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-ceilometermiddleware [source] (eoan-proposed) [1.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted virtualbox-ext-pack [amd64] (eoan-proposed) [6.0.12-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-blazarclient [source] (eoan-proposed) [2.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: custodia (eoan-proposed/universe) [0.6.0-3 => 0.6.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.11]
-queuebot:#ubuntu-release- Unapproved: duplicity (eoan-proposed/main) [0.8.04-2 => 0.8.04-2ubuntu1] (ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted custodia [source] (eoan-proposed) [0.6.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-cinderclient [source] (eoan-proposed) [1:5.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gitlint (eoan-proposed/universe) [0.9.0-2 => 0.9.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gitlint [source] (eoan-proposed) [0.9.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-keysign (eoan-proposed/universe) [1.0.1-3 => 1.0.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keysign [source] (eoan-proposed) [1.0.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ionit (eoan-proposed/universe) [0.3.3-1 => 0.3.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-glance-store [source] (eoan-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pagemon (eoan-proposed/universe) [0.01.16-1 => 0.01.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ionit [source] (eoan-proposed) [0.3.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pagemon [sync] (eoan-proposed) [0.01.17-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-glanceclient [source] (eoan-proposed) [1:2.17.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: knack (eoan-proposed/universe) [0.6.2-1 => 0.6.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-keystoneauth1 [source] (eoan-proposed) [3.17.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted knack [source] (eoan-proposed) [0.6.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pathspider (eoan-proposed/universe) [2.0.1-2 => 2.0.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-manilaclient [source] (eoan-proposed) [1.29.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pathspider [source] (eoan-proposed) [2.0.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pylint-flask (eoan-proposed/universe) [0.5-3 => 0.5-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-monascaclient [source] (eoan-proposed) [1.16.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pylint-flask [source] (eoan-proposed) [0.5-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-neutron-lib [source] (eoan-proposed) [1.29.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-stetl (eoan-proposed/universe) [2.0+ds-1 => 2.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-stetl [source] (eoan-proposed) [2.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-novaclient [source] (eoan-proposed) [2:15.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-trio (eoan-proposed/universe) [0.11.0-1 => 0.11.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-trio [source] (eoan-proposed) [0.11.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-octaviaclient [source] (eoan-proposed) [1.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-ttystatus (eoan-proposed/universe) [0.38-2 => 0.38-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-ironicclient [source] (eoan-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-ttystatus [source] (eoan-proposed) [0.38-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ranger (eoan-proposed/universe) [1.9.2-4 => 1.9.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ranger [source] (eoan-proposed) [1.9.2-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-brick [source] (eoan-proposed) [2.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: uranium (eoan-proposed/universe) [3.3.0-1 => 3.3.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uranium [source] (eoan-proposed) [3.3.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-ken [source] (eoan-proposed) [0.4.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-os-vif [source] (eoan-proposed) [1.17.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vmdb2 (eoan-proposed/universe) [0.13.2+git20190215-1 => 0.13.2+git20190215-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-os-win [source] (eoan-proposed) [4.3.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vmdb2 [source] (eoan-proposed) [0.13.2+git20190215-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vmware-nsx (eoan-proposed/universe) [14.0.0~b1~git2019062013.30eab6bb8-0ubuntu1 => 14.0.0~b1~git2019062013.30eab6bb8-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-osc-lib [source] (eoan-proposed) [1.14.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vmware-nsx [source] (eoan-proposed) [14.0.0~b1~git2019062013.30eab6bb8-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.cache [source] (eoan-proposed) [1.37.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.concurrency [source] (eoan-proposed) [3.30.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstacksdk [source] (eoan-proposed) [0.36.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackdocstheme [source] (eoan-proposed) [1.31.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.db [source] (eoan-proposed) [5.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.i18n [source] (eoan-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcloudproviders (eoan-proposed/universe) [0.3.0-1 => 0.3.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libcloudproviders [sync] (eoan-proposed) [0.3.0-3]
#ubuntu-release 2019-09-26
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (bionic-proposed) [1.8.8-1ubuntu0.5]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.config [source] (eoan-proposed) [1:6.11.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.context [source] (eoan-proposed) [1:2.23.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.privsep [source] (eoan-proposed) [1.33.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libcloudproviders [amd64] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcloudproviders [armhf] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcloudproviders [ppc64el] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcloudproviders [arm64] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcloudproviders [s390x] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcloudproviders [i386] (eoan-proposed/universe) [0.3.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.middleware [source] (eoan-proposed) [3.38.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [amd64] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [armhf] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [ppc64el] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [arm64] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [s390x] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- New: accepted libcloudproviders [i386] (eoan-proposed) [0.3.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackclient [source] (eoan-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.serialization [source] (eoan-proposed) [2.29.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.reports [source] (eoan-proposed) [1.30.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (eoan-proposed) [2.19.6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted duplicity [source] (eoan-proposed) [0.8.04-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (eoan-proposed) [2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] has been updated (20190926)
<infinity> ...
<infinity> Who's rebuilding stuff under my nose? :/
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Beta] has been updated (20190926)
<Eickmeyer> infinity: I triggered Studio, I didn't expect everything else would follow suit.
<Eickmeyer> Funny because I had just finished syncing my isos. Again.
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Beta] has been updated (20190926)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Beta] has been updated (20190926)
<infinity> Eickmeyer: Everything needed a rebuild because of changes today.  Luckily, yours got all of them so I didn't have to re-do it.
<infinity> Uhm, but someone decided to re-do MATE anyway?  :P
 * infinity shrugs.
<infinity> Too many cooks in the kitchen.
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.416 => 1.417] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Beta] has been updated (20190926)
<infinity> Wimpress: How many times are you going to rebuild MATE? :)
<infinity> (assuming that was you)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: vmdb2 (eoan-proposed/universe) [0.13.2+git20190215-1ubuntu1 => 0.13.2+git20190215-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vmdb2 [source] (eoan-proposed) [0.13.2+git20190215-1ubuntu2]
<vorlon> Laney, juliank: rabbitmq got unhappy and stopped servicing retry requests; restarted it
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.8-0ubuntu0~18.04.2 => 19.0.8-0ubuntu0~18.04.3] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: django-hijack (eoan-proposed/universe) [2.1.7-1 => 2.1.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted django-hijack [source] (eoan-proposed) [2.1.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: django-compat (eoan-proposed/universe) [1.0.15-2 => 1.0.15-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted django-compat [source] (eoan-proposed) [1.0.15-2ubuntu1]
<cpaelzer> vorlon: thanks for spotting this, really my bad, I did state the condition of a team subscriber on my actual review (comment #1) but when security was done as well forgot that this had to be rechecked before it can move on
<cpaelzer> vorlon: RAOF: I've sent a mail to get this resolved - I didn't want it to be only an IRC ping that might be forgotten
<RAOF> cpaelzer: Thanks. I'd temporarily subscribed myself to libxml++ bugmail until I could get someone to subscribe ~mir-team. I thought Saviq owned it!
<cpaelzer> I checked the group and only found Alex as admin
<cpaelzer> Alan
<cpaelzer> you might yourself request membership there as well :-)
<RAOF> Yeah, I hadn't checked the group. I just assumed.
<RAOF> Saviq should probably be on the team, too, as the manager :)
<oSoMoN> apw, good morning! Are you (still) reviewing my enigmail upload in the eoan queue?
-queuebot:#ubuntu-release- Unapproved: ionit (eoan-proposed/universe) [0.3.3-1ubuntu1 => 0.3.3-1ubuntu2] (no packageset)
<seb128> apw, hey, so what was the conclusion for enigmail? looks like we got stucked, can we have a ack/nack, the problem isn't going to resolve by just sitting on it and the more we wait the less testing we get for the new thunderbird and the more problematic that is, ideally we would have got in beta but lack of queue reviewing makes us miss it
<seb128> oSoMoN, we are on the same timing it looks like!
<LocutusOfBorg> thanks vorlon for the pylint fixup, I fixedup your fixup because ionit still needed a change in debian/tests/control file :D
-queuebot:#ubuntu-release- Unapproved: accepted ionit [source] (eoan-proposed) [0.3.3-1ubuntu2]
<seb128> LocutusOfBorg, do you know what's the end goal of those pylint changes?
<LocutusOfBorg> seb128, pylint was python2, pylint3 was python3
<LocutusOfBorg> now python2 is dying, so pylint3 has been renamed to pylint
<LocutusOfBorg> I would have added just a "Provides" and kicked it after some months, but Debian is going faster on that way
<seb128> LocutusOfBorg, right, but do we need to fix all rdepends before Debian rather than just providing a transitional or provides?
<seb128> well what Debian is doing at this point isn't impacting eoan since we are in sync freeze right?
<LocutusOfBorg> debian is in the middle of the transition, we just ended it before them
<LocutusOfBorg> reason that they can't just upload changes is that I had to manually fix dh-python to stop doing the bad replace
<LocutusOfBorg> their dh-python is fixed in git but not uploaded
<LocutusOfBorg> so, they will likely need to apply all our patches to end their transition too, after dh-python is fixed
<LocutusOfBorg> funny thing, when I opened an rc bug against pylint http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940012
<ubot5> Debian bug 940012 in src:pylint "pylint: renaming broke reverse-dependencies" [Normal,Fixed]
<LocutusOfBorg> they just relaxed the breaks relationship, to slow down the need of a transition
<jibel> kernel panic on dell xps with the beta cf bug 1845454
<ubot5> bug 1845454 in linux (Ubuntu) "Dell XPS 13 7390 - Kernel panic with 19.10 beta image" [Undecided,Incomplete] https://launchpad.net/bugs/1845454
<jibel> apw ^
<jibel> apw, could someone from kernel have a look?
<seb128> LocutusOfBorg, k, seems suboptimal to add diff to our packages which we aren't forwarding back to the BTS but hopefully they fix it before next cycle anyway and we can sync those back without too much work wasted
<apw> oSoMoN, i guess as long as you are happy to deal with the fakesyncs if they choose to make a different orig, we are ok
<apw> sforshee, ^
<apw> jibel, ack
<oSoMoN> apw, yeah, that'll most likely be necessary, and I'm happy to deal with it
<seb128> oSoMoN, it doesn't have to
<seb128> we could fake rename to a version just lower so we are able to sync a debian update
<seb128> oSoMoN, but the tarball isn't coming from upstream? usually Debian repacks it?
-queuebot:#ubuntu-release- Unapproved: accepted enigmail [source] (eoan-proposed) [2:2.1.2-0ubuntu1]
<oSoMoN> seb128, debian repacks the upstream tarball to strip some bits, whereas I used it unmodified
<seb128> k, right
<seb128> well they +ds name it
<seb128> so there is no conflict and we should be able to sync if wanted
<apw> then we will be ok
<seb128> apw, thx for the review and accepting it!
<oSoMoN> apw, thanks!
<oSoMoN> there's also a thunderbird upload in the queue that needs review (new upstream release, drops a patch that was upstreamed and refreshes another one)
<oSoMoN> seb128, can you please retry the enigmail autopkgtests with trigger jsunit/0.2.2-1 for all architectures? I'm not allowed to do it myself
<seb128> oSoMoN, k
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (eoan-proposed/main) [1.16.0-3ubuntu2 => 1.16.1-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.service (eoan-proposed/main) [1.40.0-0ubuntu2 => 1.40.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslotest (eoan-proposed/universe) [1:3.8.0-0ubuntu1 => 1:3.8.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-oslo.upgradecheck (eoan-proposed/main) [0.3.1-0ubuntu1 => 0.3.2-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.utils (eoan-proposed/main) [3.41.0-0ubuntu3 => 3.41.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.vmware (eoan-proposed/main) [2.34.0-0ubuntu3 => 2.34.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-osprofiler (eoan-proposed/main) [2.8.1-0ubuntu1 => 2.8.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-tenacity (eoan-proposed/main) [5.0.4-0ubuntu1 => 5.1.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-taskflow (eoan-proposed/main) [3.7.0-0ubuntu3 => 3.7.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-tooz (eoan-proposed/main) [1.66.0-0ubuntu1 => 1.66.2-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: stevedore (eoan-proposed/main) [1:1.30.1-0ubuntu2 => 1:1.31.0-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-qinlingclient (eoan-proposed/universe) [2.2.0-0ubuntu1 => 4.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-swiftclient (eoan-proposed/main) [1:3.8.0-0ubuntu3 => 1:3.8.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-saharaclient (eoan-proposed/main) [2.2.1-0ubuntu1 => 2.3.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-vitrageclient (eoan-proposed/universe) [2.7.0-0ubuntu2 => 3.0.0-0ubuntu1] (no packageset)
<jamespage> hi release team - sahid, coreycb and I are working on the RC's for OpenStack - so quite a few uploads today/tomorrow to support that - all will have 'New upstream release for OpenStack Train' in the changelog entry
-queuebot:#ubuntu-release- Unapproved: accepted python-qinlingclient [source] (eoan-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-vitrageclient [source] (eoan-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.53 => 2.408.54] (desktop-core)
<cjwatson> infinity: ^- appropriate amount of grovelling re livecd-rootfs.  The bug has details of the more strenuous tests I've done this time
<jibel> infinity, another critical bug on the beta: bug 1845466
<ubot5> bug 1845466 in mokutil (Ubuntu) "Dell XPS 13 7390 - "Failed to start MokManager" error when trying to install 3rd party driving during install, leading to unbootable device" [Critical,Confirmed] https://launchpad.net/bugs/1845466
-queuebot:#ubuntu-release- Unapproved: mate-power-manager (eoan-proposed/universe) [1.22.2-0ubuntu1 => 1.22.2-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: python-ovsdbapp (eoan-proposed/main) [0.16.0-0ubuntu2 => 0.17.0-0ubuntu1] (ubuntu-server)
<Laney> cyphermox: ^^^^ that bug is likely for you ?
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: networking-bagpipe (eoan-proposed/universe) [11.0.0~b2~git2019080116.f8139b0-0ubuntu1 => 11.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-odl (eoan-proposed/universe) [1:15.0.0~b2~git2019080116.0aa158478-0ubuntu1 => 1:15.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-sfc (eoan-proposed/universe) [9.0.0~b2~git2019080111.7fb0207-0ubuntu1 => 9.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (eoan-proposed/main) [2:15.0.0~b1~git2019080821.66dfa3f57-0ubuntu1 => 2:15.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: networking-bgpvpn (eoan-proposed/universe) [11.0.0~b2~git2019080820.9ec426c-0ubuntu1 => 11.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-dynamic-routing (eoan-proposed/universe) [2:15.0.0~b2~git2019073117.7a2b807-0ubuntu1 => 2:15.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: networking-ovn (eoan-proposed/universe) [7.0.0~b2~git2019082217.e07d4316-0ubuntu1 => 7.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-bagpipe [source] (eoan-proposed) [11.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-odl [source] (eoan-proposed) [1:15.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-sfc [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-bgpvpn [source] (eoan-proposed) [11.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [source] (eoan-proposed) [2:15.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (eoan-proposed) [7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (eoan-proposed/universe) [1.16.0-3ubuntu1 => 1.16.1-1ubuntu1] (kubuntu)
<LocutusOfBorg> mwhudson, hello, I have a general question, pathspider is blocked in -proposed, and out from testing, rc buggy and so on... why isn't on this list? https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/rcbuggy-problem-packages.html
<LocutusOfBorg> also, can an AA ^^ please do the magick? debian bug: 906500
<ubot5> Debian bug 906500 in src:pathspider "pathspider: FTBFS in buster/sid (autobuilder hangs)" [Serious,Open] http://bugs.debian.org/906500
-queuebot:#ubuntu-release- Unapproved: gitlint (eoan-proposed/universe) [0.9.0-2ubuntu1 => 0.12.0-0.1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gitlint [source] (eoan-proposed) [0.12.0-0.1~build1]
<LocutusOfBorg> vorlon, ^^ I fixed it up
<LocutusOfBorg> the only remaining stuff to kick out is pathspider, I can't fix it
-queuebot:#ubuntu-release- Unapproved: pidgin (eoan-proposed/universe) [1:2.13.0-2ubuntu1 => 1:2.13.0-2.2ubuntu1] (kubuntu)
<LocutusOfBorg> ^^ there is a python3 fix
<LocutusOfBorg> we are already python3 on that package
-queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.0~b2~git2019082812.5aa5d61dfd-0ubuntu1 => 2:15.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu1 => 2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (eoan-proposed/universe) [1:12.0.0~b2~git2019073019.f7201517-0ubuntu2 => 1:12.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (eoan-proposed) [1:12.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openstack-trove (eoan-proposed/universe) [1:12.0.0~rc1-0ubuntu1 => 1:12.0.0~rc1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (eoan-proposed) [1:12.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: zaqar (eoan-proposed/universe) [9.0.0~b2~git2019080910.d535a96e-0ubuntu1 => 9.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zaqar [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnocchi (eoan-proposed/universe) [4.3.4-0ubuntu1 => 4.3.4-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (eoan-proposed) [4.3.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: panko (eoan-proposed/universe) [7.0.0~b2~git2019073019.07f2d20b-0ubuntu1 => 7.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted panko [source] (eoan-proposed) [7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (eoan-proposed/main) [2.22.0~b2~git2019073018.d33e569be-0ubuntu1 => 2.22.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: sdl-image1.2 (eoan-proposed/universe) [1.2.12-11 => 1.2.12-12] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: simple-xml (eoan-proposed/universe) [2.7.1-2 => 2.7.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted simple-xml [sync] (eoan-proposed) [2.7.1-3]
-queuebot:#ubuntu-release- Unapproved: trafficserver (eoan-proposed/universe) [8.0.3+ds-4build1 => 8.0.5+ds-1] (no packageset) (sync)
<LocutusOfBorg> ^^ all CVE fixes
-queuebot:#ubuntu-release- Unapproved: accepted trafficserver [sync] (eoan-proposed) [8.0.5+ds-1]
-queuebot:#ubuntu-release- Unapproved: slirp4netns (eoan-proposed/universe) [0.3.2-1 => 0.4.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted slirp4netns [sync] (eoan-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- Unapproved: python-mistral-lib (eoan-proposed/universe) [1.0.0-0ubuntu3 => 1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-mistral-lib [source] (eoan-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu5 => 2.04-1ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: fwts (eoan-proposed/universe) [19.08.00-0ubuntu1 => 19.09.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (eoan-proposed/main) [1.121 => 1.122] (core)
<doko> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1845157
<ubot5> Launchpad bug 1845157 in autopkgtest (Ubuntu) "runner/autopkgtest fails to setup env with binary packages moved to another packge, and different source/binary versions" [Undecided,New]
<doko> vorlon: ^^^
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (eoan-proposed) [19.09.00-0ubuntu1]
<vorlon> doko: is the real thing you're concerned about the fixing of this autopkgtest bug, or getting binutils-mipsen to migrate?
<doko> vorlon: the migration. it's known in Debian as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939790
<ubot5> Debian bug 939790 in autopkgtest "autopkgtest fails to find the right source version with package takeover and Built-Using" [Normal,Open]
<cyphermox> ^^^ grub2/grub2-signed fixes critical bug; missing mmx64.efi installed to /EFI/ubuntu.
-queuebot:#ubuntu-release- Unapproved: guile-2.0 (eoan-proposed/universe) [2.0.13+1-5.1ubuntu1 => 2.0.13+1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted guile-2.0 [source] (eoan-proposed) [2.0.13+1-5.2ubuntu1]
<cyphermox> could someone please review the nplan SRU in xenial unapproved queue?
<vorlon> cyphermox: shouldn't there be a versioned breaks: as well against versions of shim that do use the .signed path?
<Laney> if we're going to respin for that, I should fix ubiquity-dm for budgie I guess
<Laney> broke that with yesterday's upload :(
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: placement (eoan-proposed/universe) [2.0.0~b2~git2019073117.541052ad-0ubuntu1 => 2.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted placement [source] (eoan-proposed) [2.0.0~rc1-0ubuntu1]
<fossfreedom> Laney: thanks for the feedback for the budgie ubiquity issue. Sorry cant look at this for a few hours since am travelling
<Laney> don't IRC and drive!
<fossfreedom> Train!
<RikMills> driving a train is worse! :P
<Wimpress> It's on rails. How hard can it be?
<Wimpress> ;-)
<dannf`> mwhudson, infinity - should we now have arm64 subiquity isos in the test tracker?
<infinity> dannf`: We certainly can if we intend to release them officially this cycle.  I haven't been told that's the plan.
<dannf> infinity: oh, ok. well, we're testing them :)
<infinity> Personally, I was operating under the assumption that we'd flip everyone !x86 to subiquity as official next cycle.
<infinity> To avoid confusion doing it one at a time.
<infinity> dannf: Testing them is still good. :)
<dannf> infinity: i've no opinion on it fwiw, just didn't know if we should post test results somewhere. thx!
<powersj> dannf, I said we wouldn't until we had daily automated tests
<dannf> powersj: ack
<vorlon> why are we not waiting for daily automated tests?
<vorlon> why are we not stridently demanding automated tests?
<infinity> "wouldn't until"
<vorlon> oh
<infinity> Violent agreement ahoy.
<vorlon> sorry I read an additional "block" into that sentence ;)
<vorlon> but that's for arm64
<vorlon> my understanding is we already have automated testing for ppc64el
<vorlon> and we SHOULD be releasing ppc64el today
<infinity> Should we?
<vorlon> if the testing is there, yes
<powersj> testing is there
<vorlon> the automated testing has been in place for a whole cycle and this was the sole blocker
<infinity> I mean, I guess.  As I noted, it's messy and consufing to flip the default one arch at a time.
<infinity> "If you're on this type of machine, you get this ISO, but on another, you get this one, and..."
<vorlon> that's already the case though, x86 vs not
<infinity> Also, I thought there were still multipath presentation issues.
<infinity> Which is a huge no-no where most ppc64el machines ship with multipath by default.
<vorlon> AIUI there's a UX bug to be followed through on
<vorlon> but that's just about member devices being exposed as options when they shouldn't be
<infinity> I wouldn't downplay that.  It was RC for d-i, according to IBM at the time.
<vorlon> and I thought we were fixing that for 19.10 (mwhudson?)
<vorlon> regardless, that's not something that should be a prerequisite for it being on the tracker and going through the beta
<infinity> Well, "beta" implies "being released with final", s'all.
<infinity> It's on the tracker for dailies.
<infinity> cyphermox: Did I miss the part where you addressed vorlon's concerns about the grub change?
<vorlon> infinity: the intent is that it be releasable with final, so it should be on beta
<vorlon> it's possible we will make a call later that it's unreleasable, but we shouldn't presuppose that
<infinity> vorlon: Mmkay.  I feel like we talked about all this last week (as a side note to a larger conversation) and no one mentioned we planned to flip any arches for 19.10. :P
<infinity> I mean, "flip" being a weird word here, since we publish live and d-i side-by-side, so it's more confusing than flipping.
<vorlon> infinity: I didn't talk about flipping arches for 19.10 because I presumed this was /already done/ based on the fact that ppc64el images were sorted 19.04 release week
<infinity> Something about assumptions and asses of u and mptions.
<jibel> infinity, beta is broken on VMWare, latest image is clearly not ready
<jibel> i'll file a bug
<infinity> ...
<infinity> I'm pretty sure we're respinning for grub and ubiquity anyway (yay), but "it's broken on vmware" might not be a showstopper if it's not an obvious fix.
<infinity> vmware's like a tiny fraction of a tiny fraction of our userbase, and I suspect an even smaller fraction of people who run betas.
<infinity> (not counting testers)
<jibel> infinity, it's the change to casper 1.412+
<jibel> a function called by easyinstall has been removed
<infinity> easyinstall?
<jibel> it's the automated installation of Ubuntu with VMWare workstation.
<infinity> That sounds potentially like Not Our Bug...
<infinity> vorlon: Re: shim versus grub breaks.  Surely, it's shim that broke grub here, not the inverse.  But cyphermox seems to have wandered away from his keyboard, so I'm not sure I want to block on nitpicking that.
<infinity> Laney: How goes budgie ubiquity?
<jibel> bug 1845535
<ubot5> bug 1845535 in casper (Ubuntu) "VMWare easyinstall fails with "30custom_installation: line 59: try_mount not found"" [Critical,New] https://launchpad.net/bugs/1845535
-queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.11 => 19.10.12] (core)
<Laney> Like that
<Laney> but I didn't test it properly ...
<jibel> infinity, right, nothing we can fix but broke the API of casper and a supported guest.
<Laney> for some reason if I cowboy my changes in break=bottom it then boots to a full live session
<jibel> +we
<Laney> so :(
<infinity> jibel: I'm not sure anyone ever claimed that random functions in casper/casper-helpers were a "stable API".
<infinity> ## Casper helper functions, used by casper on boot and by casper-snapshot
<infinity> Doesn't really inspire confidence for third party use.
<Laney> ah, OK, that time it worked, maybe I didn't add only-ubiquity or something
<infinity> That said, if the function is critical to how third parties are doing things, we could add it back with a comment to that effect, even though casper itself no longer uses it.
<infinity> But ick.
<infinity> Meh.  I'll do that.  There will be time while ubiquity and grub go through testing.
<infinity> Laney: "it worked" meaning your testing passed, or just that you made it do boot things so you can test?
<Laney> the former
<infinity> Shiny.
<Laney> I mean I'm cowboying
<infinity> Care to once-over the casper that's about to hit the queue?
<Laney> so I could have made a syntax error in the upload or something
<infinity> Already debdiffed with 1.413 to confirm the re-added function is byte-identical.
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.416 => 1.417] (desktop-core, ubuntu-server)
<Laney> i.e. please actually read it
<infinity> ^
<Laney> OK
<Laney> there's a casper from mwhudson already in the queue
<infinity> Oh.
<Laney> clobber or merge?
<infinity> Lemme look.
<infinity> I can merge those, gimme two ticks.
<Laney> Your change looks good to me, no diff besides the comment compared to 1.413
<Laney> self-approve once you've reviewed the other changes
<infinity> Ta.
<cyphermox> infinity: vorlon: there was a misunderstanding; I'm fixing a mismerge in grub
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.416 => 1.418] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.417]
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.417]
<cyphermox> (it's already been fixed everywhere, including the breaks
<infinity> cyphermox: Okay.
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.12]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.418]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (eoan-proposed) [2.04-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (eoan-proposed) [1.122]
<infinity> Laney, willcooke: What's the desktop team's plan WRT LP: #1845198
<ubot5> Launchpad bug 1845198 in gnome-shell (Ubuntu Eoan) "GNOME Shell seemingly locked up at login" [Critical,In progress] https://launchpad.net/bugs/1845198
<Laney> it's worked around enough for the installer/live session case, IMHO
<Laney> there's a more full fix under review
<infinity> Kay.
<infinity> Ignoring, then.
<infinity> apw, Laney, gaughen, powersj: Since new casper and new grub means respinning the whole world, can we get some help re-testing community flavours for the poor flavours who are a bit timezone-skewed from this mess?
<infinity> Should be new images in an hour or two, with a goal to still release in 12h or so.
<jibel> infinity, can you ping me when new builds are ready to test? I'll have diner and do something else until then.
<infinity> jibel: Yarp.  Can do.
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu6 => 2.04-1ubuntu6] (core)
<infinity> jibel: If you can help find suckers to re-test flavours who thought they were done, that would be nice too. :)
<infinity> I knew I should have test-built that casper...
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.418 => 1.419] (desktop-core, ubuntu-server)
<Eickmeyer> infinity: Does that mean new build?
<infinity> Eickmeyer: There will be new builds of everything for casper/grub2/ubiquity, yes.
-queuebot:#ubuntu-release- Unapproved: rejected casper [source] (eoan-proposed) [1.419]
-queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.418 => 1.419] (desktop-core, ubuntu-server)
<Eickmeyer> infinity: Roger that. I'll be ready when they are. I have release notes done and blog post ready for whenever.
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.419]
<infinity> Eickmeyer: "whenever" will probably be around midnight my time (in ~12h), unless all the re-testing goes super fast.
<infinity> Err, for release that is.  New images will be much sooner. :P
<Eickmeyer> Ok, that's about 10-11pm my time.
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu6 => 2.04-1ubuntu6] (core)
-queuebot:#ubuntu-release- Unapproved: golang-1.13 (eoan-proposed/universe) [1.13-1ubuntu1 => 1.13.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.13 [source] (eoan-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: ceilometer (eoan-proposed/main) [1:13.0.0~b2~git2019082217.b6896c24-0ubuntu1 => 1:13.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: aodh (eoan-proposed/main) [9.0.0~b2~git2019073015.4b93caca-0ubuntu1 => 9.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.54]
 * infinity goes to grab some food while computers do computer things.
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.service [source] (eoan-proposed) [1.40.2-0ubuntu1]
<ahasenack> infinity: wrt new casper ping ~1h ago, I'm around
-queuebot:#ubuntu-release- Unapproved: golang-1.12 (eoan-proposed/main) [1.12.9-2ubuntu1 => 1.12.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: watcher (eoan-proposed/universe) [1:3.0.0~b2~git2019073117.f2020a92-0ubuntu1 => 1:3.0.0~rc1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted watcher [sync] (eoan-proposed) [1:3.0.0~rc1-0ubuntu1]
<infinity> powersj: I'm being told by the kernel team that there's a pretty nasty bug in ppc64el that will die in early boot on LPARs and most PPC VMs.
<infinity> powersj: I'm trying to reconcile that with the testing tracker telling me that ppc64el is fine. :/
<cpaelzer> paride: ^^
<cpaelzer> infinity: FYI powersj is on a conference, paride will know what worked and what didn't therefore I highlighted him on this
<cpaelzer> then we will understand why it is fine in the tracker
<infinity> cpaelzer: Ta.
<powersj> infinity, all our testing is done in VMs
<powersj> ah as cpaelzer said, paride will take a look
<infinity> *nod*
<infinity> Basically, I want to know how we got here, and have a plan to get better coverage in the future.
<infinity> But also, it all seems a bit WTF right now, with cascardo telling me he thinks it should reproduce basically anywhere you might be testing. :P
<ahasenack> is that a blocker for the release today?
<ahasenack> paride is past eod
<infinity> There won't be a fixed kernel today, so it's not a blocker in the sense that I'd hold up release for it.
<infinity> If it's genuinely broken on all things PPC, though, I'd not release PPC images.
<ahasenack> and what about that lvm on virtio bug?
<infinity> Which would be nice to know.
<ahasenack> I no longer have access to raw ppc, since they took diamond away, snif
<infinity> -ESPARSEINFO
<infinity> "That lvm on virtio bug" isn't something I have context on.
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1838525
<ubot5> Launchpad bug 1838525 in grub-installer (Ubuntu Eoan) "LVM setup fails to install grub on virtio storage" [Critical,Triaged]
<infinity> I think that's a dupe of a bug that was fixed a while ago.
<infinity> Oh, I didn't read the comments.
<infinity> So, no, looks like that also won't be fixed for beta.
<infinity> Thankfully, installing on LVM on virtio is something that normal humans don't do, only testers.
<infinity> Well, some humans might, but it's hardly the common case for VMs.
<ahasenack> hm, isn't it exactly the common case for vms? virtio?
<ahasenack> or do you mean the lvm part
<infinity> Yeah, the lvm part.
<ahasenack> k
<infinity> VM disks don't tend to be complicated enough to want LVM, and the other common LVM use-case (FDE) is also not super common in the VM world.
<infinity> So, yeah, should be fixed for release, but not beta-critical at this point.
<LocutusOfBorg> golang-1.12 is a CVEfix release
<LocutusOfBorg> like sdl-image1.2
<infinity> LocutusOfBorg: That's nice.  It can wait until the beta freeze lifts.
-queuebot:#ubuntu-release- Unapproved: ironic (eoan-proposed/universe) [1:12.2.1~b2~git2019080812.b8db11279-0ubuntu1 => 1:13.0.0-0ubuntu1] (openstack)
<vorlon> ahasenack: if you're missing access to the MAAS pool, I know someone who could get you creds
<vorlon> :P
<vorlon> infinity: the assertion this morning about LVM+virtio and the grub-installer bug was that the server d-i does LVM by default; I called bullshit but not very loudly (xnox)
<infinity> It does do LVM by default on some arches, yes.
<infinity> Irritatingly, not all of them, so it's weirdly inconsistent.
<vorlon> really? that IS irritating
<infinity> Also irritating, libtext-wrapi18n-perl and libtext-charwidth-perl have moved from depending on perl-base to full perl, pulling perl/libperl/perl-modules into minimal (because debconf)
<infinity> libtext-wrapi18n-perl hasn't actually changed, code-wise, so maybe a dh_perl bug?
<infinity> Both had uploads to "convert to dh()", so yeah, I'd guess some magic was lost.
<infinity> Will track that down post-beta.
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: murano-agent (eoan-proposed/universe) [1:4.0.0~b2~git2019073018.a026aa2-0ubuntu1 => 1:4.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted murano-agent [source] (eoan-proposed) [1:4.0.0~rc1-0ubuntu1]
<LocutusOfBorg> infinity, sure, I prefer to write here the reason for my work, when it happens :)
<LocutusOfBorg> I don't care about the freeze, I mean, it can wait whenever you want, just I syncd some CVEs to avoid hardened team extra work
 * LocutusOfBorg goes to sleep
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (eoan-proposed/universe) [1.16.0-3 => 1.16.1-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: murano (eoan-proposed/universe) [1:8.0.0~b2~git2019073018.7435a2e7-0ubuntu1 => 1:8.0.0~rc1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Beta] has been updated (20190926.1)
<mwhudson> infinity, jibel: i am so _extremely_ happy to find out that casper-helpers is apparently supported API :(
<infinity> mwhudson: I definitely don't consider it supported, but this was the easiest way out for now. :P
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Beta] has been updated (20190926.1)
<ahasenack> should the iso tracker be up-to-date already? I still see links to build/milestone 406
<infinity> ahasenack: 406 is the serial of the milestone itself.
<infinity> ahasenack: 20190926.1 should be the correct serial for the server stuff.
<ahasenack> ok, subiquity not there yet
<ahasenack> old server is
<ahasenack> ok
<infinity> Not quite.
<ahasenack> old installer, I mean
-queuebot:#ubuntu-release- Unapproved: accepted python-oslotest [source] (eoan-proposed) [1:3.8.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: octavia-dashboard (eoan-proposed/universe) [4.0.0~b2~git2019073114.3661294-0ubuntu3 => 4.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted octavia-dashboard [source] (eoan-proposed) [4.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Beta] has been updated (20190926.1)
<gaughen> plars_, would you be able to help with testing the beta on raspi3?
<infinity> (once it's done building)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.upgradecheck [source] (eoan-proposed) [0.3.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.utils [source] (eoan-proposed) [3.41.1-0ubuntu1]
<plars_> gaughen: definitely. Iâm already looking at the latest pending images a bit. It looks like thereâs a raspi2 image that is different from the raspi3 ones and it doesnât boot. I think they should all use a copy of the raspi3 image though right?
<infinity> plars_: pi2 is dead.
<infinity> I need to clean up stale images on the mirror, thanks for the reminder.
<plars_> long live pi2
<infinity> There's only pi3 on the tracker.
<infinity> (pi3 images are meant to boot on pi2, in theory)
<wxl> we rebuilt again?
<plars_> Iâm just looking at climate
<infinity> wxl: Yeahp.
<plars_> cdimage
<wxl> infinity: what did i miss?
<infinity> wxl: ubiquity, casper, and grub fixes that forced a world respin.
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Beta] has been updated (20190926.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been updated (20190926.2)
<wxl> yikes
<infinity> wxl: If you're picking up a flavour to re-test, let us know, as we're trying to pass around some flavour testing to fill in gaps.
<infinity> jibel: Desktop built ^
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] has been updated (20190926.1)
 * willcooke downloads
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.vmware [source] (eoan-proposed) [2.34.1-0ubuntu1]
<wxl> infinity: well i'll certainly have lubuntu taken care of, but are there other flavors that are particularly in need?
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] has been updated (20190926.1)
<xnox> vorlon:  server.iso ships a default preseed on full server isos on some architectures to do LVM by default. Which is not observable via mini.iso / netboot, or rather not always. I've seen that before, couldn't understand why it was done like that, and just rolled with it. As it was before my time.
<infinity> wxl: Every flavour needs a smoketest to make sure the build didn't break, but we (Canonical) will try to cover those who aren't awake right now. :P
<xnox> vorlon:  i too wish this was not true.
<wxl> infinity: okie dokie. well, you deserve some sleep, too, so if you get to needing help don't be afraid to ask.
<cwayne> hello party people
<wxl> woot woot
-queuebot:#ubuntu-release- Unapproved: accepted python-osprofiler [source] (eoan-proposed) [2.8.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (eoan-proposed) [3.7.1-0ubuntu1]
<vorlon> why does Ubuntu Studio have an openstack-provided python module seeded?
<vorlon> (python-tenacity)
<cwayne> gaughen: i was told there was a lively conversation here re: pi and I feel like I've been misled.
<gaughen> cwayne, well I got you here :-p
<mwhudson> cwayne: maybe you want #ubuntu-release-party
<infinity> plars_: arm*+raspi3 20190926.1 should be ready to test.
<ahasenack> which flavor has no volunteer yet?
<infinity> ahasenack: Well, Foundations picked a few.  If you want one, speak up.
<infinity> ahasenack: Take Studio?
<ahasenack> sure
<ahasenack> http://cdimage.ubuntu.com/ubuntustudio/dvd/20190926.1/eoan-dvd-amd64.iso.zsync is a 404
<ahasenack> infinity: ^
<ahasenack> as is http://cdimage.ubuntu.com/ubuntustudio/dvd/20190926.1/eoan-dvd-amd64.iso
<infinity> Err, wat.
<infinity> Maybe it's still rsyncing to frontends.
<infinity> Lemme look at cdimage.
<ahasenack> it's there now
<ahasenack> that's a big image, I'm bandwidth-challenged this week
<ahasenack> eta is over 1h
<ahasenack> I'll remove my name from the test while it downloads
<ahasenack> and switch back to the server run-once ones
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Beta] has been disabled
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Beta] has been updated (20190926.1)
<mwhudson> ahasenack: i can probably test it in an hour or so if that's easier
<mwhudson> (i have lots of bandwidth at the office)
<mwhudson> ahasenack: happy to trade xubuntu, that should be easier on your connection :)
<ahasenack> cdimage was never super fast from .br
<vorlon> answering my earlier question: because rapid-photo-downloader
<ahasenack> yep, xubuntu it is
 * mwhudson gets on a bus
-queuebot:#ubuntu-release- Unapproved: accepted python-tenacity [source] (eoan-proposed) [5.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-tooz [source] (eoan-proposed) [1.66.2-0ubuntu1]
<ahasenack> eoan-desktop-amd64-xubuntu.iso                         0%[                                                                                                                      ]   5,02M   273KB/s    eta 1h 41m
<ahasenack> :/
<infinity> VPN on or off?
<ahasenack> on, but I added a route to skip it for cdimage, let me check
<ahasenack> Checking destination cdimage.ubuntu.com (91.189.88.167 91.189.88.168 91.189.88.39)
<ahasenack> yeah, not using the vpn for any of the cdimage ips
<infinity> Could actually be faster with it on, connected to a US endpoint.
<infinity> So you use our link over the ocean instead of your ISP's routing.
<infinity> But your problems are likely earlier.
<infinity> I get about 15MB/s from cdimage over the VPN.
<ahasenack> I can try
<ahasenack> oh, it sped up a bit
<vorlon> jamespage: your stevedore upload reverts my fixes to debian/tests/control; I'm going to reject it since I can (and since it won't make it through -proposed in current state) and let you fix that up
-queuebot:#ubuntu-release- Unapproved: rejected stevedore [source] (eoan-proposed) [1:1.31.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-openstackdocstheme (eoan-proposed/universe) [1.31.1-0ubuntu1 => 1.31.1-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu7 => 0.154.1ubuntu8] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-saharaclient [source] (eoan-proposed) [2.3.0-0ubuntu1]
<ahasenack> it's faster indeed
<ahasenack> 1.4Mbytes/s
<ahasenack> sometimes 2
<ahasenack> my link here is 35mbps
-queuebot:#ubuntu-release- Unapproved: python-wsme (eoan-proposed/main) [0.9.3-2ubuntu1 => 0.9.3-3] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted python-swiftclient [source] (eoan-proposed) [1:3.8.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-ovsdbapp [source] (eoan-proposed) [0.17.0-0ubuntu1]
<Wimpress> SMoke tested Xubuntu.
<Wimpress> Testing Kylin now.
<infinity> Wimpress: I've got Kylin on the go too, but two tests won't hurt my feelings.
<Eickmeyer> vorlon: That python module has something to do with gstreamer, right? My guess is we have something that depends on it.
<vorlon> Eickmeyer: almost certainly nothing to do with gstreamer given that it's an openstack component
<Eickmeyer> Then I have no idea why it's in the seed. Probably from way before my time.
<vorlon> as much as it amuses me to think this might explain a few things about neutron
<vorlon> Eickmeyer: looks like it's a newer dependency of the package, added upstream in Debian
<Eickmeyer> Interesting.
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (eoan-proposed) [2:15.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (eoan-proposed) [2:15.0.0~rc1-0ubuntu1]
<mwhudson> oh wow ubuntu studio really is a big iso
<ahasenack> :)
<Eickmeyer> mwhudson: It's always been that way.
<mwhudson> pulling it down at 8 MB/s though
<Eickmeyer> mwhudson: I was able to drop it down by making some wallpapers non-default.
<ahasenack> Wimpress: did you see squashfs errors at the end of the xubuntu install? I'm wondering if I unplugged the cd/iso too soon
<willcooke> ahasenack, I saw that on the Ubuntu desktop too
<willcooke> and I /think/ it hosed my USB stick
-queuebot:#ubuntu-release- Builds: Netboot s390x [Eoan Beta] has been disabled
<ahasenack> willcooke: hm
<mwhudson> there is a bug about this
<mwhudson> which i am currently failing to find
<ahasenack> it eventually rebooted, and the installed system seems fine
<mwhudson> https://bugs.launchpad.net/bugs/1840122
<ubot5> Launchpad bug 1840122 in linux (Ubuntu Eoan) "System fails to reboot from live session or ubiquity-dm - squashfs_read_data failed to read block" [High,Confirmed]
<ahasenack> but it was stuck for about 30s in the "remove media and press ENTER" message, after I pressed enter
 * Eickmeyer is zsync-ing all the things."
<ahasenack> ok, xubuntu manual partitioning done
<ahasenack> I have to leave now, feed cats
<infinity> Okay, testing's looking promising, source ISOs are rebuilding to be current, I'm going to head out and clean up the actual release bits later.
<willcooke> l8r infinity
<infinity> gaughen: If you're bored, want to do the copy/paste/comment-out of Disco release notes to EoanErmine/ReleaseNotes?
<infinity> If not, I'll do it later.
<Wimpress> ahasenack: I did not.
<gaughen> sure I'll do that in a few minutes, will hand back to you
<gaughen> infinity, ^^
<Wimpress> willcooke: Want another pair of eye smoke testing Ubuntu?
<vorlon> NBS cleanup in the midst of the python2 deprecation is super annoying, y'all
<willcooke> Wimpress, yes please!  Its the various install methods that needs the shake down
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (eoan-proposed) [1:13.0.0~rc1-0ubuntu1]
<Wimpress> OK. Just finishing Kubuntu and I'll run through some.
 * Eickmeyer is syncing, will be doing his test on Studio soon
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (eoan-proposed) [2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu2]
<mwhudson> hmm the ubuntu studio installer was apparently happy to use the disk the installer was running from as an installation target...
<Eickmeyer> mwhudson: Interesting. And odd.
<mwhudson> Eickmeyer: is this calamares?
<Eickmeyer> Seems like a bit of a ubiquity bug.
<mwhudson> ah
<Eickmeyer> It's ubiquity.
<mwhudson> oh right yes of course it's ubiquity
<Eickmeyer> Calamares doesn't have the metapackage module yet.
<mwhudson> the kde-ish ubiquity?
<mwhudson> hmm this is slow, i wonder if i can get my spare nvme drive inside this ancient test box somehow :)
<Eickmeyer> Nah, Calamares is entirely different code, afaik.
<Wimpress> willcooke: Ummm.
<Wimpress> https://usercontent.irccloud-cdn.com/file/pffqhyVE/Screenshot%20at%202019-09-27%2000-02-52.png
<Eickmeyer> Wimpress: RIP.
<Wimpress> willcooke: CLicking OK does present the desktop.
<willcooke> well that sucks
<Wimpress> Testing in Qemu. Get that everytime.
<Wimpress> If I try Safe Graphics. Black screen. Blinking cursor.
-queuebot:#ubuntu-release- New binary: networking-ovn [amd64] (eoan-proposed/universe) [7.0.0~rc1-0ubuntu1] (no packageset)
<mwhudson> infinity, vorlon: any guesses at where the code that should prevent you from installing to the install media lives?
<mwhudson> infinity, vorlon: partman-base?
<cyphermox> possibly
<vorlon> no idea really
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (eoan-proposed) [2.22.0-0ubuntu1]
<mwhudson> i wonder if it's the change i made to casper about mounting the device vs mounting the partition
<mwhudson> Wimpress: i get that too if i select install vs try
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: piuparts (eoan-proposed/universe) [1.0.1 => 1.1.0~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted piuparts [source] (eoan-proposed) [1.1.0~build1]
<mwhudson> there's nothing obviously wrong in logs apart from a "Terminated" in /var/log/installer/dm
<mwhudson> and uh if i run DISPLAY=:0.0 ubiquity gtk_ui from vt2 it seems to start fine ?
 * mwhudson afk for a bit
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (eoan-proposed) [1:13.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: websockify (eoan-proposed/main) [0.8.0+dfsg1-10ubuntu2 => 0.8.0+dfsg1-16ubuntu1] (ubuntu-server)
#ubuntu-release 2019-09-27
-queuebot:#ubuntu-release- Unapproved: accepted murano [source] (eoan-proposed) [1:8.0.0~rc1-0ubuntu1]
<gaughen> infinity, release notes exist. need more cleanup - https://wiki.ubuntu.com/EoanErmine/ReleaseNotes
<gaughen> vorlon, do you want to have a look at the i386 bit in the release notes https://wiki.ubuntu.com/EoanErmine/ReleaseNotes
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackdocstheme [source] (eoan-proposed) [1.31.1-0ubuntu2]
<vorlon> gaughen: edited, how's that look?
<vorlon> afk now
-queuebot:#ubuntu-release- Unapproved: python-google-auth (eoan-proposed/universe) [1.5.1-1 => 1.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-google-auth [sync] (eoan-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-wsme [sync] (eoan-proposed) [0.9.3-3]
<ahasenack> back
<handsome_feng> infinity, Wimpress: Thanks for testing! :)
<Wimpress> My pleasure handsome_feng
<cyphermox> mwhudson: did you figure out what you wanted with partman-base?
<mwhudson> cyphermox: no
<mwhudson> i filed a bug though!
<cyphermox> I wonder if the fixed persistence fix is throwing off the checks in partman
<cyphermox> (because AFAIK the filtering does happen in partman-base)
<mwhudson> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1845571
<ubot5> Launchpad bug 1845571 in ubiquity (Ubuntu) "ubiquity offers installation media as an install target" [Undecided,New]
<mwhudson> yeah i wondered about that
<mwhudson> i also found https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/971425/comments/2
<ubot5> Launchpad bug 971425 in ubiquity (Ubuntu) "installation media shown in list of devices available for installation on a Mac" [Medium,New]
<mwhudson> but that doesn't make sense for an "erase disk and install" option still
<mwhudson> also there wouldn't be any space on the device by the time initramfs filled it with casper-rw
<cyphermox> that seems to match my read of the code too
<mwhudson> cyphermox: were is the code?
<mwhudson> oh init.d/parted it seems
<mwhudson> ****ing shell
<cyphermox> yeah, after line 155
<cyphermox> also, my eyes are closing, maybe it'd time I go sleep
<mwhudson> certainly a better plan that reading partman code
<mwhudson> *than
<cyphermox> bah, I have no issues with any d-i generally
<vorlon> Laney, juliank: non-armhf autopkgtest queues are stalled, and autopkgtest-cloud-worker doesn't let me ssh in.  working on rebooting it.
<rafaeldtinoco> i think i got why vda misbehaves for lvm on entire disks installation
<rafaeldtinoco> doing a last comment in case (testing with scsi disks to make sure what i found is right)
<vorlon> Laney, juliank: looks like we're stuck waiting for /lib/systemd/system/systemd-tmpfiles-setup.service to empty /tmp now :P
<vorlon> machine came up.  autopkgtest.target was somehow marked disaled.
<vorlon> b
<vorlon>    Loaded: loaded (/etc/systemd/system/autopkgtest.target; disabled; vendor preset: enabled)
<vorlon> Laney, juliank: ^^ that looks wrong to me
<vorlon> fwiw last thing in the log before the hang was a ksplice cronjob
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Beta] has been marked as ready
<infinity> plars_: .... what ever happened to my pi tests?
<jamespage> vorlon: OK - must not have been committed into the git repo - will merge and re-upload
<jibel> juliank, Hi, in python-apt 1.9.0 Package.section has been removed which causes bug 1845593. What replaces it?
<ubot5> bug 1845593 in ubiquity (Ubuntu) "Installation crashes with "Free software only" option enabled." [Critical,Confirmed] https://launchpad.net/bugs/1845593
<vorlon> triggers: ['gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu2', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1', 'gnocchi/4.3.4-0ubuntu1']
<vorlon> ... alrighty then
<vorlon> maybe I should look at fixing that script
<didrocks> at least, if someone doesn't see well which the triggers isâ¦ :) (But probably won't spot the little 4.3.4-0ubuntu2 in the middle :p)
<paride> infinity, well 20190926 was marked as working on ppc64 in the iso tracker because our test run passed
<paride> now it would be interesting to have it reproduce the crash
-queuebot:#ubuntu-release- Unapproved: piuparts (eoan-proposed/universe) [1.1.0~build1 => 1.1.0~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted piuparts [source] (eoan-proposed) [1.1.0~ubuntu1]
<juliank> ji
<juliank> jibel: Version.section
<juliank> It's been issuing DeprecationWarning for at least 3 years, but Python developers in their infinite wisdom chose to disable DeprecationWarning by default
-queuebot:#ubuntu-release- Unapproved: gnucash (eoan-proposed/universe) [1:3.7-1 => 1:3.7-1ubuntu1] (no packageset)
<juliank> I'm considering just using FutureWarning instead of DeprecationWarning in the future, because DeprecationWarning got fairly useless
-queuebot:#ubuntu-release- Unapproved: accepted gnucash [source] (eoan-proposed) [1:3.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-cryptography (eoan-proposed/main) [2.6.1-3ubuntu1 => 2.6.1-3.1] (core) (sync)
<jibel> juliank, yeah, thanks, that's what I did
-queuebot:#ubuntu-release- Unapproved: stevedore (eoan-proposed/main) [1:1.30.1-0ubuntu2 => 1:1.31.0-0ubuntu1] (ubuntu-desktop, ubuntu-server)
<Laney> vorlon: I saw something somewhere about there being a bad ksplice, but it also said the update had been blocked
<Laney> maybe we got in there before that happened
<Laney> is it good now?
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Beta] has been marked as ready
<paride> infinity, I'm not able to reproduce the ppc64 fail, basically it fails when using virtio, e.g. by running the installer like this:
<paride> kvm -m 1024 -boot d -cdrom eoan-server-ppc64el.iso -drive file=disk.img,if=virtio
<paride> it does *not* fail when dropping the if=virtio part
<paride> now, I was pretty sure that our tests did use virtio, and `virsh dumpxml` shows indeed that the storage is setup to use virtio
<infinity> I assume you get ibm-vscsi if you don't pass virtio?
<infinity> Or not. :P
<paride> but looking at the qemu command line there's if=none
<paride> so it gets lost at some point
<infinity> Well, I'm releasing it regardless, I assume it works on some systems, based on that.
<infinity> Something in the release notes might be nice.
 * paride tries a few things
<paride> 20190926.1 behaves identically (as expected I guess)
<paride> infinity, do you know if there's a bug filed already for this?
<infinity> paride: Not sure, you'd have to ask cascardo.
<paride> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1845572
<ubot5> Launchpad bug 1845572 in linux (Ubuntu) "udevadm trigger will fail when trying to add /sys/devices/vio/" [Critical,In progress]
<paride> I filed two test results, one passed and one failed, with the bug linked
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Beta] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Beta] has been marked as ready
<RikMills> I spy a release email. Thanks to all!
<Wimpress> Thanks infinity
<infinity> Sorry, it would have been a bit earlier, but I had to wait until midnight in Hawaii.  Obviously.
<infinity> (I was waiting for mirrors to sync)
-queuebot:#ubuntu-release- Unapproved: octavia (eoan-proposed/universe) [5.0.0~b2~git2019073019.f80f25e8-0ubuntu1 => 5.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Builds: 27 entries have been added, updated or disabled
<infinity> RikMills: Want to do the copypasta/editing to copy https://help.ubuntu.com/community/DiscoUpgrades/Kubuntu to https://help.ubuntu.com/community/EoanUpgrades/Kubuntu ?
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (eoan-proposed) [5.0.0~rc1-0ubuntu1]
<infinity> RikMills: Alternately, edit https://help.ubuntu.com/community/EoanUpgrades to remove the special snowflake Kubuntu section and stop linking to another page. :)
<paride> \o/
<RikMills> infinity: didn't know that was there. I will remove it until the 19.10 version is done
<infinity> RikMills: You didn't know, but you created the Disco one!
<infinity> (Don't worry, my memory's about as bad)
<RikMills> infinity: I didn't know it was linked to from that page is what I meant
<infinity> Oh, unless you meant you didn't know EoanUpgrades was... Right.
<infinity> To be fair, EoanUpgrades only came into being an hour ago or so.
 * RikMills nods
<infinity> So you're not behind. :P
<paride> infinity, anyway I take it back. I don't have a reproducer. With if=virtio the ISO boot gets stuck for a while, but then starts and seems to work (I'm going through it now).
<infinity> paride: Weird bug is weird.
<paride> It is. I'll gather some more data points and comment back to the bug on LP
<infinity> Ta.
-queuebot:#ubuntu-release- Unapproved: libtext-charwidth-perl (eoan-proposed/main) [0.04-8 => 0.04-8ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: libtext-wrapi18n-perl (eoan-proposed/main) [0.06-8 => 0.06-8ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (eoan-proposed) [5.3.0.13.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- Unapproved: linux-signed (eoan-proposed/main) [5.3.0-12.13 => 5.3.0-13.14] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libtext-charwidth-perl [source] (eoan-proposed) [0.04-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- Unapproved: accepted libtext-wrapi18n-perl [source] (eoan-proposed) [0.06-8ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (eoan-proposed) [2.26.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (eoan-proposed) [2.4.99-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [source] (eoan-proposed) [1.4.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.0~rc4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (eoan-proposed) [1:4.0+dfsg-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected gst-plugins-ugly1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [source] (eoan-proposed) [1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (eoan-proposed) [1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (eoan-proposed) [1.16.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted bolt [sync] (eoan-proposed) [0.8-4]
-queuebot:#ubuntu-release- Unapproved: accepted sdl-image1.2 [sync] (eoan-proposed) [1.2.12-12]
-queuebot:#ubuntu-release- Unapproved: accepted libgdata [sync] (eoan-proposed) [0.17.11-3]
-queuebot:#ubuntu-release- Unapproved: accepted tiff [sync] (eoan-proposed) [4.0.10+git190903-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [sync] (eoan-proposed) [2.6.1-3.1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-power-manager [source] (eoan-proposed) [1.22.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted websockify [source] (eoan-proposed) [0.8.0+dfsg1-16ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted stevedore [source] (eoan-proposed) [1:1.31.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-13.14]
-queuebot:#ubuntu-release- Unapproved: gnome-mahjongg (eoan-proposed/main) [1:3.33.90-1 => 1:3.34.0-1] (ubuntu-desktop) (sync)
<LocutusOfBorg> alt-ergo armhf permanent hint has been dropped by mistake, can it be reintroduced?
-queuebot:#ubuntu-release- Unapproved: manila (eoan-proposed/universe) [1:9.0.0~b2~git2019073018.cc830350-0ubuntu1 => 1:9.0.0~rc1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (eoan-proposed/main) [5.10ubuntu1 => 5.10ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (eoan-proposed/universe) [11.0.0~b2~git2019073113.30196d1-0ubuntu3 => 11.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (eoan-proposed) [11.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: designate (eoan-proposed/main) [1:9.0.0~b2~git2019073016.076f9fce-0ubuntu1 => 1:9.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (disco-proposed/main) [5.10ubuntu1 => 5.10ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (bionic-proposed/main) [5.3.1 => 5.3.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: autopkgtest (xenial-proposed/main) [4.3~ubuntu16.04.1 => 3.20.4ubuntu1.1] (core)
<paride> infinity, finally I think the best answer to:
<paride> <infinity> Basically, I want to know how we got here, and have a plan to get better coverage in the future.
<paride> is: the full ppc64 ISO works fine, that's why it was marked as working in the tracker. What's broken is the mini image, which we don't routinely test
<paride> powersj, ^^
<cascardo> I am trying to understand how one fails and the other doesn't
<cascardo> it has to do with udevadm trigger failing and making init exit
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (eoan-proposed/universe) [5.0.0.1017.14 => 5.3.0.1005.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (eoan-proposed/universe) [5.0.0-1017.17 => 5.3.0-1005.6] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: sahara (eoan-proposed/universe) [1:11.0.0~b2~git2019073018.2287d92f-0ubuntu1 => 1:11.0.0~rc1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: keystone (eoan-proposed/main) [2:16.0.0~b3~git2019091810.5e35efd55-0ubuntu1 => 2:16.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
<bdmurray> tjaalton, vorlon: Could one of you review my update-notifier upload in the Trusty unapproved queue?
-queuebot:#ubuntu-release- Unapproved: horizon (eoan-proposed/main) [3:16.0.0~b2~git2019080510.0a10dde2e-0ubuntu4 => 3:16.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.0.0~b3~git2019092509.cea6e823c-0ubuntu2 => 2:15.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
<vorlon> Laney: yeah, autopkgtest runner seemed to work fine after that, obviously there was no new ksplice to apply at that point.  Do you know why the autopkgtest.target is disabled, though?
<Laney> nope
<vorlon> k
<Laney> it's an interesting question
<Laney> because that's how the maintenance script restarts the stuff isn't it?
 * Laney stares at juju
<Laney> the environment is down there; did you manually hack your way in?
<Laney> huh
<Laney> rabbitmq is down too?
<Laney> why has nobody complained /o\
<vorlon> Laney: "manually hack my way in" - no, I did a nova reboot followed by a juju ssh?
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (eoan-proposed/universe) [1:8.0.0~b2~git2019080208.c4272817-0ubuntu3 => 1:8.0.0~rc1-0ubuntu1] (openstack)
<Laney> well now the environment is down...
<vorlon> ?
<Laney> so that bad ksplice update was still rolling out?
<Laney> I've just recovered it
<vorlon> ok
<Laney> it had killed the bootstrap node
<Laney> but that's not what I understood should have happened
<Laney> the rabbitmq machine was also dead
<vorlon> when you say the environment was down, do you mean the service wasn't working, or the juju environment was in a broken state?
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (eoan-proposed/main) [1:15.0.0~b2~git2019073114.243a7ef57-0ubuntu1 => 1:15.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
<Laney> well it wasn't working because rmq was offline, you couldn't use juju to interact with it because bootstrap was offline
<Laney> autopkgtest.target is active now after I ran the cloud-worker-maintenance script
<vorlon> ok
<vorlon> when I had worked on it last night, rabbitmq was definitely up
<vorlon> and the autopkgtest.target was active once I manually started it, but came up disabled after a reboot
<Laney> nod
<Laney> there's some panics in kern.log.1
<Laney> maybe the ksplice problem in question takes some time to actually kill the machine
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (eoan-proposed/universe) [13.0.0~b2~git2019073113.e53d447-0ubuntu3 => 13.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (eoan-proposed) [13.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (trusty-proposed) [0.154.1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: mysql-workbench (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu1 => 8.0.17+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mysql-workbench [source] (eoan-proposed) [8.0.17+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ipykernel (eoan-proposed/universe) [4.9.0-1 => 4.9.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ipykernel [source] (eoan-proposed) [4.9.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: mysql-workbench [s390x] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nbconvert (eoan-proposed/universe) [5.4-2 => 5.4-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-workbench [ppc64el] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nbconvert [source] (eoan-proposed) [5.4-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [0.0.20190905-1 => 0.0.20190913-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-workbench [i386] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (eoan-proposed) [0.0.20190913-1ubuntu1]
-queuebot:#ubuntu-release- New binary: mysql-workbench [amd64] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.7]
<Eickmeyer> Would it be too late to do a sync for obs-studio? Sid has a newer version than we do, which is very sought-after by the community.
<Eickmeyer> Ubuntu Studio would be the only flavor affected.
<vorlon> Eickmeyer: it's probably justifiable, but that's clearly an exception to the freeze, so there should be due diligence
<vorlon> the release team will generally defer to flavor leads for the actual decision making around such exceptions
<Eickmeyer> vorlon: That's why I asked. Thanks!
-queuebot:#ubuntu-release- Unapproved: chemfp (eoan-proposed/universe) [1.1p1-2.1 => 1.1p1-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: highlight.js (eoan-proposed/universe) [9.12.0+dfsg1-4 => 9.12.0+dfsg1-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted chemfp [source] (eoan-proposed) [1.1p1-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted highlight.js [source] (eoan-proposed) [9.12.0+dfsg1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cinfony (eoan-proposed/universe) [1.2-4 => 1.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cinfony [source] (eoan-proposed) [1.2-4ubuntu1]
<vorlon> did I see someone say somewhere that python-django 2.2 no longer had blocking revdeps for eoan?
-queuebot:#ubuntu-release- New binary: mysql-workbench [armhf] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
<vorlon> trying to work out what to do about https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/1843355/comments/1
<ubot5> Launchpad bug 1843355 in python-django (Ubuntu) "Remove version "2:2.2.4-1" from eoan proposed" [Undecided,Fix released]
-queuebot:#ubuntu-release- New binary: mysql-workbench [arm64] (eoan-proposed/universe) [8.0.17+dfsg-1ubuntu2] (no packageset)
<Eickmeyer> vorlon: Done with the request, bug 1845692
<ubot5> bug 1845692 in obs-studio (Ubuntu) "FFe: Sync obs-studio 24.0.1+dfsg1-1 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1845692
-queuebot:#ubuntu-release- Unapproved: kbackup (eoan-proposed/universe) [19.08.1-0ubuntu1 => 19.08.1-1] (kubuntu) (sync)
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Post-beta Chill | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, cheque or gin | melius malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: heat-dashboard (eoan-proposed/universe) [1.5.1~b2~git2019082610.050d63b-0ubuntu3 => 2.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted heat-dashboard [source] (eoan-proposed) [2.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: magnum (eoan-proposed/universe) [9.0.0~b2~git2019073018.2d9e0587-0ubuntu1 => 9.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (eoan-proposed/main) [20101020ubuntu589 => 20101020ubuntu590] (core)
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (eoan-proposed/universe) [9.0.0~b2~git2019073116.9fecedf-0ubuntu3 => 9.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (eoan-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: senlin (eoan-proposed/universe) [8.0.0~b2~git2019073018.c993775b-0ubuntu1 => 8.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: masakari-monitors (eoan-proposed/universe) [8.0.0~b2~git2019073018.ae3ab24-0ubuntu1 => 8.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (eoan-proposed) [8.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (eoan-proposed) [8.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gevent-socketio (eoan-proposed/universe) [0.3.6-4 => 0.3.6-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: jupyter-sphinx-theme (eoan-proposed/universe) [0.0.6+ds1-7 => 0.0.6+ds1-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gevent-socketio [source] (eoan-proposed) [0.3.6-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted jupyter-sphinx-theme [sync] (eoan-proposed) [0.0.6+ds1-8]
-queuebot:#ubuntu-release- Unapproved: lyx (eoan-proposed/universe) [2.3.3-1 => 2.3.3-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: owncloud-client (eoan-proposed/universe) [2.5.1.10973+dfsg-1 => 2.5.1.10973+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [source] (eoan-proposed) [2.5.1.10973+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lyx [sync] (eoan-proposed) [2.3.3-2]
-queuebot:#ubuntu-release- Unapproved: rejected cinder [source] (disco-proposed) [2:14.0.1-0ubuntu2]
<vorlon> coreycb: you're aware that cinder in the disco unapproved queue is blocked on there being a previous unfinished SRU in -proposed?
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (eoan-proposed) [1:11.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (eoan-proposed) [1:9.0.0~rc1-0ubuntu1]
<vorlon> xnox, rbalint: LP: #1771858 is listed as fixed in systemd 237-3ubuntu10.24 in bionic, which is present in the changelog of the latest version.  So are we confident this is really fixed this time and hasn't been clobbered by any security updates?  because the snapd change is ready to go
<ubot5> Launchpad bug 1771858 in snapd (Ubuntu) "/snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH" [Critical,Confirmed] https://launchpad.net/bugs/1771858
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.41+19.04]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (eoan-proposed) [5.10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (eoan-proposed) [5.3.0-1005.6]
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (disco-proposed) [1.2.5-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (eoan-proposed) [5.3.0.1005.1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (eoan-proposed) [2:16.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (eoan-proposed) [3:16.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-networkx (eoan-proposed/main) [2.2-1ubuntu2 => 2.2-1ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (eoan-proposed) [2:15.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (disco-proposed) [1.8.4]
-queuebot:#ubuntu-release- Unapproved: accepted autopkgtest [source] (disco-proposed) [5.10ubuntu1.1]
<vorlon> ddstreet: are you sruing autopkgtest only because it's blocking a dpkg sru?  the parsimonious solution there is to confirm the autopkgtest failure is not a regression vs release+updates, and hint it away
<vorlon> ddstreet: which you'll need to have done anyway given that we won't release an autopkgtest-only SRU
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (eoan-proposed) [1:8.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (eoan-proposed) [1:15.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (eoan-proposed) [2.2-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (eoan-proposed) [1:9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (eoan-proposed) [20101020ubuntu590]
#ubuntu-release 2019-09-28
<vorlon> xnox: amd64-microcode has been awaiting verification in disco for quite a while, are you on that?
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (bionic-proposed) [3.20181128.1~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted kbackup [sync] (eoan-proposed) [19.08.1-1]
<vorlon> LocutusOfBorg: what warrants a new upstream release of golang-1.12 during final freeze?
<vorlon> mwhudson: ^^ ?
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.30]
-queuebot:#ubuntu-release- Unapproved: python-pymzml (eoan-proposed/universe) [0.7.6-dfsg-5ubuntu1 => 0.7.6-dfsg-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-pymzml [source] (eoan-proposed) [0.7.6-dfsg-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: haskell-servant (eoan-proposed/universe) [0.15-2ubuntu1 => 0.15-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-shake (eoan-proposed/universe) [0.16.4+dfsg-3ubuntu1 => 0.16.4+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-servant [sync] (eoan-proposed) [0.15-3]
-queuebot:#ubuntu-release- Unapproved: haskell-semigroupoids (eoan-proposed/universe) [5.3.2-1ubuntu1 => 5.3.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-shake [sync] (eoan-proposed) [0.16.4+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: haskell-http-api-data (eoan-proposed/universe) [0.4-2ubuntu1 => 0.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-http-types (eoan-proposed/universe) [0.12.3-1ubuntu1 => 0.12.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-http-api-data [sync] (eoan-proposed) [0.4-3]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-semigroupoids [sync] (eoan-proposed) [5.3.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-http-types [sync] (eoan-proposed) [0.12.3-2]
-queuebot:#ubuntu-release- Unapproved: haskell-email-validate (eoan-proposed/universe) [2.3.2.11-1ubuntu1 => 2.3.2.11-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-cborg (eoan-proposed/universe) [0.2.1.0-3ubuntu1 => 0.2.1.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-distributive (eoan-proposed/universe) [0.6-2ubuntu1 => 0.6-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-cborg [sync] (eoan-proposed) [0.2.1.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-email-validate [sync] (eoan-proposed) [2.3.2.11-2]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-distributive [sync] (eoan-proposed) [0.6-3]
-queuebot:#ubuntu-release- Unapproved: libtext-charwidth-perl (eoan-proposed/main) [0.04-8ubuntu1 => 0.04-9] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libtext-wrapi18n-perl (eoan-proposed/main) [0.06-8ubuntu1 => 0.06-9] (core) (sync)
<LocutusOfBorg> vorlon, look at the diff, it is *only* including a CVE fix http://launchpadlibrarian.net/444340800/golang-1.12_1.12.9-2ubuntu1_1.12.10-1ubuntu1.diff.gz
<LocutusOfBorg> and some VCS fields modifications, meh :) I already did the same for golang-1.13, they have been pushed as hotfixes for CVE-2019-16276
<vorlon> LocutusOfBorg: ah ok
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.12 [source] (eoan-proposed) [1.12.10-1ubuntu1]
<LocutusOfBorg> I had a patch to make golang-1.13 in sync with Debian accepted, they didn't even include it in the cve hotfix release.. :(
<LocutusOfBorg> thanks for accepting it
<LocutusOfBorg> I also did a pidgin "merge", that fixed a Python3 incompatibility in code (we were python3 already since some years)
-queuebot:#ubuntu-release- Unapproved: python-pymzml (eoan-proposed/universe) [0.7.6-dfsg-5ubuntu2 => 0.7.6-dfsg-5ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-pymzml [source] (eoan-proposed) [0.7.6-dfsg-5ubuntu3]
<LocutusOfBorg> vorlon, I looked at python-cryptography, and all the tests failing (barbican on armhf), openstack-trove, python-adal, python-azure are regressed in release
<LocutusOfBorg> can them be hinted? I retried tests on amd64
<LocutusOfBorg> the python sadness will find its way post eoan probably...
-queuebot:#ubuntu-release- Unapproved: gnome-taquin (eoan-proposed/universe) [3.32.0-1 => 3.34.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-taquin [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-guide (eoan-proposed/universe) [19.10.0-0ubuntu1 => 19.10.1-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: spice-vdagent (eoan-proposed/main) [0.19.0-1 => 0.19.0-2] (desktop-core, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: cups-filters (eoan-proposed/main) [1.25.6-0ubuntu1 => 1.25.6-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: exim4 (eoan-proposed/main) [4.92.1-1ubuntu2 => 4.92.1-1ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-xapp (eoan-proposed/universe) [1.2.0-2 => 1.6.0-1] (ubuntu-budgie, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: xapp (eoan-proposed/universe) [1.2.2-1 => 1.4.9-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: cinnamon-desktop (eoan-proposed/universe) [3.8.1-2 => 4.0.1-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: cinnamon-translations (eoan-proposed/universe) [3.8.2-1 => 4.0.2-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: nemo (eoan-proposed/universe) [3.8.5-1build1 => 4.0.6-1] (ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: cinnamon-control-center (eoan-proposed/universe) [3.8.1-1 => 4.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-control-center [sync] (eoan-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- Unapproved: cinnamon-settings-daemon (eoan-proposed/universe) [3.8.4-2 => 4.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: cinnamon-session (eoan-proposed/universe) [3.8.2-1 => 4.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-session [sync] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: cjs (eoan-proposed/universe) [3.8.0-5 => 4.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-settings-daemon [sync] (eoan-proposed) [4.0.3-1]
-queuebot:#ubuntu-release- Unapproved: cinnamon-screensaver (eoan-proposed/universe) [3.8.2-1 => 4.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-screensaver [sync] (eoan-proposed) [4.0.3-1]
-queuebot:#ubuntu-release- Unapproved: muffin (eoan-proposed/universe) [3.8.2-1 => 4.0.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cjs [sync] (eoan-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- Unapproved: cinnamon-menus (eoan-proposed/universe) [3.8.2-1 => 4.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-menus [sync] (eoan-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted muffin [sync] (eoan-proposed) [4.0.7-1]
-queuebot:#ubuntu-release- Unapproved: developers-reference (eoan-proposed/universe) [11.0.2 => 11.0.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted developers-reference [sync] (eoan-proposed) [11.0.3]
-queuebot:#ubuntu-release- Unapproved: sugar-toolkit-gtk3 (eoan-proposed/universe) [0.112-3 => 0.116-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar-toolkit-gtk3 [sync] (eoan-proposed) [0.116-4]
-queuebot:#ubuntu-release- Unapproved: mumble (eoan-proposed/universe) [1.3.0~git20190125.440b173+dfsg-2 => 1.3.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mumble [sync] (eoan-proposed) [1.3.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: libreoffice-dictionaries (eoan-proposed/main) [1:6.3.0-1 => 1:6.3.1-1] (personal-gunnarhj, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: josm (eoan-proposed/universe) [0.0.svn15238+dfsg-1 => 0.0.svn15322+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted josm [sync] (eoan-proposed) [0.0.svn15322+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: granite (eoan-proposed/universe) [5.2.3-1 => 5.2.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted granite [sync] (eoan-proposed) [5.2.5-1]
-queuebot:#ubuntu-release- Unapproved: gnucash-docs (eoan-proposed/universe) [3.6-1 => 3.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnucash-docs [sync] (eoan-proposed) [3.7-2]
-queuebot:#ubuntu-release- Unapproved: lightsoff (eoan-proposed/universe) [1:3.32.0-1 => 1:3.34.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: polari (eoan-proposed/universe) [3.32.0-1 => 3.34.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-weather (eoan-proposed/universe) [3.33.90-1 => 3.34.0-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: gtkmm3.0 (eoan-proposed/main) [3.24.0-2 => 3.24.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted polari [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: tali (eoan-proposed/universe) [1:3.32.0-1 => 1:3.32.1-1] (desktop-extra) (sync)
<santa_> good afternoon
<santa_> tjaalton: as we discussed, I tried to change the xorg-server source generation. I have build modified packages here https://launchpad.net/~panfaust/+archive/ubuntu/xorg-server
<santa_> as you can see I tested that tigervnc still builds (tigervnc seems to be the only package using xorg-server-source)
<santa_> the modification fixes the FTBFS with debhelper as a side effect
-queuebot:#ubuntu-release- Unapproved: git-buildpackage (eoan-proposed/universe) [0.9.14 => 0.9.15] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted git-buildpackage [sync] (eoan-proposed) [0.9.15]
-queuebot:#ubuntu-release- Unapproved: gnome-tetravex (eoan-proposed/universe) [1:3.32.0-2 => 1:3.34.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: mate-menu (eoan-proposed/universe) [19.10.1-1 => 19.10.2-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: haskell-jwt (eoan-proposed/universe) [0.7.2-9ubuntu1 => 0.7.2-10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-lens-aeson (eoan-proposed/universe) [1.0.2-6ubuntu1 => 1.0.2-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-servant-server (eoan-proposed/universe) [0.15-1ubuntu2 => 0.15-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-jwt [sync] (eoan-proposed) [0.7.2-10]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-servant-server [sync] (eoan-proposed) [0.15-2]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-lens-aeson [sync] (eoan-proposed) [1.0.2-7]
-queuebot:#ubuntu-release- Unapproved: haskell-xml-conduit (eoan-proposed/universe) [1.8.0.1-1ubuntu1 => 1.8.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected haskell-xml-conduit [sync] (eoan-proposed) [1.8.0.1-2]
-queuebot:#ubuntu-release- Unapproved: rust-num-traits (eoan-proposed/universe) [0.2.8-1ubuntu2 => 0.2.8-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rust-num-traits [source] (eoan-proposed) [0.2.8-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gtranslator (eoan-proposed/universe) [3.32.0-1 => 3.34.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gtranslator [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- New sync: lollypop (eoan-proposed/primary) [1.1.4.16-4]
-queuebot:#ubuntu-release- Unapproved: graphicsmagick (eoan-proposed/universe) [1.4+really1.3.33-1 => 1.4+really1.3.33+hg16115-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: meld (eoan-proposed/universe) [3.20.0-2 => 3.20.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted meld [sync] (eoan-proposed) [3.20.1-1]
#ubuntu-release 2019-09-29
<vorlon> IOError: [Errno 28] No space left on device.. not exactly what I expect to see in a debug of cron.NBS.
-queuebot:#ubuntu-release- Unapproved: binutils (eoan-proposed/main) [2.32.90.20190917-0ubuntu1 => 2.32.90.20190929-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (eoan-proposed) [2.32.90.20190929-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: binutils (eoan-proposed/main) [2.32.90.20190917-0ubuntu1 => 2.32.90.20190929-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (eoan-proposed) [2.32.90.20190929-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: git-annex (eoan-proposed/universe) [7.20190129-3build1 => 7.20190912-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: haskell-haskell-gi (eoan-proposed/universe) [0.21.5-1ubuntu1 => 0.21.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted git-annex [sync] (eoan-proposed) [7.20190912-1]
-queuebot:#ubuntu-release- Unapproved: accepted haskell-haskell-gi [sync] (eoan-proposed) [0.21.5-2]
<RikMills> looks like new systemd broke ubiquity
<RikMills> cyphermox: ^
<RikMills> LP: #1845730
<ubot5> Error: Launchpad bug 1845730 could not be found
<RikMills> grrr. private
<RikMills> * Drop /sbin/udevadm compat symlink (Closes: #852580)
<RikMills> did it I guess
-queuebot:#ubuntu-release- Unapproved: atomix (eoan-proposed/universe) [3.32.1-1 => 3.34.0-1] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted atomix [sync] (eoan-proposed) [3.34.0-1]
-queuebot:#ubuntu-release- Unapproved: libsigc++-2.0 (eoan-proposed/main) [2.10.1-2 => 2.10.2-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: buildstream (eoan-proposed/universe) [1.2.4-1ubuntu1 => 1.4.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted buildstream [sync] (eoan-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- Unapproved: gnote (eoan-proposed/universe) [3.32.1-1 => 3.34.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gedit-plugins (eoan-proposed/universe) [3.32.0-1ubuntu1 => 3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gedit-plugins [source] (eoan-proposed) [3.34.0-2~build1]
-queuebot:#ubuntu-release- New binary: gedit-plugins [amd64] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [s390x] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [ppc64el] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [i386] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [arm64] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [armhf] (eoan-proposed/universe) [3.34.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kcov (eoan-proposed/universe) [36+dfsg-1build3 => 36+dfsg-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: naev (eoan-proposed/universe) [0.7.0-2build8 => 0.7.0-2build9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: looking-glass (eoan-proposed/universe) [0+b1-1build5 => 0+b1-1build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oprofile (eoan-proposed/universe) [1.3.0-0ubuntu7 => 1.3.0-0ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted oprofile [source] (eoan-proposed) [1.3.0-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted kcov [source] (eoan-proposed) [36+dfsg-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted naev [source] (eoan-proposed) [0.7.0-2build9]
-queuebot:#ubuntu-release- Unapproved: accepted looking-glass [source] (eoan-proposed) [0+b1-1build6]
-queuebot:#ubuntu-release- Unapproved: kubuntu-settings (eoan-proposed/universe) [1:19.10ubuntu8 => 1:19.10ubuntu9] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (eoan-proposed/universe) [0.194 => 0.195] (ubuntustudio)
<Eickmeyer> ^ We forgot something important... *facepalm*
<Eickmeyer> And by we I mean "I". *double-facepalm*
-queuebot:#ubuntu-release- Unapproved: python-jsondiff (eoan-proposed/universe) [1.1.1-2 => 1.1.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-jsondiff [sync] (eoan-proposed) [1.1.1-3]
-queuebot:#ubuntu-release- Unapproved: python-json-patch (eoan-proposed/main) [1.23-2 => 1.23-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: bst-external (eoan-proposed/universe) [0.9.0-1 => 0.18.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bst-external [sync] (eoan-proposed) [0.18.0-1]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-menu (eoan-proposed/universe) [0.33 => 0.34] (ubuntustudio)
<Eickmeyer> ^Another bug fix.
-queuebot:#ubuntu-release- Unapproved: latte-dock (eoan-proposed/universe) [0.9.2-1 => 0.9.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: wlroots (eoan-proposed/universe) [0.6.0-1 => 0.7.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wlroots [sync] (eoan-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- Unapproved: sway (eoan-proposed/universe) [1.1.1-1 => 1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sway [sync] (eoan-proposed) [1.2-1]
-queuebot:#ubuntu-release- Unapproved: containerd (eoan-proposed/universe) [1.2.9-0ubuntu1 => 1.2.10-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (eoan-proposed) [1.2.10-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-policy (eoan-proposed/universe) [4.4.0.1 => 4.4.1.0] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-policy [sync] (eoan-proposed) [4.4.1.0]
