#ubuntu-release 2011-02-28
<ev> I don't suppose I could pester someone into reviewing the MIR for bug 726453 today?  It's needed for the package preservation part of reusing or upgrading an existing copy of Ubuntu in ubiquity.
<ubot4> Launchpad bug 726453 in dpkg-repack (Ubuntu) "[MIR] dpkg-repack (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/726453
<ev> Apologies for the short notice; I had mistakenly presumed it was already in main.
<ev> (dpkg-repack)
<Riddell> ev: mterry is the guy to pester when he's online
<ev> Riddell: cool, thanks; I'll stalk him.
<Riddell> today's Kubuntu CD loads fine on a virtual machine but from a real CD gives me an isolinux error
<cjwatson> it's oversized, isn't it?
<Riddell> no
<cjwatson> I thought I saw cron mail telling me it was
<Riddell> powerpc is but I'm testing amd64
<cjwatson> oh, just powerpc
<cjwatson> don't know, syslinux/gfxboot/etc. haven't changed to my knowledge
<Riddell> I'll try different CDs and a USB stick
<jamespage> Please could a member of the release team review FFE bug 661230 for me? This is for a merge that just missed Feature Freeze last week.
<ubot4> Launchpad bug 661230 in groovy (Ubuntu) "[FFe] Merge groovy 1.7.4-1 (main) from Debian testing (main) (affects: 2) (dups: 1) (heat: 22)" [Medium,New] https://launchpad.net/bugs/661230
<jamespage> thanks!
<hggdh> cjwatson: bug 726131 has the logs, and jibel reports he also got hit today
<ubot4> Launchpad bug 726131 in debian-installer (Ubuntu Natty) (and 1 other project) "alternate ISO: installation freezes when starting partman (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/726131
<Riddell> bug 726581  install asks for change of CD
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/726581
<charlie-tca> Should mention that I only see 726131 using hardware, it does not affect VirtualBox for me
<cjwatson> hggdh: unfortunately I haven't been able to reproduce this despite my best efforts, and the log is unfortunately a bit sparse - could you do a bit more debugging for me?
<cjwatson> I'll put instructions in the bug
<hggdh> cjwatson: yes, of course
<hggdh> cjwatson: jibel  brought up https://launchpad.net/bugs/722198 as a possible side effect
<ubot4> Launchpad bug 722198 in partman-auto (Ubuntu Natty) (and 2 other projects) "installation hangs on 15reuse w/ blank disk (affects: 3) (dups: 1) (heat: 28)" [Critical,Fix released]
<charlie-tca> cjwatson: I can not reproduce it in Virtualbox, but it reproduces on hardware every time.
<cjwatson> hggdh: posted
<cjwatson> hggdh: ev has been working on partman-auto lately, there's already been at least one change since your log
<hggdh> cjwatson: done
<cjwatson> hggdh: which processes did you kill?
<cjwatson> unfortunately, the log is truncated before the point I need
<hggdh> cjwatson: anything with 'partman' in the command line; I left parted-server
 * cjwatson hates d-i's syslog buffering; one of these days I will find out what's causing it
<cjwatson> did the installer display return to the main menu?
<hggdh> cjwatson: it is easy to redo it
<hggdh> (for me, of course ;-)
<cjwatson> you basically need to kill stuff until Alt-F1 goes back to the main menu
<cjwatson> it's annoying
<hggdh> cjwatson: after killing the partman processes, yes -- it noted a failure, and returned me to "Partition disks"
<cjwatson> hmm
<cjwatson> I wonder why the trace stops in 25replace then
<hggdh> I will do it again, it will take just 2 minutes
<cjwatson> huh, this time the partman log also stops in 25replace
<cjwatson> the previous log showed it stopping in 50biggest_free
<cjwatson> ah, you upgraded since then
<hggdh> yes, the original syslog was from yesterday's ISO
<hggdh> and I was running with DEBCONF_DEBUG=DEVELOPER
<cjwatson> that needs to be DEBCONF_DEBUG=developer in order to have any effect
<hggdh> dammit
<hggdh> want it, anyway?
<cjwatson> sure
<hggdh> in the oven
<cjwatson> I have a suspicion, though
<hggdh> yes?
<cjwatson> Feb 28 15:53:57 main-menu[382]: (process:10185): + grep -s DISTRIB_ID /tmp/tmp.9pMRFq/etc/lsb-release
<cjwatson> Feb 28 15:53:57 main-menu[382]: (process:10185):
<cjwatson> Feb 28 15:53:57 main-menu[382]: (process:10185): + release=
<cjwatson> that's 'set -e' firing
<cjwatson> Feb 28 15:53:57 main-menu[382]: (process:10185): +
<cjwatson> Feb 28 15:53:57 main-menu[382]: (process:10185): cleanup
<cjwatson> and the effect in that particular place will be to send the partman fifo comms out of sync
 * cjwatson goes to insert some more || true calls
<hggdh> oh -- when I tried yesterday with a virgin disc (went out and bought a new HD -- first run I had no issues (except wrong option selected)
<cjwatson> right, it depends on the state of the disk
<hggdh> OK. I will start now killing processes until F1 shows the error message about a failed stop
<hggdh> step
<cjwatson> I think I've fixed it, so no need
<cjwatson> if you want to double-check, you could apply http://bazaar.launchpad.net/~ubuntu-core-dev/partman-auto/ubuntu/revision/595 before the partitioner starts up (the filenames are a bit different, use tab-completion under /lib/partman/)
<hggdh> cjwatson: will try it -- right now my laptop is a brick, and I really, really, desperately, need it
<charlie-tca> heh, there is a good side to the old desktop, at least it works better as a doorstop than the laptop :-)
<hggdh> heh
<hggdh> cjwatson: OK, seems to work
<cjwatson> excellent
 * cjwatson closes the bug
 * charlie-tca thanks cjwatson for fixing that miserable bug
<cjwatson> skaet_: can you ack/nack the "branches (1)-(3)" part of bug 723846?
<ubot4> Launchpad bug 723846 in upstart (Ubuntu) "Feature Freeze Exception request for Upstart in Natty (affects: 1) (heat: 885)" [Undecided,New] https://launchpad.net/bugs/723846
<cjwatson> now to see if I can reproduce those mountall problems with separate /usr and /var ...
 * skaet_ looking
<hggdh> cjwatson: I am giving up on multiple filesystems, so I will not be able to test it anymore. Sorry.
<skaet_> cjwatson, am a little concerned about comment Do *NOT* use this PPA on systems you care about as it has not been fully tested yet.
<skaet_> how risky is it?
<cjwatson> skaet_: well, since then it has been tested by a few people on the team
<cjwatson> I think that's standard "you probably don't want to be the first person to try an upstart upgrade"
<cjwatson> James Page and Michael Vogt haven't reported any issues AFAIK so far
<skaet_> Do we have a fallback if the wider exposure suddenly shows breakage?
<skaet_> cjwatson,  what features of branch 2 will be on by default, and which ones not?
<cjwatson> branch 1 only has any effect if the upstart-socket-bridge process is started, so we could just not start that (and not use it in any jobs, which we won't be using at the moment)
<cjwatson> from branch 2, chroot session handling is on by default but user session handling is off by default
<cjwatson> chroot session handling is only invoked if you talk to upstart from inside a chroot
<cjwatson> if chroot session handling breaks, I think a reasonable fallback would be to change session_from_dbus temporarily to always return NULL (i.e. the root session)
<cjwatson> that would effectively disable that feature
<cjwatson> user session handling is switched off by means of an Ubuntu-local patch that switches the D-Bus policy back to root-only; we'd like to enable this, but we can't do so until it has a comprehensive test suite
<skaet_> from discussions jhunt, branch 3 is in good shape.   and 1,2,3 are all bound together now, so its really just branch 2 that's the top worry.    Sounds like we've got fall backs,  do we have adequate documentation if there are issues?
<skaet_> cjwatson, or can we ensure we've got it in place by Thursday?
<skaet_> ;)
<cjwatson> I think we should be able to manage some form of documentation of the intended semantics of sessions by Thursday
<cjwatson> probably improvements to the init(5) man page
<skaet_> cjwatson,  its sounding ok from a desktop sense then, concern will be impact to server team.  Am working with Daviey to figure out what sort of coverage they'll have this week, with ensemble sprint going on.
<Daviey> Personally, i think getting exposure in A3 makes sense... it doesn't seem to be a kitten killer on a server i just tried it on.
<Daviey> Would feel happier if robbbie ack'd that opinion tbh.
<skaet_> cjwatson, jhunt,  Daviey,   since its new features only, we'll have documentation and we're not affecting the old ones,  ok.  lets put it in.   ack.
<skaet_> cjwatson, I'll put my comments in the bug as well - ok?  or do you need something further.
<Daviey> sounds good to me.
<cjwatson> that's fine, thank you!
<didrocks> hey
<didrocks> so, we get some last minute challenges that will delay the unity release for some hours and upload is planned tomorrow morning. is it ok?
<ogra> hrm
 * ogra would have liked some arm images tomorrow to fix remaining issues ... we didnt have any since 10 days or longer due to unity and nux
<cjwatson> didrocks: do wew get a choice? ;-)
<cjwatson> *we
<skaet_> didrocks, urk
<didrocks> cjwatson: well, we can take a chance and see if it blows up in that state :)
<didrocks> just that there is a compiz upload under way
<didrocks> and the other changes aren't tested a lot
<skaet_> didrocks, prefer to have them tested and solid before they go in.
<didrocks> the counter part is tomorrow morning though :/
<didrocks> at least, compiz upload tonight
 * ogra thinks we really should have two weeks between FF and the next milestone in N+1
 * skaet_ agrees with ogra
<didrocks> we tried to feed everything we can for FF, but some design changed came in since and that's impact a lot the codebaseâ¦
<skaet_> cjwatson, do we still have some libreoffice breakage going on with the DVDs?
<cjwatson> I think that should be fixed, it was just skew due to the i386 build being in binary NEW, which I processed on Saturday
<skaet_> last night's report still had it and there's a few others in there.   looks like we have oversize cds again as well though, but that can be handled with documentation.
<cjwatson> the DVDs are only built every few days
<cjwatson> and that's subject to the build succeeding of course
<skaet_> ah,  didn't quite understand that.
<skaet_> Can we kick off a DVD build then, and see if we're good there?
<cjwatson> sure, running
<skaet_> thanks.
<skaet_> didrocks,  we're going to need to handle this very, very carefully.
<skaet_> Riddell is on point for handling the image building for this release once we go into Alpha 3 freeze at 2300 UTC.
<didrocks> skaet_: ok, I'm not even sure compiz will get built at 2300 UTC
<skaet_> didrocks, its uploaded though?  how much time does it take (ie. are we waiting on priority, or compute cycles?)
<didrocks> skaet_: not yet, trying to get all the needed bits from upstream
<skaet_> urk,  this is not sounding good.
<skaet_> hmmm
 * ogra feels the soft freeze turn into a wobbly one :)
<skaet_> cjwatson, didrocks, what are the implications on holding off on the upload until after we know we have a fallback set of images from tonights build?
<didrocks> skaet_: it's a soft freeze isn't it? so I will upload compiz tomorrow morning, after the CD spin?
<dbarth> skaet_: the FFE request is at: https://bugs.launchpad.net/unity/+bug/683688
 * didrocks doesn't like to mix compiz and unity upload at once
<ubot4> Launchpad bug 683688 in unity (Ubuntu) (and 3 other projects) "Touch window management gesture previews (affects: 1) (heat: 6)" [Undecided,Triaged]
<didrocks> and there is this FFe as well coming with it ^
<dbarth> skaet_: let me know if i can subscribe the release team to it, if the request is receivable
<ogra> didrocks, that means unity upload in the afternoon ?
<didrocks> ogra: depends on what the release team is telling, tomorrow morning is definitively acheavable if I can upload compiz now
<ogra> well, asap from my POV
<skaet_> dbarth,  yes subscribe release team to it.   I'm not sure we're going to be able to include this latest set in A3 though.
<ogra> the arm team has no clue what works on the arm images and what doesnt, last successfull image build we had was on feb 16th
<skaet_> didrocks, compiz and unity need to be tied together though right?
<ogra> one depends on the other
<highvoltage> has anyone installed recent daily builds when an existing machine is alread installed? ubiquity doesn't proceed to the Where-are-you slide for me on two different machines when I have an existing system installed
<highvoltage> s/existing machine/existing system/g
<didrocks> skaet_: the new unity will dep on the new compiz, right
<sbeattie> slangasek: are you on AA duties today? Can you deNEW python-libapparmor? We'd like to get the apparmor packages update in for alpha 3.
<slangasek> sbeattie: sure, looking
<skaet_> didrocks, if compiz is in with the old unity - are we broken?  (ie did any key APIs change?)
<didrocks> skaet_: but old unity still works with the new compiz if that's the question (for this one)
<skaet_> yup it was.
<skaet_> :)
<didrocks> some API addition, only
<didrocks> humâ¦ wait
<skaet_> and bug fixes, I assume...   but ok,  less risk.   do we have a recovery plan if new compiz kitten kills.
<skaet_> ?
<didrocks> I'm checking something with upstream, because they just told me "of course, you need to build all rdepends"
<didrocks> which is a no goâ¦
<skaet_> sigh
<slangasek> sbeattie: accepted
 * didrocks is totally exhaustedâ¦ and it's only Monday :/
<sbeattie> slangasek: thanks!
 * skaet_ appreciates the effort the team did over the weekend,  was watching it. 
<dbarth> skaet_, didrocks: he grab handles feature is a nice-to-have one, a3 can ship without it; it's mostly for MT users that it's importnat
<didrocks> dbarth: it's in trunk
<skaet_> didrocks,  ok, lets get your upload candidates for unity and compiz solid and unit tested today,  and in parallel, let us get some good A3 candidate images with what we have in the repository already.   Then tomorrow morning you do some testing with the candiate A3 images, with this candidate update added.   If its solid when tested out with the A3 images, we'll negotiate with Riddell and Jibel to see if we can bu
<skaet_> ild and get it tested in time for A3,  otherwise it will need to go in after.
<didrocks> skaet_: sounds good then holding the upload right now
<didrocks> in any case, we need the FFe above acked
<skaet_> didrocks,  thanks.
<didrocks> skaet_: thanks to you :)
<highvoltage> Riddell: was this by any chance when installing from a USB disk? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/726581
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 1) (heat: 6)" [Undecided,New]
<ogra> skaet_, that wont work for arm
<ogra> we need fixes that will be in the upcoming unity to make it actually build
<skaet_> ogra, urk
<ogra> skaet_, as i said above, we're waiting for an installable unity since feb 16th
<skaet_> educate me a bit on the dependencies involved here please...
<ogra> we dont even know if the images will work in case they actually build
<ogra> ubuntu-netbook depends on unity
<ogra> after feb 16th nux was broken until FF, that made unity uninstallable ...
<skaet_> ogra, do we know that the images right now will actually solve the issues, or are we hoping?
<ogra> after FF unity itself was broken ... that makes unity uninstallable
<ogra> we dont know anything about the images atm
<ogra> thats why i am so pushy to get any
<ogra> i know that unity, and jockey hold up image builds atm
<ogra> jockey was fixed this morning
<ogra> unity is pending a fix that was submitted upstream, if that doesnt get in we could indeed still solve it through a package patch but that should happen asap
<skaet_> Would like to investigate the package patch option then, ASAP.
<skaet_> dbarth, ^^ ?
<skaet_> dbarth, can we get a package patch, so we have a possible way to unstick ARM for the release, and not jeopardize the rest of the release?
<skaet_> didrocks, ^^?
<didrocks> skaet_: sorry, I'm still under a lot of things to do
<didrocks> still trying to get compiz in shape
<didrocks> not like if i asked for that 12 hours agoâ¦
<skaet_> didrocks, understand.
<skaet_> is there anyone else who can help pull the patch and test it?
<ogra> didrocks, well, if you dont make it, could you add a package patch with the fix from janimo to have the unity ftbfs fixed ?
<ogra> i could prepare a dpatch against whats in the archive atm
<didrocks> ogra: no dpatch, we can use cherry-pick
<ogra> err s/dpatch/debdiff/
<didrocks> wait, we need to define what can get in
<cjwatson> skaet_: I'd be concerned about relying on a fallback - the installer has a number of open partitioning bugs and I'm not sure we've nailed them all
<didrocks> can we hold on for 15 minutes?
<skaet_> cjwatson,  I was afraid that might be the case... :(
<skaet_> didrocks,  ok.
<ogra> skaet_, bug 724615 btw
<ubot4> Launchpad bug 724615 in unity (Ubuntu) (and 1 other project) "unity FTBFS on armel (affects: 1) (heat: 1170)" [High,Fix committed] https://launchpad.net/bugs/724615
<skaet_> cjwatson, ok, so we need focused testing right at start of images emerging on the partitioning bugs.  Any chance we can pull together a candidate image right now (the DVDs that were building??) and see where we are?
<cjwatson> partitioning is just what I know about ...
<cjwatson> we can probably do an image later tonight - the current DVDs, I wouldn't be so sure
<skaet_> cjwatson,  if you can get an image that should be close to what we'll be using, I'll see if we can get some sniff testing lined up with marjo.   If sniff testing doesn't look good, we're going to have to go with a package patch if we want arm to go out with A3.
<cjwatson> I'd honestly be pretty surprised if images from tonight will be releaseable
<jdstrand> skaet_: hey. did you get an answer as to whether universe/multiverse needs FFes?
<cjwatson> we've had too many days in succession with uninstallable images, with a sequence of different things going wrong
<ScottK> skaet_ and jdstrand: What question is there?
<dbarth> skaet_: distro patch you mean, sure, discussing that with didrocks atm
<jdstrand> ScottK: well, I couldn't remember, and skaet couldn't find an authoritative answer on whether or not universe/multiverse needs an FFe now that we are past FF. the wiki seems to only imply it
<ScottK> Yes.
<jdstrand> cool
<jdstrand> I'll make the wiki more explicit then
<ScottK> Thanks.
<skaet_> thanks ScottK, jdstrand
<jdstrand> cjwatson: after I look at some more deNEWs that might affect alpha3, I was planning to start looking at the alpha3 buildability things that I can investigate/prod/fix as an AA. are there particular items I should look at first? (noting your recent comments)
<skaet_> cjwatson, I fear you are right.
<cjwatson> jdstrand: nothing in particular, just beat on as much as you can
<jdstrand> skaet_: that goes for you too
<jdstrand> cjwatson: ack
<jdstrand> I hoped to be able to beat on it sooner, but between FF and various other items last week, I was unable to
<cjwatson> the livefs bits of the Ubuntu DVDs at least built successfully
<skaet_> cjwatson, good to know.  If you can go into #ubuntu-testing and let marjo know which image to pick up,  he's ready to start doing some early testing on it to see where we are.    If its better to wait for another build from later today, please advise.
<skaet_> jdstrand,  do we know if the problems with ubuntu-meta 1.216 produces uninstallable binaries:
<skaet_>   * ubuntu-desktop (amd64)   have been resolved?
<jdstrand> skaet_: let me see
 * jdstrand hasn't been looking at that
 * skaet_ --> lunch, biab
<didrocks> soâ¦
<didrocks> skaet_: dbarth: I have a working compiz right now
<jdstrand> skaet_: my apt-get install ubuntu-desktop with only main and restricted enabled in my chroot seems to indicate yes
<didrocks> so, to sum up:
<didrocks> - new compiz with decorators fix and some requirements for next unity here
<didrocks> - I can distro-patch unity to get the FTBFS fixed as well as at least one important commit to fix a "dancing launcher" issue
<didrocks> then, tomorrow, we can push the new unity release
<didrocks> does it sounds ok?
<dbarth> didrocks: +1 for the dancing launcher one, getting that one + the decorator is important for a3
<marjo> didrocks: sounds ok
<skaet_> didrocks,  sounds good.   We'll make the call on the rest of unity tomorrow, and cross fingers for no regressions for compiz
<didrocks> skaet_: ok pushing away then :)
<didrocks> 1. compiz -> now
<didrocks> ogra_: FYI ^^
<ogra_> didrocks, fine with me as long as i dont stand in the rain in the end :)
<didrocks> ogra_: seems really pressuring and rainy here since too long :)
<ogra_> heh, yeah
<skaet_> jdstrand, can you keep a close eye on compiz as it goes into the archive, and nudge up its building priority?   would prefer to know soonest if its going to be problematic.
<ogra_> didrocks, i guess we can be just lucky its still water that comes down from above ;)
<didrocks> ok, compiz done, time for backporting some unity fixes
<didrocks> ogra_: heh, agreed :)
<skaet_> didrocks, thanks.
<dbarth> ogra_: is there still an FTBFS problem with unity on arm?
 * skaet_ walks away for computer now for food,  REALLY.
<dbarth> or didrocks ^^, ie do you need help fixing that
<didrocks> dbarth: it should be fixed with the commit I backport
<dbarth> ok
<didrocks> dbarth: we need daily armel build
<ogra_> right, its holding back the image builds since FF
<ogra_> i guess we should in the future just use distro patches for armel failures to overcome that
<ogra_> it was unfortunate that nux and unity failed in succession this time
<didrocks> ogra_: that would be better to prepare before the release
<didrocks> yeah :/
<didrocks> hence the daily build option we have for FTBFSâ¦ just no armel hw still
<ogra_> that should be solved pretty soon
<ogra_> davidm is working on it
<didrocks> that will be nice, I don't know if I'm going to break you guys before the upload righ tnow :/
<ogra_> you shouldnt
<dbarth> ogra_: we had that for certain ppas but powerpc and other as well
<dbarth> ogra_: it's something i need to ask IS for right? i don't see a build option in the ppa config right now
<cjwatson> that's called "non-virtualised PPAs" - you have to ask IS for it, yes
<ogra_> dbarth, i can arrange that your team or the desktop team has access to the canonical-arm-dev ppa
<cjwatson> and it's not a generally available facility because there are security implications
<cjwatson> (it means that PPA has no sandboxing)
<ogra_> right
<didrocks> yeah, I remember the discussion about it at UDS
<ogra_> thats why all access to arm PPAs is restricted
<ogra_> we are working on a solution and should have it ready right by release
<ogra_> (non deliverable HW held this up)
<didrocks> ok, unity builds and work fine here, pushing
<didrocks> dbarth: skaet_ ^^
<dbarth> didrocks: cool
<dbarth> ogra_, cjwatson: who do i need to email to get the process started?
<cjwatson> RT
<dbarth> k
<ogra_> you shouldnt file an RT for that, we specifically have an existing PPA specifically for such testbuild cases
<jdstrand> skaet_: I actually don't have the access to up the build priority
<didrocks> ogra_: that would be better to test it before the release
<ogra_> didrocks, right
<didrocks> ogra_: and as I got most of the time the release really late, I don't see myself pushing the release to the ppa, wait it builds and then if it doesn't, what to do? it will be 10PM with nobody around
<jdstrand> skaet_: I could probably have that arranged though
<jdstrand> skaet_: but it isn't needed-- it is building
<jdstrand> (done on all but armel, and building on armel)
<highvoltage> https://wiki.ubuntu.com/OtherProjectSchedules is linked from https://wiki.ubuntu.com/NattyReleaseSchedule and is outdated (just thought someone here might want to know)
<ogra_> didrocks, i dont get that ? so why would a PPA hel at all then ?
<ogra_> *help
<didrocks> ogra_: the daily builds are automatic
<skaet_> thanks jdstrand
<didrocks> ogra_: each commits is pushed and built
<ogra_> ah
<jdstrand> ok, so NEW is caught up for source and binaries until saturday, and nothing pending in main
<didrocks> so we know that really early :)
 * jdstrand moves away from NEW processing
<ogra_> didrocks, but then you need close control over the people that can commit
<jdstrand> s/until/up til last/
<didrocks> ogra_: agreed (should be the dx team IIRC)
 * skaet_ --> appt, out of touch for a bit.
<cjwatson> upstart 0.9.0-1ubuntu3 uploaded
<didrocks> unity build on arm
<didrocks> ogra: skaet_ ^^
<didrocks> built*
<ogra> yay
<didrocks> compiz ok as well, pending publishing on armel
<didrocks> all sounds under control :)
<didrocks> so now, let's wait tomorrow morning for next unity with a good QA
<ogra> ++
<ogra> thanks for all the effort
<didrocks> ogra: you're welcome :)
<didrocks> see you tomorrow!
<marjo> cjwatson, didrocks: do you still want QA team to do sanity testing? otherwise, you'll have to wait for jibel tomorrow morning
<marjo> cjwatson, didrocks: sanity testing today (US time)
<cjwatson> we're approaching ready to start building images, but it's going to be another hour
<cjwatson> (which time I am going to spend with my family rather than my computer)
<marjo> cjwatson: thx for the update
<slangasek> skaet_, cjwatson: hi, so as I understand it these current builds are smoke testing, right?  pitti approved a dpkg multiarch FFe conditional on getting it in before alpha3, and I haven't uploaded yet because the change has still been in upstream review to make sure there are no interface changes needed.  Is there time for me to upload dpkg before a3 or should we look at doing that Friday instead?
<cjwatson> slangasek: I'm not sure, I think skaet_ is in more of a hurry than I am
<cjwatson> on general principles I (a) sympathise with pitti's stipulation, (b) REALLY want this in for natty, and (c) would be more comfortable with Friday
<cjwatson> I realise that these are mutually inconsistent
<slangasek> :-)
<cjwatson> (oh hey, don't suppose you can get dpkg upstream to accept Debian #612472, and then we would have no outstanding Ubuntu delta that needs to be preserved ...)
<ubot4> Debian bug 612472 in dpkg "dpkg: Ubuntu ppc64 optimisation defaults" [Wishlist,Open] http://bugs.debian.org/612472
<slangasek> ah, I'll bend buxy's ear on this :)
<cjwatson> I would be happy with Friday as long as that doesn't cause us to miss natty, so I wonder if it's possible to contact pitti
<cjwatson> doing Ubuntu alternate/desktop/server Kubuntu alternate/desktop builds now
<cjwatson> by way of smoke-testing
<cjwatson> and I'm off bedwards
<jdstrand> so, looking at natty_probs.html, it is mostly a bunch of armel stuff. anything related to smb is resolving. bugs filed for various others
<jdstrand> fglrx and nvidia are due to the known xorg-video-abi-8.0 incompatibility
<jdstrand> (those are obviously amd64 and i386)
<jdstrand> and that is also what makes kubuntu-full uninstallable
<jdstrand> so, in all, natty_probs.html looks quite good
<jdstrand> skaet_: ^
<jdstrand> and with that, I am out of here. I'll look at cd issues when I come online again, if cjwatson and pitti don't beat me to it
<jdstrand> (based on what I've seen today, they should all by fine, but obviously we need to wait for cjwatson's smoke test
#ubuntu-release 2011-03-01
<marjo> ping skaet
<marjo> ping skaet_d
<skaet_> jdstrand, thank you for looking into the natty_probs.html.  fingers are crossed for a smooth set of builds tonight before Riddell switches the builders to manual.
<skaet_> Riddell, when the images come off the build, please get them added into the .iso tester, so we can get started on testing them immediately.   Note, when I checked just now,  .iso tester still needs to be reset.   Please work with jibel to get it cleaned up, if its not reset already to Alpha 3 when you've got images to push.
<charlie-tca> Kubuntu alternate-amd64.iso dated 2011-03-01 installed on hardware
<jdstrand> huh
<jdstrand> various cd images died cause ubuntu-minimal couldn't be installed due to:
<jdstrand> dpkg: error processing lsb-release (--configure): subprocess installed post-installation script returned error exit status 1
<jdstrand> dpkg: error processing rsyslog (--configure): subprocess installed post-installation script returned error exit status 10
<jdstrand> not reproducable here...
 * jdstrand makes note to ask how antimony bootstraps images
<slangasek> skaet_: so given that bug #723846 is approved for a3, does it make sense for me to upload what's in James' branch to give us a leg up on image respins?
<ubot4> Launchpad bug 723846 in upstart (Ubuntu) "Feature Freeze Exception request for Upstart in Natty (affects: 1) (heat: 14)" [High,In progress] https://launchpad.net/bugs/723846
<slangasek> jdstrand: exit status 10 is a pretty good indicator of a debconf-related failure
<jdstrand> interesting.
<jdstrand> well, I am just passing through and noticed that
<jdstrand> no time to debug, but will follow up and certainly learn something tomorrow
 * jdstrand likes to learn :)
<slangasek> the lsb-release error is almost certainly *not* debconf-related, however
<slangasek> jdstrand: do you have an example log I could fix my eyes on?
<jdstrand> slangasek: there is not a lot to go on, but let me paste one
<slangasek> well, you said "how antimony bootstraps", but package installation is normally done on the livecd builders, no?
<jdstrand> slangasek: full log for LiveFS kubuntu/natty/i386 failed to build on 20110301: http://paste.ubuntu.com/573772/
<skaet_> slangsek, branch 1-3 are approved for A3 based on what jhunt and cjwatson did.
<skaet_> those changes have been uploaded already earlier.   What's in james' branch?
<slangasek> jdstrand: right, that log is available at available at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/kubuntu/20110301/livecd-20110301-i386.out, no?
 * skaet_ approved it earlier in the day, but forgot to hit save on the bug update until she got back to her computer (multiple windows hid it... :P )
<jdstrand> slangasek: looks like it :)
<slangasek> skaet_: ah, if it's already uploaded then nevermind :)
<jdstrand> see, I even got to learn something *tonight* \m/
<slangasek> skaet_: I saw the bug update and was trying to avoid it waiting until morning
<slangasek> jdstrand: :)
<slangasek> so, this is some sort of debootstrap failure involving lsb-release and pycentral; not god
<slangasek> good
<slangasek> (not god either, but that's a somewhat less specific statement)
<jdstrand> lol
<skaet_> :)
<skaet_> slangsek,  yup I think were good for the upstart side,  now the issue of failure to builds .... urk.   not good.
<slangasek> yep, working on reproducing locally
<skaet_> thanks.
<jdstrand> I tried 'apt-get install ubuntu-minimal' in my natty schroot, which was created via mk-sbuild
<jdstrand> it worked fine
<jdstrand> (or course with just main and restricted, and archive.ubuntu.com, not something local
<jdstrand> )
<GrueMaster> armel images failed to build.  Looks like dpkg postinst issues with lsb-release and rsyslog.
<jdstrand> GrueMaster: yeah, so did several others
<GrueMaster> Ah.  See it now in the backscroll.
<jdstrand> (in recent backscroll)
<jdstrand> slangasek: does antimony use debootstrap?
<slangasek> jdstrand: shouldn't; the debootstrapping should be on the livefs builders
 * jdstrand really doesn't want to get embroiled in this right now, but is curious
<slangasek> but that log is from the debootstrap call on a livefs builder, yes
<slangasek> (i.e., not /from/ antimony, only dispatched via antimony)
<jdstrand> I think you might have taken my question slightly too precisely
<slangasek> guess so :)
<jdstrand> I only know that antimony 'does stuff' to boot strap an image
<slangasek> anyway, yeah, this'll be a problem related to initial installation of the core packages
<jdstrand> wither helpers do it or whatever, I have no idea. but if the main thing is debootstrap, then maybe I can try that here
<slangasek> yes, it's debootstrap
<jdstrand> s/wither/whether/
<jdstrand> my schroot uses a buildd bootstrap...
 * jdstrand tries a straight up debootstrap before heading to bed
<slangasek> reproducible
<jdstrand> slangasek: I'm using something like this: debootstrap natty /natty/ http://archive.ubuntu.com/ubuntu/
<jdstrand> slangasek: as that what you are using?
<slangasek> yes
<jdstrand> slangasek: so, lsb-release failed there right? looking at the logs there seemed to be problems before trying to install ubuntu-minimal
<slangasek> it's lsb-release; ubuntu-minimal depends on lsb-release
<slangasek> and I think this is related to my dpkg upload
 * jdstrand nod
<jdstrand> nods even
<slangasek> (pycentral is snuffling around inside of /var/lib/dpkg, which it Ought Not Do)
 * jdstrand just reproduced
<slangasek>         if not os.path.exists('/var/lib/dpkg/info/%s.list' % self.pkgname):
<slangasek>             self.error("package %s is not installed" % self.pkgname)
<slangasek> tsk, bad python-central
<slangasek> fix will be on its way before the top of the hour
<jdstrand> cool
<slangasek> what builds should I retrigger once it's published?
<jdstrand> well, I got two learn 2 things tonight
<jdstrand> let me get the list
<jdstrand> kubuntu/natty/armel+omap
<jdstrand> kubuntu/natty/armel+omap4
<jdstrand> ubuntu-netbook/natty/armel+omap4
<jdstrand> ubuntu-netbook/natty/armel+omap
<jdstrand> kubuntu/natty/amd64
<jdstrand> kubuntu/natty/i386
<jdstrand> edubuntu-dvd/natty/amd64
<jdstrand> edubuntu-dvd/natty/i386
<jdstrand> kubuntu-mobile/natty/i386
<jdstrand> I don't know what's pending, but that is everything I have
<jdstrand> kubuntu/natty/armel+omap was the last and failed 28 minutes ago
<slangasek> ok
<jdstrand> nice, now I don't have to feel guilty about going to bed
<jdstrand> slangasek: thanks! :)
<slangasek> sure thing :)
<slangasek> it's my bug anyway ;)
<jdstrand> learned 2 new things, and a guilt-free sleep. pretty sweet
<slangasek> well, technically pycentral's, but I set it off :-)
<jdstrand> hehe
<slangasek> ok, python-central is accepted but I ran into the content generation job as usual
<slangasek> trigger set to fire off builds as soon as that's cleared and python-central is in the archive
<slangasek> and I have the fix for libreoffice on armel, but maybe today is not the day to upload that, given that it's not going to get done before alpha3 anyway :)
<Keybuk> slangasek: would you mind if I made an upload?
<ev> it's a trap!
<Keybuk> ev: can you test something for me?
<Keybuk> touch /etc/init/.conf
<slangasek> Keybuk: I'm too busy putting out my own dpkg-induced fires to mind, but that doesn't mean the other members of the release team won't :
<slangasek> )
<slangasek> I think I have python-central fixed now
<slangasek> now I have to unbreak ucf
<slangasek> which ironically is broken because of a patch to ucf that I wrote
<Keybuk> wow, ev stopped responding to PING
<slangasek> so... another hour before debootstrap will work again
<Keybuk> he really tested that
<Keybuk> you'd think he'd know better than listening to me :p
<ev> jerk
<Keybuk> love you too
<cody-somerville> +1
<ev> 'twas an excuse to make more coffee
<ev> and curse your name
<Keybuk> slangasek: ok, no upload from me
<slangasek> kubuntu alternate will also need respun for this issue
<slangasek> it has the new dpkg in it, so debootstrap will fail at install time
<pitti> slangasek, cjwatson: disabling CD cron jobs now, so that we can do an optimized pipeline mass rebuild after the remaining debootstrap fixes
<slangasek> yes, I already have a pipeline queued... I didn't notice that cronjobs were still enabled
<pitti> ah, good to know
<pitti> slangasek: do you also have a current pipeline which includes ports?
<pitti> the pipeline in my documentation is already quite old
<slangasek> pitti: AIUI there are no longer separate jobs for ports
<pitti> ah, seems your pipeline already started? at least natty/powerpc alternates are already building
<ev> might I kindly ask an archive admin to promote dpkg-repack to main
<pitti> ev: ugh, yes
<pitti> ev: I see it's blocking ubiquity, but please file an MIR
<ev> I did
<ev> sorry, I didn't reference it in the upload
<pitti> ah, you aren't supposed to
<pitti> great, promoting and closing
<pitti> slangasek: ^ I think this needs another publishing cycle (for your wait-for pipeline)
<ev> bug 726453
<ubot4> Launchpad bug 726453 in dpkg-repack (Ubuntu) "[MIR] dpkg-repack (affects: 1) (heat: 8)" [Undecided,Fix released] https://launchpad.net/bugs/726453
<ev> pitti: thanks
<pitti> slangasek: as ubiquity depends on it
<slangasek> oh; should I turn this over to you then?
<slangasek> way past my bedtime here
<pitti> slangasek: sure; mind to throw me your pipeline?
<slangasek> done
<pitti> slangasek: good night!
<ev> could I squeeze in one last ubiquity upload or are we well into the process?  There's a bug in partman-auto that's fixed with the latest upload, but it requires another ubiquity upload for it to make it to the desktop CDs as well.
<pitti> ev: we can squeeze it in, I think
<ev> awesome, uploading now
<pitti> I checked natty_probs now, and all i386/amd64 uninstallabilities are expected now (fglrx/nvidia), except for ubiquity (fixed with promotion) and jasper (investigating now)
<pitti> ev: I'll rebuild the livefs-base in the meantime then, and the alternates
<pitti> ah, jasper is just a followup of ubiquity
<slangasek> ev: so, ah... just how much does ubiquity depend on dpkg-repack?
<slangasek> because on a hunch (man, I'm never gonna get to bed) I just checked, and dpkg-repack isn't multiarch-safe
<ev> slangasek: heavily for the reinstall/upgrade option
<ev> alternative proposals welcome
<slangasek> well, dpkg-repack will need fixed for multiarch regardless
<slangasek> I'm just asking if this is a feature you need working in alpha 3... because right now it won't
<slangasek> it needs to be ported to use $dpkg_lib/info/$arch instead of $dpkg_lib/info... not too tricky, but I think somebody on your side of the pond will need to take care of this
<ev> I'm not overly concerned if it's broken and release noted, so long as it's still allowed to make the final cut
<slangasek> (if you need it urgently)
<slangasek> ok
<slangasek> good, then I'll sleep easy :)
<ev> :)
<ev> pitti: ubiquity 2.5.21 uploaded
<ev> right, I'm going to bed for a few hours. Don't hesitate to call my cell and wake me if it turns out I broke the world somewhere along the way.
<jibel> cjwatson, skaet_, Ubuntu alternate amd64/i386 fails to install this morning. rsyslog and lsb-release failed to install. I'll file a report and attach the logs.
<jibel> during the setup of the base system
<pitti> jibel: nevermind, it's known
<pitti> jibel: and already fixed
<pitti> jibel: I'm about to respin all images
<jibel> pitti, okay, thanks.
<Riddell> any plan for ubuntu desktop being oversized?
<pitti> Riddell: I killed a langpack
<pitti> and we have a bug to remove libreoffice-tango from the default install
<pitti> but too late for a3
<pitti> Riddell: FTR, I have all alternate rebuilds queued up, and wait for ubiquity 2.5.21 to rebuild the entire lot of desktops/dvds/preinstalled
<pitti> Riddell: are you aware of anythign the Kubuntu CDs block on?
<pitti> argh, sync-mirrors keeps hanging on scandium (discussing with IS)
<Riddell> Kubuntu is fine except I had bug 726581 yesterday
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/726581
<pitti> I temporarily take out scandium from etc/config, to unblock CD builds
<pitti> jibel: new ubuntu alternates posted, they ought to work now
<pitti> s/new// really (it's the first image on the tracker for a3)
<jibel> pitti, ok syncing.
<pitti> cjwatson: sorry for all the build log spam; I'm on it
 * pitti starts desktop/DVD build pipeline from hell
<pitti> kubuntu alternates posted, ready for testing
<pitti> cjwatson: looks like nic-usb-modules-2.6.32-410-dove-di is on the mirror now, I'm retrying a build
<pitti> ... of d-i
<cjwatson> yeah, I probably ought to have looked at the d-i/armel build failures rather than ignoring them
<pitti> cjwatson: good morning
<pitti> cjwatson: I didn't investigate a lot whether the 410 kernel was actually only NEWed recently, but the buildds don't have anything else to do anyway
<pitti> and I guess this is a blocker for the preinstalled images
<pitti> (maybe not -- I don't know how they are actually built)
<pitti> cjwatson: dang, failed again with the same error
<pitti> E: Unable to locate package kernel-image-2.6.32-410-dove-di
<pitti> E: Couldn't find any package by regex 'kernel-image-2.6.32-410-dove-di'
<didrocks> so, FYI, we are testing unity trunk and should get something ready for upload in the next hour
<pitti> cjwatson: ah, that's because I can't look properly
<pitti> kernel-image-2.6.32-410-dove-di | 2.6.32-410.27 | maverick/main/debian-installer | armel
<pitti> maverick != natty..
<didrocks> do you think that, as planned yesterday, there will a window for it in alpha3?
<pitti> didrocks: the current ubuntu desktops are just about to finish, and my current rebuild queue will still take several hours, so it's not too urgent
<didrocks> pitti: ok, will keep you posted then
<pitti> didrocks: DVD will build in some 2 hours, so if it gets uploaded and published  before, that'd speed it up a bit
<pitti> didrocks: but if it misses that, no worries; good testing >> speed at this point :)
<didrocks> pitti: we are still testing a lot to ensure we have no regression, I'll tell you :)
<didrocks> yeah
<didrocks> prefer quality so closed to the gate
<didrocks> ;)
<pitti> xubuntu alternates posted
<cjwatson> pitti: so should I just disable dove support in d-i for now?  looks like the kernel is gone ...
<pitti> cjwatson: TBH I have no current idea about our variety of armel kernels
<cjwatson> bug 715984
<pitti> ogra: which armel flavours are we supposed to have these days? "linux" only builds omap AFAICS; no omap4, no dove?
<ubot4> Launchpad bug 715984 in linux-mvl-dove (Ubuntu Natty) (and 3 other projects) "Remove linux-mvl-dove from Natty (affects: 1) (heat: 201)" [Critical,Fix released] https://launchpad.net/bugs/715984
<pitti> aah
<pitti> that'd be it :)
<cjwatson> OK for me to reupload debian-installer for that, then?
<pitti> sounds fine to me
<pitti> cjwatson: it doesn't practically affect the currently built alternates, right?
<pitti> cjwatson: or does it include new wrapped components?
<cjwatson> not that I know of
<pitti> ubuntu-server posted
<pitti> apparenty my seed change didn't make it into the ubuntu desktop rebuild, so it's still oversized; at this point I'll wait for the new unity to land before I rebuild
<pitti> http://cdimage.ubuntu.com/daily-live/20110301.1/ if someone wants to give it a smoketest
<pitti> ubuntustudio posted
<pitti> kubuntu desktop posted
<cjwatson> wait
<cjwatson> we need to fix bug 727106
<ubot4> Launchpad bug 727106 in dpkg (Ubuntu) "multiarch symlink not present in fresh installs (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727106
<cjwatson> it's a pain to migrate otherwise
<cjwatson> uploading a quick fix now, and patch sent to buxy
<pitti> cjwatson: that'll require rebuilds of all images?
<cjwatson> yes
 * pitti stops the big pipeline then
<pitti> marking all images as to be rebuilt then
<cjwatson> otherwise any systems installed from those images will be different from upgraded systems in a way that's (a) significant and (b) hard to put right latere
<cjwatson> *later
<cjwatson> sorry
<pitti> cjwatson: hm, on first sight that seems like something that could be done in a postinst?
<cjwatson> then you have to move a load of files in /var/lib/dpkg/info in a maintainer script, temporarily making them be not a path that dpkg will consider
<cjwatson> I don't think this is safe
<pitti> ok
<pitti> all images disabled (I left upgrades, as there haven't been any tests yet)
<cjwatson> I'm waiting for brltty to build before reuploading d-i
<cjwatson> there was a conflict marker in one of its startup scripts
<jibel> when can we expect the next batch of images to be ready for testing ?
<pitti> jibel: I'm currently doing a smoketest, and doing so with the current images is appreciated (to check for installer failures, etc.)
<pitti> jibel: the "good" ones will still take some 4 hours, I'm afraid
<pitti> we need dpkg, brltty, d-i, nux, unity, and have dependencies between brltty->d-i and nux->unity
<cjwatson> hmm, tempting to stop the publisher so that brltty/armel will have time to get in
<cjwatson> would that be ok?
<pitti> please do
<cjwatson> done
<pitti> cjwatson: is the d-i build failure due to the missing symlink in dpkg? (doesn't immediately look like it) or yet another bug?
<pitti> cat: ./tmp/cdrom_gtk/tree/extraudebs-tmp/var/lib/dpkg/info/*.templates: No such file or directory
<jibel> pitti, thanks, I'll continue testing the current images in approx. 1 hour. I'm doing upgrades at the moment.
<cjwatson> already fixed in bzr and upstream git
<cjwatson> d-i sets up its own dpkg/info directory
<pitti> \o/ you rock
<pitti> jibel: nice, thanks
<cjwatson> so it needs to create that symlink otherwise (a) its own build system and (b) udpkg will get horribly confused
<pitti> jibel: I'm running an amd64 smoketest now, too
<ogra> pitti, right, we only support omap flavours
<cjwatson> publisher running
<cjwatson> uh, except there was already one running from the last hour, WTF
<cjwatson> 09:43 <pitti> argh, sync-mirrors keeps hanging on scandium (discussing with IS)
<cjwatson> pitti: what did IS say to that?
<cjwatson> because the publisher is hanging on scandium too
<cjwatson> 27321 11:26:36      \_ ssh archvsync@scandium
<cjwatson> $ date
<cjwatson> Tue Mar  1 12:16:43 UTC 2011
<pitti> cjwatson: talked to Ng, and he promised to get back to it once he sorted out some high-urgency stuff
 * pitti pokes again
<wgrant> archive.u.c is partly borked too, so there are probably big issues.
<ogra> would someone kick off armel builds in the meantime (we dont need d-i on the preinstalled ones)
<pitti> ogra: need to wait on dpkg
<ogra> oh, ok
<pitti> well, perhaps not, unless armel needs multiarch?
<ogra> it will, though i would like to have a boot smoketest asap
<ogra> we didnt have images since feb 16th due to archive out of sync-ness
<ogra> so all feature freeze breakage hasnt been tested yet
<pitti> jibel: just finished a successful amd64 desktop smoketest, so don't bother about that one
<cjwatson> pitti: we should block on the new dpkg on all architectures, multiarch or not
<pitti> *nod*
<cjwatson> it will affect any software that looks in /var/lib/dpkg/info/
<pitti> so, waiting on publisher, smoketest done, I think I can disappear for a quick lunch
<pitti> cjwatson: Ng re-poked, FTR
<cjwatson> [5~/wg 64
<cjwatson> urgh
<didrocks> compiz just uploaded to fix unity launching in the classic session
<didrocks> all nux + unity testing is succesfull (testing done by four people on trunk)
<didrocks> nux building in my pbuilder (will take 30 min)
<cjwatson> publisher really running
<didrocks> then building packaged unity
<ogra> Setting up lsb-release (4.0-0ubuntu9) ...
<ogra> pycentral: pycentral pkginstall: package lsb-release is not installed
<ogra> pycentral pkginstall: package lsb-release is not installed
<ogra> dpkg: error processing lsb-release (--configure):
<ogra> hmpf
<cjwatson> that should be fixed with current python-central
<ogra> phew, k
<skaet_> pitti, cjwatson,   just read through the backscroll,   busy morning.    Has unity been incorporated in the current run or not?  must be missing some key comment ( /me slurping tea now - caffine is likely to be needed today :P )
<pitti> hey skaet_
<pitti> skaet_: unity is still being prepared
<skaet_> pitti, good.
<pitti> skaet_: currently wrangling kernel updates, after that I'll check the status of dpkg etc. and start building new imagwes
<cjwatson> just uploading d-i now
<cjwatson> publisher's still on manual for maximal throughput
<skaet_> cjwatson,  sounds good.
<skaet_> pitti,  if unity has any possibility of introducing regressions at this point, we can't afford to include it since we don't have a good set of images at this point.
<didrocks> ok, nux 0.9.30-0ubuntu1, unity seems fine, just looking if we can sneak a distro-patch here
<didrocks> skaet_: we tested it 4 people for 2 hours now
<didrocks> and I'm running the packaged version to ensure there is no crash at all
<didrocks> in any case, unity is dep on latest nux that I just uploaded
<didrocks> so, waiting for a publisher run, and still testing for now
<skaet_> didrocks, what does the nux that was just uploaded do/fix?
<didrocks> skaet_: unity dep on latest nux, it's speed improvement for most of them for the dash
<didrocks> and some crash fixes
<pitti> didrocks: does it change ABI? you only need a strict build dep on nux abi changes
<didrocks> pitti: yeah, nux changes the ABI basically whith each upload, hence the <<
<njpatel> yeah it does
<pitti> ok
<njpatel> hey pitti :)
 * pitti ^5s njpatel
<njpatel> I haven't see a "^5s" before but I'm instantly impressed :)
 * njpatel ^5s pitti back
<skaet_> pitti, are the dpkg issues now resolved?
<pitti> skaet_: should now, yes
 * cjwatson does another debootstrap to confirm
<skaet_> pitti,  what's left before pushing off the image rebuilds?
<pitti> skaet_: FYI, I also cleaned up https://bugs.launchpad.net/ubuntu/natty/+bugs?field.milestone=33573, but not finished yet
<pitti> skaet_: let me check
<pitti> ogra, cjwatson: to confirm: armel preinstalled only depend on new dpkg; non-ubuntu alternates depend on brltty+d-i; non-ubuntu desktops only depend on dpkg; ubuntu desktop/DVD depend on unity
<pitti> ubuntu alternates depend on unity as well, of course
<pitti> IOW, as soon as my wait-for-package dpkg_1.16.0~ubuntu2 finishes, I'll trigger armel preinstalled builds
<cjwatson> pitti: that sounds right to me
<skaet_> do we have nux uploaded but unity not,  or are both not uploaded yet?
<pitti> skaet_: antimony will be busy for a fair while with building the others, FWIW
 * skaet_ nods
<cjwatson> dpkg should be available already
<pitti> ah, w-f-p just finished
<cjwatson> my debootstrap picked it up
<pitti> ubuntu-netbook daily-preinstalled should be ok, as this uses unity-2d
<cjwatson> urk
<pitti> cjwatson: ?
<cjwatson> $ ls -l /chroot/natty-multiarch/var/lib/dpkg/info
<skaet_> ?
<cjwatson> total 20
<cjwatson> -rw-r--r-- 1 root root     0 2011-03-01 13:35 dpkg.list
<cjwatson> drwxr-xr-x 2 root root 20480 2011-03-01 13:35 i386
<didrocks> skaet_: nux is pushed, I'm taking all the time I can get before it's published before pushing unity
<didrocks> skaet_: as it will need nux to be published
<cjwatson> that's still bad :(
<cjwatson> and yes, that's new dpkg
<cjwatson> I wonder if debootstrap needs to be changed
<skaet_> didrocks, but if the abi has changed, will it not break the current unity if we build images without the updated unity?
<didrocks> skaet_: we need either now:
<didrocks> - rebuilding old unity
<didrocks> - take the new one
<didrocks> both option are working, I tested them
<didrocks> options*
<cjwatson> damnit.  yes, debootstrap needs to be changed as well
<skaet_> thanks didrocks.
<didrocks> skaet_: welcome, just doing some final "try to crash it" tests and then uploading unity
<skaet_> cjwatson, pitti - I have an appt I need to leave for now.  Will be back online in about 2 hours.
<cjwatson> testing ...
<cjwatson> sorry, going as fast as I can
<skaet_> cjwatson,  understand completely, no apologies needed.
<skaet_> cjwatson, pitti - don't wait for my return for decisions,  get them building as soon as you're comfortable we'll get usable images.
<cjwatson> ack
<didrocks> ok, unity sounds good, didn't get any crash trying hard for the last 20 minutes in addition to the whole testing we did before
<didrocks> uploading it
<njpatel> \o/
<didrocks> pitti: uploaded
<ogra> hmm, it is supposed to produce good sound ?!?
<cjwatson> hmm, why is SIGPIPE set to SIG_IGN in my terminal?
<cjwatson> not in gnome-terminal though, maybe it's a pterm bug
<didrocks> ogra: heh, full dolby digital :)
<cjwatson> gnome-session bug
<ogra> geez
<ogra> and i never have my speakers attached when using it !
<Daviey> Hello release team... ebtables is a new Recommends of libvirt-bin, showing in component-mismatch.  Is this ok?
<Daviey> Or should we drop it to Suggests... we don't /need/ it.
<Daviey> (this cycle)
<Daviey> jdstrand and I are discussing it
<jdstrand> well, I asked questions. I don't know the policy/rule surrounding that. I just figured if universe wasn't enabled, then a Recommends on a universe package just wouldn't get installed, which would go for cd images
<Daviey> jdstrand, the fear i have with that is inconsistent installations... without a user explicitly setting no recommends.
<jdstrand> that is a valid concern
<cjwatson> universe is enabled by default for CD images; it might create networked vs. not inconsistency
<cjwatson> if you don't need it, though, drop it to Suggests
<Daviey> ack
<jdstrand> interesting
 * jdstrand starts to see the 'why' in all those reports
<jdstrand> :)
<pitti> cjwatson: wrt. your 'urk', was that an unexpected result from your debootstrap test? time to cancel the armel preinstalled builds?
<cjwatson> yes
<cjwatson> sorry, got distracted by SIGPIPE confusion
<pitti> ok, cancelling
<cjwatson> I just uploaded debootstrap 1.0.28ubuntu1
<ogra> hmpf
<cjwatson> sorry, but you don't want to have to clean this up later
<ogra> no, indeed
<cjwatson> publisher running now with all of that
<pitti> ah, was just about to ask, as there's none running ATM
<cjwatson> also with nux on ... whoops, not armel
<pitti> cjwatson: 's ok, we don't need it there
<cjwatson> everything else though
<pitti> armel has unity-2d
<cjwatson> ah ok
<ogra> pitti, err, nope
<ogra> we have both
<pitti> uh?
<ogra> unity needs to be insrtallable
<ogra> and i think it has a versioned dep
<pitti> ogra: I see Recommends: unity-place-files, unity-place-applications
<pitti> but those are separate
<ogra> we have unity and it should be used, but default to 2d because we cant ship the drivers in the images
<pitti> next publisher round then..
<ogra> k
<pitti> ogra: so, I'll wait with building preinstalled until nux and unity are built?
<ogra> well, if its installable you can just build away ... i still need a boot test
<pitti> so, new trigger list; debootstrap -> everything !ubuntu; unity -> all ubuntu images
<ogra> i fear we might need a good bunch of changes in the bootprocess
<charlie-tca> cjwatson: we are going to stop the Xubuntu ppc builds entirely. We don't have any testers or developers that can work them, and users when trying to install have issues.
<cjwatson> charlie-tca: OK :-/  stopped
<charlie-tca> thank you. Just no point in building them only to hear complaints they are broken
<pitti> ogra: if you have nux on the preinstalled, I'm afraid we need to wait for unity, as they strictly depend on each other
<pitti> http://paste.ubuntu.com/573949/ is my current build plan
<pitti> cjwatson: do you want to re-test once debootstrap is published, or did you do that locally already?
<ogra> pitti, well, i get used to it, we couldnt build images since feb 16th due to that
<ogra> its just massively frustrating
<cjwatson> pitti: I did locally
<cjwatson> (also committed upstream)
<pitti> cjwatson: ok, cool; so I'll fire as soon as debootstrap is up
<cjwatson> stuck on scandium again
<pitti> publisher?
<pitti> cjwatson: is there any way to temporarily take scandium out of the publisher mirror poke, just like in cdimage?
<cjwatson> kicked, it's on its way
<cjwatson> don't know, I don't like to touch that
<pitti> ok
<cjwatson> asked #is
<jibel> kubuntu upgrades are failing because of bug 727211
<ubot4> Launchpad bug 727211 in udev (Ubuntu Natty) (and 1 other project) "package udev 166-0ubuntu2 failed to install/upgrade: dpkg-divert: error: mismatch on package (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/727211
<pitti> looking
 * pitti taps feet on debootstrap appearing in antimony's Pacakges.gz (it's already in pool/)
<pitti> hm, that udevadm diversion hasn't changed in years
<pitti> trying in pbuilder..
<pitti> jibel: do you still have the affected machine/vm from above bug?
<jibel> pitti, yes
<pitti> jibel: do you need to tear it down in the next 30 mins? I'ld like to test this locally first
<pitti> jibel: could you please add the output of "dpkg-divert --list" to the bug for now?
<pitti> jibel: and "ls -l /sbin/udevadm*"
<pitti> ok, can't reproduce locally
<jibel> pitti, I can keep it to the release of natty if you wish. http://paste.ubuntu.com/573969/
 * skaet_ back
<pitti> jibel: trying upgrade in conjunction with new dpkg now, the new dpkg migth be the one to blame
<jibel> pitti, I'm retrying ubuntu upgrades. They passed this morning.
<pitti> jibel: I don't think it's specific to u/kubuntu; just sounds like it'd hit the upgrade on some particular package order
<cjwatson>   * Use DPKG_MAINTSCRIPT_PACKAGE environment variable as package name on
<cjwatson>     dpkg-divert when no --package or --local options have been specified.
<cjwatson> although udev seems to use --local explicitly everywhere
<pitti> hah, reproduced
<cjwatson> but that does suggest a possible location for the bug
<pitti> jibel: ok, you can tear down your machine
<jibel> ok, thanks pitti
<cjwatson> the code in dpkg-divert looks wrong to me
<cjwatson> in setpackage:
<cjwatson>         /* If value is NULL we are being called from --local. */
<cjwatson>         opt_pkgname = value;
<cjwatson> and in main:
<cjwatson>         env_pkgname = getenv("DPKG_MAINTSCRIPT_PACKAGE");
<cjwatson>         if (!opt_pkgname && env_pkgname)
<cjwatson>                 setpackage(NULL, env_pkgname);
<cjwatson> I suggest tracking down Guillem on #debian-dpkg@oftc
<cjwatson> I *think* the right answer is to replace !opt_pkgname with opt_pkgname_match_any there
<pitti> I updated the bug with the details; I'll go find him
<slangasek> current policy forbids use of --local for packages
<slangasek> seems dpkg now enforces this
<cjwatson> the changelog does not document that
<cjwatson> it says:
<cjwatson> oh, I quoted it above
<cjwatson> it looks like a dpkg bug regardless of what policy says
<slangasek> right
<cjwatson> I agree udev's use of --local is questionable, but it seems easier to fix dpkg-divert in a hurry
<cjwatson> publisher back on auto
 * slangasek nods
<pitti> finally, debootstrap landed on mirror; /me starts new images
<cjwatson> ow, what a day
<skaet_> is unity on the mirrors, or are we still waiting for it?
<pitti> skaet_: I was waiting for debootstrap, which just got mirrored (hiccup again, had to run anonftpsync myself)
<pitti> skaet_: images are building now, starting with !ubuntu/!edubuntu (since these wait for unity)
<skaet_> sounds like we're still waiting on unity then.
<pitti> unity is building on i386/amd64, depwait on nux on armel
<skaet_> ack.
<pitti> Riddell, ogra: do we want kubuntu daily-preinstalled? they failed to build
<Riddell> if they don't build we don't have a choice surely
<pitti> or only kubuntu-mobile daily-preinstalled? or both?
<pitti> Riddell: no, I mean, are these even expected to build?
<pitti> not quite sure about kubuntu vs. kubuntu-mobile preinstalled
<pitti> these are only for arm, so potentially we might only want mobile?
<Riddell> preferably we'd have both
<pitti> Riddell: do you happen to know where the preinstalled logs are?
 * pitti tries kubuntu-mobile preinstalled in the meantime
<Riddell> I think kubuntu-mobile won't work because of that tasks issue needing launchpad to be updated
<Riddell> not sure where the logs are
<ogra> if they need the recent qt fix Riddell uploaded, thats likely still building
<ogra> Riddell, i dont think they are mirrored, look on the buildds directly
<Riddell> ogra: how would I look on the buildds directly?
<ogra> w3m from antimony
<Riddell> mm hmm
<Riddell>  libreoffice-style-oxygen : Depends: libreoffice-core but it is not installable
<Riddell> tsk
<ogra> ugh
<ogra> why do you install libreoffice on your images at all :)
<cjwatson> what architecture?
<ogra> armel
<pitti> Riddell: ah, right; libreoffice currently FTBFS on armel, hitting a gcc ICE
<ogra> does linaro know about it ?
<pitti> armel images on a3 need to remove LibO, sorry
<ogra> we dont ship it anywhere
<ogra> and Riddell should stop that too :)
<ogra> we have zoho-weboffice in main for armel images
<ogra> will work with kde too
<slangasek> no, libreoffice currently FTBFS on armel, debian/rules was updated with an untested exception that results in a recursive variable definition
<pitti> ah, right; the previous version ICEed, then this variable update was done, which failed, too
<pitti> anyway, won't get fixed in time for armel to build it
<slangasek> right
<pitti> Riddell: so I guess it's down to "temporarily unseed libo for kubuntu{,-mobile} preinstalled, or skip it for a3
<Riddell> yep, removing from seeds
<Riddell> it's not in -mobile but that needs the launchpad update anyway
<pitti> ah, ok
<pitti> slangasek: hm, http://www.debian.org/doc/debian-policy/ap-pkg-diversions.html doesn't actually speak about --local
<slangasek> pitti: hmm, it's in the upgrading checklist, let me see
<pitti> anyway, I'll fix it (--local -> --package udev)
<pitti> sounds more standard anwyay
<slangasek>      You should not use `dpkg-divert' on a file belonging to another
<slangasek>      package without consulting the maintainer of that package first.  When
<cjwatson>      3.9
<cjwatson>           Maintainer scripts must pass `--package' to `dpkg-divert' when
<cjwatson>           creating or removing diversions and must not use `--local'.
<slangasek>      adding or removing diversions, package maintainer scripts must provide
<slangasek>      the `--package' flag to `dpkg-divert' and must not use `--local'.
<slangasek> Policy version 3.9.1, section 3.9
<pitti> h, thanks
<cjwatson> pitti: is there any upgrade handling needed?
<cjwatson> transition, I mean
<pitti> cjwatson: the diversion doesn't exist in an installed system
<pitti> only between unpack (well, preinst) and configure (postinst)
<pitti> so I think not
<cjwatson> that's what I was hoping, but was on the phone so couldn't analyse
<pitti> I'd just like to test/upload it now, so that upgraders get this in time for a3
<cjwatson> yes, it's not vital for images but should be there
<pitti> tested udev upgrade again, works fine now. uploading
<pitti> images are getting built, but cdimage mirror is badly behind.. so not posting yet
<GrueMaster> For arm, we only need the omap and omap4 preinstalled images.  No dove or imx51, and no netboot images (afaik).
<slangasek> Do we know what's happening with mirroring?  Is this scandium still?
<pitti> GrueMaster: hm, the only preinstalled ubuntu image type we have is ubuntu-netbook
<pitti> slangasek: I disabled scandium from cdimage config temporarily, so sync-mirrors stops hanging
<pitti> I think now it's just utterly slow
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20110301.4/
<GrueMaster> yes, that is correct.  But I have email from iso.qa saying images for imx51 & dove were ready.
<pitti> (it's like that for > 20 mins already)
<cjwatson> slangasek: Ng said that it's because security.u.c is getting hammered quite a lot at the moment
<slangasek> pitti: well, there are public mirrors that are out of date also; the python-central and ucf fixes I pushed last night are still not available
<slangasek> cjwatson: ah
<cjwatson> (if I'm paraphrasing correctly)
<GrueMaster> And looking at the tracker, I saw that the netboot images had been enabled.
<cjwatson> they're trying to rebalance
<pitti> slangasek: same reason probably; the world downloading openjdk from -security
<jdstrand> one of the openjdk's has finally made it to -updates
<jdstrand> (lucid)
<pitti> GrueMaster: don't want netboot?
<jdstrand> the karmic one is still finding its way
<ogra> pitti, nice to have
<GrueMaster> No easy way to test it as it doesn't have ta bootable image.
<ogra> not priority or focus
<pitti> GrueMaster: ah, I see -- I accidentally enabled netboot dove/imx51, those should go of course
<GrueMaster> Yes, that was what I was referring to.
<ogra> yeah, dove and imx should go
<GrueMaster> We can have the images, just don't want them showing up as needing testing.
<ogra> omap3/4 would be nice to have but wont be tested
<ogra> (omap3 is helpful for having a downloadable vmlinuz for qemu)
<pitti> GrueMaster: ack
<pitti> publisher stuck again
<pitti> cjwatson: you just killed the ssh archvsync@scandium for that?
<cjwatson> yeah
<pitti> *zap*
<pitti> skaet_: downloaded and installed new unity debs from Launchpad, seems tame
<pitti> (and awesome, too)
<skaet_> whew!!
<ogra> did they build on arm ?
<ogra> :)
<seb128> no
<seb128> not yet rather
<pitti> nux did, published now
<pitti> armel unity is building
<pitti> ogra: FTR, kenvandine just mentioned another libdbusmenu fix which is very important for unity-2d
<pitti> he'll upload now
<pitti> I just don't know whether it's important enough to delay the preinstalled images another hour?
<ogra> pitti, we will likely need to rebuild anyway and have a couple of uploads once we actually *have* an image
<pitti> ogra: ok; so build it ASAP?
<ogra> right, we can still rebuild, but we need something to test first
<ev> anyone have an opinion on whether these will require a tech board decision: https://bugs.launchpad.net/ayatana-design/+bug/723831 https://bugs.launchpad.net/ayatana-design/+bug/723826 ?
<ubot4> Launchpad bug 723831 in ubiquity (Ubuntu) (and 1 other project) "Installer â The option to 'install third-party software' when installing Ubuntu should be selected by default (affects: 1) (heat: 6)" [Critical,New]
<cjwatson> I'm going to be away for about three hours
<charlie-tca> I thought third party software required user approval to install, wouldn't checked by default be wrong?
<cjwatson> Kirsten needs to go out so I have to babysit
<pitti> cjwatson: I'll still be here for 3 hours
<charlie-tca> If it was checked by default, why not just install the software, which is what will be done anyway?
<ev> charlie-tca: not a lawyer, but we might be able to get away with it by changing the button label to "Accept" or something like that.  I've seen such things on other platforms with larger legal teams than ours.
<charlie-tca> I am not a lawyer either, but I thought the whole reason behind it not being checked was to insure the user knew it would be installed
<pitti> ^ I agree
<pitti> we print "free software" on the cover
<ev> the text is still there for them to read; it's still vastly different than just sticking it in the squashfs.
<charlie-tca> If they read it, why would it need to be checked by default? Isn't that being done because they don't read!
<ev> I don't know the motivation, but I suspect it's because they may not realize the benefit of checking the box, a difficult proposition to solve in a paragraph of text.
<ev> And it does benefit the vast majority of users, who greatly outnumber the people who care about software purity.
<ev> whom equally tend to better understand these issues and can uncheck the box.
<slangasek> well, if you're talking about "third party software", isn't that more than just a question of freeness?  Isn't there also a question of quality of integration?
<slangasek> (from the bug description, it's not clear to me what this "third party software" option points to)
<ev> ubuntu-restricted-addons
<slangasek> oh; how is that third-party at all? :)
<ev> so yes, but I suspect (I'm not claiming to have done user research) people will care more about having working java in the browser than they will being able to report bugs about it and get a decent response.
<pitti> ev: oh, I thought this thing was about installing wl and nvidia, not extra codecs
<ev> that's part of it as well
<ev> but the same principle applies
<pitti> ev: the latter are handled quite fine by our codec installer already, with much better UI?
<ev> "rather have a working network card"
<skaet_> ev, charlie-tca, re 723826 - we need to get signoff from legal before this is done, since its not just a convenience thing.   Basically some of the non free licenses combined with the free licenses have redistribution implications.
<pitti> I'd be fine with installing drivers by default (wlan/graphics), as we have always considered them an "enabling pain" to use free software at all
<pitti> but lumping both drivers and u-restricted-extra into one option seems hard to describe in a single sentence indeed
<ev> historical context: the original motivation for the option was Michael Forrest surveying the community to find out what the most common set of actions were immediately after install, and he found that most people went straight for ubuntu-restricted-extras.
<ev> skaet_: absolutely
<slangasek> judging by bug reports it looks like the second most common post-install action is to remove grub2 in favor of grub1 and break their bootloader setup, but I wouldn't recommend we do that by default ;-)
<ev> skaet_: we had long conversations with Amanda and Andrew about this originally, and I suspect we'd pick those back up with this change, if accepted.
<ev> slangasek: heh
<skaet_> ev,  want to have this accepted by amanda and andrew, before the change is made ;)
<ev> why on earth are people switching to grub1?  Is there some Automatix Part Deux out there doing this for them?
<ev> skaet_: of course
<skaet_> anyhow,  have changed the priortity to wishlist,  and put my comments into this bug.  Pull me in, if the discussions start up.
<ev> skaet_: will do
<slangasek> ev: I don't think it's automatix; maybe some bad advice in the forums
<ev> ugh, the forums.
<ev> if I had but one nuclear weapon, I know where I'd point it.
<charlie-tca> +1
<pitti> yay, images trickling in on cdimage
<pitti> mirrors ran out of space, had to free up a bit
 * pitti starts tracker'ing
<pitti> Riddell: kubuntu alternates, desktop posted
<Riddell> ooh!
<pitti> unity appeared now, building images
<pitti> smoser: are you taking care again about the UEC image building and adding to the tracker?
<smoser> well, yes, i will ping someone to do that when we have a build.
<smoser> i cannot build at the moment
<smoser> (or at least could not all morning)
<smoser> is that expected to be resolved ?
<pitti> smoser: what broke?
<smoser> i get archive errors. sudo debootstrap --arch=i386 natty ./out.d http://archive.ubuntu.com/ubuntu
<smoser> will regularly fail
<pitti> weird, my cron.dvd/kubuntu-dvd build just finished, and yet there's no trace of it in www/full/kubuntu/dvd - WTH?
<smoser> right now:
<smoser> W: http://archive.ubuntu.com/ubuntu/dists/natty/main/binary-i386/Packages.gz was corrupt
<pitti> smoser: when did you try last?
<pitti> ah
<pitti> debootstrap was fixed a few hours ago
<smoser> oh? SRU'd to lucid ?
<pitti> no, in natty
<smoser> this is a lucid system building natty
<smoser> just now, trying 'apt-get update' on that system showed 'Failed to fetch' errors.
<pitti> smoser: judging by http://launchpadlibrarian.net/65373191/debootstrap_1.0.28_1.0.28ubuntu1.diff.gz it seems that you need to copy natty's recipe file to your build system
<pitti> smoser: the failed to fetch sound like fallout from the security.u.c/archive.u.c. hammering
<smoser> thats going to fix *download* ?
<pitti> smoser: no, not download, but should fix the debootstrap result for natty
<smoser> i think right now i'm not that far.
<skaet_> pitti, ==== Syncing Kubuntu mirror =====
<skaet_> Tue Mar  1 17:51:50 UTC 2011
<skaet_> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/ftp/Archive-Update-in-Progress-antimony.canonical.com"
<skaet_> antimony.canonical.com is unable to start rsync, lock file exists
<pitti> ah, that'd explain it
<pitti> thanks
<smoser> yeah... an dearlier today, i was lucky and actually got rhough an image build without such a thing. so i dont think thats it.
<pitti> skaet_: re-running cron.dvd
<pitti> skaet_: I just checked cardamom, the livefs is there (which is the expensive part)
<skaet_> pitti, cool.
<skaet_> thanks!
<smoser> the hammering of security.ubuntu.com definitely isnt helping anything, though.
<pitti> unity armel being published nwo
<ogra> \o/
<smoser> yeah, i'm getting corrupt downloads still from the mirrors. :-(
<jdstrand> smoser: that should be resolving itself soon. the offending packages have been pocket copied and so mirrors should start to pick them up
<smoser> so, i'm blocked on that at the moment.
<pitti> finally! no "rebuilding" images any more on http://iso.qa.ubuntu.com/qatracker/
<pitti> xubuntu/ubuntu alternate etc. all posted now
<pitti> ubuntu/edubuntu desktops/dvds to come
<ogra> did you accidentially fire off an arm build ?
<ogra> i just got empty build failure mails
<pitti> I might have earlier, yes; sorry
<ogra> np
<pitti> wait-for-package returned, but I didn't realize it wouldn't wait for all arches
<pitti> have it running wiht -a armel now
<ogra> heh
<ogra> yeah, we are used to that :P
<smoser> pitti, what is wait-for-package ?
<pitti> smoser: it's a script that waits until a particular package version is on antimony's mirror
<smoser> i've a similar [sounding] thing that is buggy right now because out of the N archive.ubuntu.com, only X of them have what i want.
<pitti> smoser: so we can upload a fixed package, then set of a trigger with wait-for-package -a armel unity_3.6.0-0ubuntu1 && buildlive ..
<smoser> yeah.. ihave something very similar, but would rather use yours
<smoser> is that in a bzr repo somewhere ?
<pitti> smoser: the heart of it is just a zgrep -q "$PACKAGE" "$CDIMAGE_ROOT/$FTPDIR/dists/$DIST/$COMPONENT/binary-$ARCH/Packages.gz"
<pitti> smoser: the rest is rather specific to antimony, like the scripts to call anonftpsync, etc.
<smoser> yeah, thats basically what i have. wget + grep.
<smoser> k
<pitti> parent branch: /srv/cdimage.ubuntu.com/bzr/private/cdimage
<pitti> smoser: hm, I'm sure cdimage is in some branch on LP, just not sure where exatly
<pitti> kubuntu-desktop_1.217 just hit, building kubuntu preinstalled
<smoser> dont worry about it, pitti thanks.
<pitti> ok, I did all I can for now, now I need to wait for the machinery; AFK for a bit for dinner
<stgraber> skaet_: I'm working on a new ltsp package at the moment, that'll be a new upstream release containing only bugfixes. It'll fix LTSP for Edubuntu and possibly for Ubuntu Alternate (assuming it's also broken for alternate at the moment). Is it fine for me to upload that ?
<stgraber> skaet_: I don't think we need it for alpha-3 but it'd definitely be a nice to have if we have to rebuild for whatever reason
<stgraber> (the issue is caused by the new ssh introducing ecdsa keys which didn't exist before. LTSP currently doesn't copy them and so login doesn't work, the new package will fix that)
<skaet_> stgraber,  if its not necessary for A3,  lets hold off until we know we're going to need a rebuild.  We may have some fragile other parts, and we probably need to minimize changes for a bit.
<stgraber> ok
<skaet_> stgraber, is there a bug number/s for tracking the LTSP fixes?
 * stgraber checks
 * skaet_ wants to dig into it a bit more and understand implications ( and what should be documented, etc. )
<stgraber> nope, filing one now
<skaet_> :)  okie,  copy release team on it,  since its going to be a FFe, since we're pulling in the new upstream package (even though it should be mostly bug fixes... :/ )
<stgraber> oh, do we need FFe now for bugfix only upstream releases ? (as in, I'm the upstream :))
<stgraber> anyway, bug 727339
<ubot4> Launchpad bug 727339 in ltsp (Ubuntu Natty) (and 1 other project) "LTSP on natty doesn't support ecdsa ssh key. Login impossible (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/727339
<dbarth__> skaet_: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/709461 should provide a clearer description now
<ubot4> Launchpad bug 709461 in unity (Ubuntu Natty) (and 4 other projects) "Application windows can sometimes fail to display and will mask regions of the screen (affects: 16) (dups: 2) (heat: 108)" [Undecided,In progress]
<skaet_> stgraber, :) thanks for the bug number.  Sometimes the line between bug fixes and features is kinda blury.   https://wiki.ubuntu.com/FreezeExceptionProcess  calls for a bug in any case.  From the description, it sounds like you are adding the a capability to handle something that wasn't there before - so is it a new feature or bug fix, I could argue both ways? :P   But its a good thing to add and a bug is asked fo
<skaet_> r in either case, just question of timing before it will go in. ;)
<stgraber> hmm, looks like we also have a bug in tftp-hpa affecting ltsp ...
 * stgraber tries to reproduce
<stgraber> skaet_: bug 727356 (Chuck Short is looking at it)
<ubot4> Launchpad bug 727356 in tftp-hpa (Ubuntu) "tftp-hpa crashes on natty (buffer overflow) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727356
<skaet_> stgraber, thanks for letting me know.
 * pitti feeds the hamsters to build faster
<pitti> Riddell: Kubuntu DVDs posted, FYI
<pitti> Riddell: kubuntu preinstalled took an hour now, so I guess they succeeded
<ogra> just wait another 30min and you will know ;)
<pitti> skaet_: do you know whether we post the chinese edition dailies in the tracker?
<pitti> it just finished building
<pitti> *cry*, ubuntu desktops still oversized; oddly enough they come out as the same size as this morning, althuogh I already removed a langpack
<skaet_> pitti, re: chinese editions haven't gone in the tracker so far.  Do you know who's lined up to test them?
<pitti> skaet_: I don't know
<skaet_> pitti, ok,  will dig a bit and see if I can figure out what needs to happen to them.
<marjo_> skaet_, pitti: no testers, no image!
 * ogra guesses chinese people 
<skaet_> pitti,  will let you focus on the oversized desktops...
<skaet_> marjo_,  ack,  need to find out why they were added to the build list this time around...
 * skaet_ goes off to talk to the OEM folk...
<pitti> skaet_: they are always built
<pitti> skaet_: we just haven't added them to the iso tracker so far
<pitti> http://cdimage.ubuntu.com/daily-live/20110301.1/ ready for testing, but is oversized
<marjo_> pitti: we don't want to add images to tracker unless there are committed testers for them
<skaet_> pitti,   as part of dailies, but not part of release manifest.  ;)
<pitti> so I won't add to tracker
<skaet_> pitti, are we going to be able to get one out today that isn't oversized?
<pitti> skaet_: your today, yes; my today, probably not
<pitti> or just barely
<pitti> skaet_: I synced upower, which just adds a new binary (GIR), and has no other code changes
<pitti> I need a harmless main uplaod to update the Taks headers for my dropped langpack
<pitti> (i. e. I dropped another one)
<pitti> need to investigate what caused the CD to baloon
<pitti> but that'll do for now
<pitti> skaet_: so, we'll ideally get a CD in about 2 hours
<skaet_> pitti,  thanks ok,  yeah no point in starting to test then.
<pitti> unfortunatley the CD builds need a lot of handholding today
<pitti> at least I got all builds in my "plan.txt" queued, and most of them done now
<skaet_> pitti,  thanks for doing the hand and finessing.   I think ogra's suggestion that we allow 2 weeks between FF and a release makes sense for next time.
<skaet_> s/hand/handholding/
<ogra> yeah, to have some time for settling the newly introduced FF breakage
<pitti> skaet_: we'd just get more FFEs..
<pitti> but the dpkg one hit quite hard, yes
<pitti> but actually the handholding mostly comes from the mirror breakage
<pitti> ogra, Riddell: wohoo! http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110301/
<skaet_> \o/,    will add the pompoms when we know it works ;)
<pitti> tracker'ed
<pitti> I added it as "kubuntu netbook" (it's what the tracker offers), hope that's right
 * skaet_ believes so
<jibel> skaet_, re: chinese edition, chrisxia is the one you should ask. they have a tester if needed.
 * ogra doesnt care about kubuntu to be honest
<skaet_> jibel, thanks for the pointer.   will work with management to determine if this is going to be on the manifest/tracker or not in the future (and if it is, can they sign up to the  2 day testing cycle ;) )
 * ogra wonders if there will be any trace of armel images at some point before A3 :P
<pitti> ogra: kubuntu is published, ubuntu building
<ogra> k
<ogra> finally
<ogra> did kens fix make it in ?
<ogra> now that it took several hours anyway
<pitti> I suppose yes
<ogra> great
<jcastro> hi, I'd like to make sure that the unity bug filing docs are linked to from release notes or the announcement or whatever: https://wiki.ubuntu.com/Unity/FilingBugs
<pitti> Ubuntu DVD posted (http://cdimage.ubuntu.com/dvd/20110301/)
<pitti> ogra: ubuntu preinstalled fs builds just succeeded, running cron.daily-preinstalled now
<pitti> whee, after what feels like 20 hours stuff is finally coming together
 * ogra hugs pitti
<ogra> what do you mean with "feels"
<ogra> :)
<ogra> didnt we start yesterday afternoon with preparations
<pitti> Heghlu'meH QaQ jajvam
<ogra> hookah hey
<mvo> I have some fixes in software-center, is that still appropriate for a3?
<pitti> mvo: you can upload, but no guarantees that they'll make it into the images
<pitti> ogra: Quapla'! omap/omap4 .img.gz in antimony's tree now, just need to catch up rsyncing
<ogra> yep, waiting for them to show up publically :)
<pitti> libdbusmenu-glib3 0.3.99-0ubuntu4
<pitti> ogra: ^ so it missed ubuntu5 :/
<ogra> well, a build just takes 90min
<pitti> (as we discussed earlier on)
<pitti> but at least there are images now
<ogra> yeah
<mvo> pitti: thanks!
<skaet_> jcastro,  ack.   Will put a link into the TechOverview.
<jcastro> thanks!
<cjwatson> back
<cjwatson> I'm going to continue working on bug 723482, unless somebody has something better for me to do
<pitti> cjwatson: wb
<ubot4> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22 (affects: 14) (heat: 78)" [High,Confirmed] https://launchpad.net/bugs/723482
<pitti> cjwatson: quick status: cdimage mirror syncs have been resolved (was -ENOSPC), except for scandium
<pitti> cjwatson: most images are ready now, and on the tracker
<pitti> ogra: ubuntu omap preinstalled added to tracker, ther enow
<pitti> cjwatson: currently building edubuntu DVD, still need to wait a bit for publisher to rebuild ubuntu CDs for oversizedness
<jibel> pitti, can I test Ubuntu 20110301.2 ? I get an error with kubuntu i386: dpkg-query: error: failed to open package info file '/target/var/lib/dpkg/status' for reading: No such file or directory which doesn't make sense
<pitti> skaet_: I'm about to fall off my chair; can you add the edubuntu DVD once it finished building? should be 30 mins to an hour; should appear at http://cdimage.ubuntu.com/edubuntu/dvd/
<pitti> jibel: you can test the current ubuntu iso, but it's oversized
<skaet_> pitti,  sure,  can do.
<pitti> jibel: eww
<cjwatson> jibel: what's the context of that error?
<pitti> jibel: is that alternate?
<jibel> kubuntu desktop i386 on VBox, dialog box at the end of the installation. I can post the syslog
<cjwatson> bah.  it'll be ages before I've synced it
<jibel> that's just after "Removing Ubiquity ..."
<jibel> well there are more errors higher in the logs related to update-alternatives
<cjwatson> /var/lib/dpkg/status hasn't moved with multiarch though, AFAIK
<jibel> :q
<jibel> sorry wrong keyboard
<pitti> cjwatson: I did an upower upload (no code changes, just building an extra gir deb) about an hour ago, which shuold have updated the Task: headers; apparently I need a second publisher run now, to finalize it
<pitti> cjwatson: would you be able to re-run ubuntu desktops in about an hour, after language-pack-pt finally loses its ubuntu-live task header on amd64?
<cjwatson> yeah, I guess so
<pitti> or are you going to bed soon, too?
<cjwatson> no
<pitti> I'm just feeling tired enough, I think I'll be more useful if I get up early tomorrow
<cjwatson> language-pack-pt/amd64  Task  ubuntu-dvd-live
<cjwatson> language-pack-pt/amd64  Task  kubuntu-dvd-live
<cjwatson> language-pack-pt/amd64  Task  kubuntu-full
<cjwatson> language-pack-pt/amd64  Task  edubuntu-dvd-live
<cjwatson> that looks OK
<pitti> cjwatson: hm, just did an apt-get update, and I still have it
<cjwatson> (grep language-pack-pt/amd64 /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.natty.main on cocoplum)
<pitti> cjwatson: where do you see that?
<pitti> ah
<cjwatson> that's the output of cron.germinate; it may not be committed yet
<cjwatson> FYI, the upower upload is not what causes cron.germinate to be rerun
<cjwatson> it's what causes the output of cron.germinate to be applied to the archive
<pitti> ubuntu/dists/natty/main/binary-amd64/Packages.gz on cocoplum still has the header, though
<pitti> cjwatson: I remember that you said it needs two publisher runs?
<pitti> cjwatson: ah, so it should have been uploaded in this publisher run, not in the previous?
<cjwatson> hard to tell exact timings
<cjwatson> no, probably not, I think your seed change was after the cron.germinate run in the publisher run immediately before your upower sync
<cjwatson> so your upower sync was too soon to be effective
<cjwatson> however, the publisher had work to do in natty/amd64 this cycle anyway, so that doesn't matter
<cjwatson> all it needs is for the pocket to be dirty for some reason
<pitti> ok, thanks for taking over
 * pitti waves good night
<ogra> pitti, night and thanks for everything !
<marjo_> pitti: thx!
<skaet_> pitti,  thanks and sleep well.
<jibel> cjwatson, bug 727427
<ubot4> Launchpad bug 727427 in ubiquity (Ubuntu) "dpkg-query: error: failed to open package info file '/target/var/lib/dpkg/status' for reading: no such file or directory at the end of kubuntu desktop installation (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727427
<cjwatson> ev: ^- don't suppose you're still around?
<skaet_> slangasek: ^ - any insight?
<slangasek> mmh - as cjwatson said, it's not supposed to have moved with multiarch
<skaet_> ack.
<cjwatson> I'm syncing it, but ETA at least an hour even for the sync to finish, so if somebody could investigate first that would likely be better
<cjwatson> I've only been working with server images lately :-/
<slangasek> can someone tell the exact command that's being run to give this error?
<slangasek> I'm in a similar situation as cjwatson as far as being able to test here
<cjwatson> from the context, it's a python-apt package removal
<cjwatson> Mar  1 20:53:40 ubuntu ubiquity: update-alternatives: error:
<cjwatson> Mar  1 20:53:40 ubuntu ubiquity: scan of /target/var/lib/dpkg/alternatives failed: No such file or directory
<cjwatson> I wonder if this is a "process being run chrooted when we thought it wasn't" problem
<cjwatson> or chroot-suitable configuration leaking through to a chrooted command, that kind of thing
<cjwatson> for all I know it may have nothing to do with dpkg multiarch, and be related to an apt change or something
<slangasek> very strange
<cjwatson> as far as I know, the dpkg in question should be running outside the chroot, with --root=
 * slangasek nods
<cjwatson>   * Propagate --admindir to programs run from maintainer scritpts.
<cjwatson>     Closes: #97076
<cjwatson> it doesn't have anything to do with that, does it?
<slangasek> checking
<slangasek> looks probable
<slangasek> hmm, but does dpkg call chroot for --root?
<cjwatson> for maintainer scripts, yes
<cjwatson> so I think it needs to strip the value of --root off the front of the DPKG_ADMINDIR it sets
<cjwatson> or something simiar
<cjwatson> *similar
 * slangasek nods
<cjwatson> basically undo what setroot does
<cjwatson>   m_asprintf(&p, "%s%s", value, ADMINDIR);
<cjwatson>   admindir= p;
<cjwatson> should be easily testable in isolation
<slangasek> right
<cjwatson> so that will clearly hose all desktop images
<cjwatson> I don't think we use dpkg --root in d-i
<cjwatson> it would seem unlikely given the environment
<slangasek> cjwatson: would you do the stripping in preexecscript() right before the chroot, then?
<cjwatson> no, I'd do it where it sets DPKG_ADMINDIR
<cjwatson> hm, would I
<slangasek> well, are there other subprocesses that will care about this besides maintainer scripts, is what I wonder
<cjwatson> I suppose doing that would break dpkg --root= -l
<cjwatson> since that execs dpkg-query
<cjwatson> doing it in preexecscript feels inelegant, but it would work as a stopgap at least
<slangasek> completely untested so far, buT: http://paste.ubuntu.com/574179/
<slangasek> hmmm, building from bzr gives me a strange build failure
 * slangasek grabs the source packgae
<cjwatson> looks nominally OK
<slangasek> right, builds fine from source package; something out of sync maybe?  will check later
<charlie-tca> The wording in the ubiquity installer is now unclear.
<charlie-tca> the page "Install Ubuntu alongside them" does not explain what "them" is
<slangasek> cjwatson: checks out in a test here
<slangasek> shall I upload?
<skaet_> charlie-tca, please open a bug and we'll deal with it there.
<charlie-tca> okay
 * slangasek uploads
<skaet_> hmm,  Thanks to who ever beat me to the edubuntu DVDs - they're on the ISO tracker now.
<slangasek> skaet_: but I guess they'll be uninstallable and need respun like the others, so I don't know if it's worth having people test?
<skaet_> slangasek, was wondering if that might be the case.   ok,  marking them for rebuild.
<slangasek> anything that uses ubiquity is broken and needs respun
<ogra> slangasek, your change onmly affects /target ?
<slangasek> it affects installing with ubiquity (due to use of dpkg --root=)
<ogra> GrueMaster just reported a hang in oem-config on the preinstalled images
<ogra> hmm, does it use that on oem-config mode ?
<slangasek> I can't think of any reason oem-config would be affected
<slangasek> and it doesn't present as a hang, anyway
<ogra> right
<slangasek> so sounds like you've got a separate bug
<GrueMaster> Yep.  Filing a bug report now.
<ogra> yeah, thats what i thought
<jibel> server images fail to upgrade, something to do with mysql being blocked by apparmor :(
<jdstrand> jibel: is there a bug?
<jibel> idk, I've just got the hang here.
<jdstrand> jibel: what is the apparmor denied message in the logs?
<slangasek> ogra, GrueMaster: according to the manifests, the preinstalled images carry a full copy of ubiquity; do you know why?
<ogra> oem-config depends on it
<ogra> since oem-config == ubiquity nowadays
<GrueMaster> Submitting bug report now.
<ogra> it runs the same ubiquity but supresses modules
<GrueMaster> Bug #727468
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu) "oem-config crashed during install on armel (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727468
<slangasek> ogra: ok - not quite how I had thought that was structured, but makes sense
<jibel> jdstrand, http://pastebin.ubuntu.com/574195/
<ogra> it doesnt run tasksel and the partitioner
<ogra> but beyond that they are the same
<slangasek> ogra: "the same" - it doesn't need to copy packages either, does it?
<slangasek> to a different install partition
<ogra> Mar 1 21:54:27 acorn ubiquity: grep:
<ogra> Mar 1 21:54:27 acorn ubiquity: /target/etc/apt/sources.list
<ogra> Mar 1 21:54:27 acorn ubiquity: : No such file or directory
<slangasek> that's what's currently broken in dpkg - trying to confirm whether it affects preinstalled
<ogra> it shouldnt use /target at all
<Riddell> ev, cjwatson: any thoughts on bug 726581 ? it's been confirmed by someone else now too
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 3) (dups: 1) (heat: 3510)" [Undecided,New] https://launchpad.net/bugs/726581
<slangasek> ogra: ok, so that's probably a ubiquity bug
<ogra> if it would chroot in an oem install i would expect it to just use /
<ogra> it doesnt seem to be the cause of the trasceback though
<jdstrand> jibel: please file a bug and assign it to me. is this required for alpha3?
<GrueMaster> Are there any other logs I can include in my bug report that would help?  I'm not seeing anything in most of the other reports, but if there is a hidden report somewhere...
<ogra> the syslog is already quite descriptive
<slangasek> can someone score up dpkg on powerpc, or should we run without it?
<slangasek> n/m... only two ppc builders, one has a kernel, the other has eclipse
<slangasek> skaet_, cjwatson: triggers set to rebuild livecds + dvds with dpkg 1.16.0~ubuntu3
<jibel> jdstrand, bug 727478
<ubot4> Launchpad bug 727478 in mysql-5.1 (Ubuntu) "mysql upgrade hang at 'installing new version of config file /etc/init/mysql.conf' during upgrade from 10.10 to 11.04 (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/727478
<doko_> slangasek: done
<jibel> jdstrand, I'll keep the testing env if you need more info.
<slangasek> doko_: ta
<jdstrand> jibel: is this a stock configuration?
<jdstrand> jibel: it seems odd that mysql needs a raw ip socket
<jibel> jdstrand, yes, fresh 10.10 LAMP + ssh, dist-upgrade, reboot, do-release-upgrade.
<jdstrand> jibel: is this required for alpha3?
<jdstrand> jibel: or is friday good enough?
<jibel> jdstrand, if we can ensure that its mysql and verify the upgrade without it I think that's good enough for a3. skaet_ what do you think ?
<ogra> slangasek, hmm, looking at line 130 in scripts/plugininstall.py it calls some debconf output, i wonder if it
<ogra> perhaps doesnt find the template
<jdstrand> jibel: can you add the following to /etc/apparmor.d/usr.sbin.mysqld:
<ogra> self.db.progress('START', self.start, self.end, 'ubiquity/install/title')
<jdstrand>   network stream,
<jdstrand> jibel: then run 'sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld'
<jdstrand> jibel: then try 'apt-get -f install'
<jdstrand> jibel: I'm assuming that your test environment failed in such a way that apt-get -f install will sufficiently test the fix
<jdstrand> jibel: and to confirm, you saw this on both i386 and amd64 upgrades?
<skaet_> bug 727288 just came across the list.   Is there any chance it could be a lingering effect from last night's instability?  worth holding off on debugging until we can get a retest with new dpkg/ubiquity?
<ubot4> Launchpad bug 727288 in ubiquity (Ubuntu) (and 1 other project) "installer crashes with InstallStepError: HwDetect failed with code 1 on Dell XPS 1340 (affects: 9) (dups: 1) (heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/727288
<ogra> skaet_, bug 727468 is definitely a blocker for armel
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/727468
<skaet_> ogra,  ack.  thanks for flagging explicitly.
<jibel> jdstrand, I get lot of errors like debconf/config.dat is locked probably because the upgrade has been interrupted abruptly. I'll apply the config change and then upgrade but that will take more time.
<slangasek> cjwatson: 727288> should we be holding off on respins for a ubiquity rebuild?
<cjwatson> skaet_: 727288 has nothing to do with last night's work.  I've just committed a fix
<skaet_> cjwatson,  great.  thanks.
<cjwatson> ogra: I have no idea what's going on with 727468 other than to say that it's probably got nothing to do with the message about /target/etc/apt/sources.list, and that that message essentially means that the underlying debconf confmodule fell over
<cjwatson> ogra: if you want that fixed for alpha-3, you guys will have to do it
<ogra> yes, its clear that the sources.list has nothing to do with it
<cjwatson> ogra: you should use --debug to get debconf debug output
<ogra> i just dont understand why the confmodule would fall over
<cjwatson> (oem-config-debug as a boot parameter)
<ogra> yep
<GrueMaster> Ok will do.
<cjwatson> sorry, debug-oem-config
<cjwatson> not oem-config-debug
<cjwatson> (maybe I should make both work ...)
<cjwatson> I'm going to upload ubiquity 2.5.22 nowish
 * slangasek cancels his trigger and sets one for ubiquity instead
<jdstrand> jibel: this was on both i386 and amd64?
<jibel> jdstrand, yes
 * jdstrand is trying a do-release-upgrade after install LAMP via tasksel to try to reproduce
<jibel> jdstrand, same problem with the configuration change.
<jdstrand> that... is... odd...
<jdstrand> jibel: same as in 'same end result' or same apparmor denial?
<jibel> jdstrand, same end result and same apparmor denial. How do I verify that the rule is active ?
<jdstrand> jibel: verify that 'network stream,' is in /etc/apparmor.d/usr.sbin.mysqld, then compare the timestaps on /etc/apparmor.d/cache/usr.sbin.mysqld and /etc/apparmor.d/usr.sbin.mysqld
<jdstrand> jibel: the cache should be newer (or possibly the same minute if using ls -l). if the cache is older, it certainly wasn't applied
<jibel> jdstrand, I confirm that the cache is 11 minutes newer and the rule is there.
<jdstrand> jibel: how did you prepare the VM prior to do-release-upgrade?
<jdstrand> jibel: I can confirm it here with up-to-date maverick
<jibel> jdstrand, prepare ? That's a virtualbox ose 4.0.4, I attached a 10.10 ISO downloaded from releases.u.c, selected install ubuntu server, ran the install with LAMP + ssh, setup my local proxy, rebooted once, login with the user I added during the install, applied the updates with apt-get update && apt-get dis-upgrade, then rebooted, login again and entered do-release-upgrade on the command prompt.
<jibel> to all the questions about configuration files, I replied 'install the maintainer version'
<jdstrand> jibel: k. I was curious if the VM was up to date prior to upgrading
<jdstrand> and I see it was
<jdstrand> I can confirm here, so I'll take a look
<jibel> jdstrand, nice, thanks for your help. Heading to bed then. see you
#ubuntu-release 2011-03-02
<ev> Riddell: what partitioning method did you choose in bug 726581?
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 3) (dups: 1) (heat: 3510)" [Undecided,New] https://launchpad.net/bugs/726581
<jdstrand> skaet_: re bug #727478. it is actually worse than I initially thought
<ubot4> Launchpad bug 727478 in mysql-5.1 (Ubuntu Natty) (and 3 other projects) "mysql upgrade hang at 'installing new version of config file /etc/init/mysql.conf' during upgrade from 10.10 to 11.04 (affects: 1) (heat: 6)" [High,Invalid] https://launchpad.net/bugs/727478
<jdstrand> skaet_: it is an apparmor userspace built on natty's kernel on a maverick kernel issue
<jdstrand> skaet_: it shouldn't be horribly hard to fix-- jjohansen is looking at a fix this evening
<jdstrand> skaet_: mysql users upgrading will get bit by the bug and the upgrade will interminably hang due to how the upstart job is written
<skaet_> jstrand:  thanks,  not quite sure I'm parsing "on natty's kernel on a maverick kernel" - can you expand a bit.
<jdstrand> skaet_: other apparmor consumers will be affected as well, but the severit is unknown atm
<jdstrand> skaet_: after reboot all is fine
<cjwatson> (apparmor userspace built on natty's kernel) on a maverick kernel
<cjwatson> bracket it thus and it makes more sense
<jdstrand> yes
<skaet_> yup that helps.
<jdstrand> skaet_: now, this only affects upgrades, not installs
<skaet_> jdstrand, so there is a workaround to do a reboot?  does that work for mysql users or just the other cases.
<jdstrand> skaet_: but an upload of apparmor means it is on all the CDs
<jdstrand> skaet_: well, rebooting isn't a workaround, it is just things are correct then
<jdstrand> skaet_: mysql users have to stop the mysql upgrade in some manner and revocer from a partial do-release-upgrade
<jdstrand> skaet_: it is not pretty
<skaet_> jdstrand: agreed.
<jdstrand> skaet_: so the question is timing. people are working on a fix, and we should hopefully have something tonight
<slangasek> jdstrand: it's generally ok to have newer packages in the archive than are on CDs at the time of alpha release; I don't think that should block you from fixing a critical upgrade bug
<slangasek> (assuming skaet_ agrees)
<jdstrand> skaet_: the question is do you want it on the CDs, if so when is the deadline
<jdstrand> skaet_: or what slangasek said, which is we upload before alpha3 is announced so upgraders can get it
<jdstrand> I'm partial to the second option
<skaet_> jdstrand, slangasek,  sorry for the slowness of response,  thinking
<skaet_> jdstrand, slangasek,  yeah,  lets keep the image building and have this uploaded to the archive, and document it in the release notes that its a known issue.  Not good, but I think we're running out of options.
<jdstrand> skaet_: what time do you plan to announce alpha3?
<jdstrand> skaet_: I can just make sure that it is in there before then, so any inspired 10.10 users will get it
<skaet_> jdstrand,  alpha3 will be announced on Thursday afternoon, evening, after we know we have reasonable coverage from the QA team.
<jdstrand> skaet_: cool, thanks. I'll pass that along and keep you updated
<skaet_> thanks jdstrand.
<slangasek> waiting for this ubiquity build really makes me want qemu armel builders
<skaet_> slangasek,  have the rebuilds triggered yet with that last upload?
<skaet_> heh
<slangasek> nope, still waiting :)
<skaet_> ok,  I'm going to break for dinner,  will be back in an hour or so.
 * skaet_ crossing fingers ready we have a good set when jibel wakes up. 
<cjwatson> hmm, I should have started building CDs a while back, per pitti's comment
<cjwatson> oh, but slangasek has them queued
<cjwatson> you know, I think I need coffee
<cjwatson> bug 723482 is kicking my ass
<ubot4> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22 (affects: 14) (heat: 78)" [High,Confirmed] https://launchpad.net/bugs/723482
<slangasek> :/
 * slangasek taps his fingers on the desk and stares intently at the I/O bound armel builder
<slangasek> I could put that .deb together faster by hand with a magnet and a pottery wheel
<cjwatson> oh
<cjwatson> of course
<cjwatson> mounted MOUNTPOINT=/usr and mounted MOUNTPOINT=/var => the first mounted event waits forever for alsa-restore to come back => deadlock
 * cjwatson stupid
<slangasek> doh
<slangasek> is that in a package?
<slangasek> 'cause neither of those are supposed to appear in shipping upstart jobs, you don't get any mounted events at all for paths that aren't mount points
<cjwatson> alsa-utils
<slangasek> sigh
<cjwatson> it should just be 'filesystem'
<slangasek> yep
<cjwatson> I'll fix it up in a bit
<cjwatson> slangasek: in fact, the whole thing is redundant since it's also 'start on runlevel [2345]'
<slangasek> cute
<cjwatson> and runlevel [2345] is always after filesystem ...
<slangasek> there we go, ubiquity/armel built, publisher going
<GrueMaster> slangasek: is that a fix for bug 727468?
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/727468
<slangasek> no
<GrueMaster> so, what's the point of respinning?
<slangasek> I'm respinning desktop cds
<slangasek> oh, there aren't actually any arm desktop cds building these days, are there
<slangasek> so I guess I didn't need to wait
<GrueMaster> Oh.  But I thought you were waiting for ubiquity to publish.
<cjwatson> other architectures
<GrueMaster> Well, we will need to push another update and respin anyways if we can't get this fixed.
<slangasek> I would have thought you need a respin if you /do/ get it fixed?
 * cjwatson doesn't have the faintest idea what's going on from the debug log in 727468, I'm afraid
<cjwatson> I expect that somebody with some degree of installer experience needs to debug it locally
<GrueMaster> I'll light a fire under ncommander and get him on it.
<cjwatson> thanks
<skaet_> slangasek, will you be publishing the images this evening as they emerge from the builder or do you need my help?
<slangasek> sure, I'm around and can publish them to the tracker
<skaet_> slangasek,  thanks!   will focus on the Tech Overview, and then get some sleep
 * skaet_ expects its going to be a late couple of next nights.
<slangasek> skaet_: ok :)
<slangasek> ubuntu, kubuntu desktop CDs re-posted
 * highvoltage wonders if some of those errors in LP: #727468 are related to bug 723357
<ubot4> Launchpad bug 723357 in casper (Ubuntu) "ISO filesystem not mounted properly on Live USB disks (affects: 1) (heat: 503)" [Undecided,New] https://launchpad.net/bugs/723357
<slangasek> cjwatson: ah, I see you already knew about bug #727603 still being an issue... ran across it this evening because it was still causing trouble for smoser's UEC builds, and I'm wondering if it could be related to the oem-config troubles
<ubot4> Launchpad bug 727603 in dpkg (Ubuntu Natty) (and 1 other project) "/var/lib/dpkg/info/$arch still a directory on new installs (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/727603
<slangasek> don't see anything in oem-config that would account for it
<slangasek> GrueMaster, ogra: ^^ a test for this would be to boot a preinstalled image, pull up a root terminal, and run 'mv /var/lib/dpkg/info/armel/* /var/lib/dpkg/info/ && rmdir /var/lib/dpkg/info/armel && ln -sf . /var/lib/dpkg/info/armel'; if that solves bug #727468, we probably want another dpkg upload to fix this
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/727468
<GrueMaster> slangasek: Thanks, I'll try that shortly.  Currently looking at other possible angles.
<GrueMaster> slangasek: btw:  I tried reproducing this on x86 in a vm.  Unfortunately after doing an oem install and reboot, oem-config is gone and there is nothing to indicate that the user needs to configure the system.
<pitti> Good morning
<pitti> ah, so the new dpkg required rebuilding all the desktops?
<pitti> but not the alternates?
<GrueMaster> slangasek: Your proposed solution is already there. ls -l /var/lib/dpkg/info/armel
<GrueMaster> lrwxrwxrwx 1 root root 1 2011-03-01 11:26 armel -> .
<GrueMaster> So that can't be it.
<slangasek> pitti: yes, the alternates don't call dpkg --root
<slangasek> GrueMaster: ok, thanks for checking
<slangasek> I think that means I'm off the hook as far as having broken the preinstalled images is concerned
<slangasek> don't see how it can be multiarch's doing
<GrueMaster> Awww.  We'll still think of you.  :P
<pitti> slangasek: do you think bug 727603 affects the desktops/alternates/DVDs as well? (they mostly seem to work, but there might be suble breakage)
<ubot4> Launchpad bug 727603 in dpkg (Ubuntu Natty) (and 1 other project) "/var/lib/dpkg/info/$arch still a directory on new installs (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/727603
<slangasek> pitti: it definitely /affects/ some set of these, but the last image it was known to /break/, the uec image, is now sorted
<slangasek> I think this is just something to clean up post alpha
<slangasek> unless someone shows some other way that it's breaking us, I'd rather we take our time now and fix it the right way once the dpkg upstream changes are finalized, since it seems the subdirectory is going away as quickly as it came
<pitti> slangasek: i. e. replace it with a symlink for the 'native' arch, and leave the other $arch directories alone?
<slangasek> if there are any other $arch directories
<slangasek> nobody should be doing that yet, so yeah, they get to keep both pieces on upgrade
<pitti> .. which will only be the case if people actually play with multiarch
<pitti> i. e. flashplugin-installer and friends still use the old method with ia32-libs, so it shouldn't hit a lot of people
<slangasek> it shouldn't hit anyone who doesn't have my phone number :)
<pitti> slangasek: can it happen that dpkg actually puts any files into $arch/?
<pitti> lol
<slangasek> only for $arch == $native
<pitti> I just wonder if we can end up in a situation where both info/ and info/$arch/ have files for the same package
<slangasek> right now it puts *all* files there, and $arch/ is just conveniently a symlink in the common case
<slangasek> dpkg is writing everything to the info/$arch/ path currently
<slangasek> so, not too painful to unwind
 * pitti checks his desktop install from yesterday
<pitti> right, info/ just has dpkg.list and arch/
<pitti> I take it dpkg.list is a leftover from debootstrap
<slangasek> yep
<slangasek> anyway, sleep for me
<pitti> slangasek: thanks for the heads-up, sleep well!
<slangasek> here's hoping for smooth testing
<slangasek> g'night :)
<pitti> slangasek: the live system seems alright, though
<pitti> GrueMaster: do you know what's happening with the "rebuilding" arm images? what are these waiting for?
<GrueMaster> A fix.
<GrueMaster> Currently we die in oem-config, making the images absolutely useless.
<pitti> GrueMaster: #727603 ?
<GrueMaster> NCommander and I are currently debugging, but we wil be hading to bed soon (midnight here).
<GrueMaster> Bug #727468
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/727468
<pitti> GrueMaster: that exception rings a bell
<GrueMaster> 727603 doesn't appear to affect preinstalled.
<pitti> the exception in that log is bug 711225
<ubot4> Launchpad bug 711225 in python2.7 (Ubuntu Natty) (and 1 other project) "subprocess.Popen() crashed with TypeError in _cleanup(): an integer is required (affects: 3) (heat: 28)" [Medium,Confirmed] https://launchpad.net/bugs/711225
<GrueMaster> I checked and /var/lib/dpkg/info/armel is a symlink to .
<pitti> whoops, sorry, no; ignore me
<GrueMaster> ignored.  :P
<Riddell> ev: for bug 726581 I did use whole disk
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 3) (dups: 1) (heat: 20)" [Undecided,Incomplete] https://launchpad.net/bugs/726581
<ev> Riddell: hm, there goes that theory.  Okay, full debug logs would be greatly appreciated then.
<Riddell> ev: running ubiquity with --debug?
<ev> correct
<ogra> hmm,  doesnt look like GrueMaster and NCommander made any progress at all on bug 727468
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/727468
<ogra> not even a syslog for the --debug run
<ogra> ev, any idea about that ?
<ev> looking
<cjwatson> GrueMaster: what version of debootstrap are you using to build your preinstalled images?
<pitti> cjwatson: good morning
<pitti> cjwatson: I figure we'll need to backport the $arch symlink in debootstrap to lucid?
<pitti> I heard from smoser that he builds the ec2 images on lucid
<ev> ogra: very strange. I can't see any reason it would be failing in that way, short of something else grabbing hold of debconf.  Any chance I could see a ps auxf from such an oem-config install attempt?
<cjwatson> so I can trivially (and with minimum bureaucracy) shove it into {lucid,maverick}-backports
<ev> when it fails, that is
<mvo> ev: the new upgade-install feature is really excellent, I'm currently using it for a test-upgrade
<cjwatson> perhaps that's the easiest approach
<ev> mvo: I hope you caught the backups warning ;)
<mvo> ev: backups, *pff*
 * mvo pats bzr push
<ev> mvo: you don't know where I live, right?
<ev> oh
<cjwatson> one thing is that the new debootstrap breaks old base-installer
<ev> :)
<cjwatson> but that's probably OK because we don't build installer images from -backports
<mvo> ev: no, I don't - but I know where you work ;)
<cjwatson> pitti: I dunno, would you prefer that, or a selective backport to -proposed?
<ogra> cjwatson, whatever is installed on the livefs builders
<ev> heh
<cjwatson> ogra: the actual livefs is built inside a whatever-suite-you're-building chroot
<ogra> i would expect that to be recent natty
<cjwatson> so hopefully that's current, I forget exactly how often it's upgraded though
<pitti> cjwatson: I'm fine with an SRU; however, I think we need to have a separate natty script then, instead of changing it all the way back into gutsy
<cjwatson> pitti: why?  it's a harmless change for older releases
<cjwatson> I'm trying to avoid creating new scripts
<pitti> I'm just concerned that the same programs which started failing with the new symlink might also trip over the extra "subdir" (link)
<pitti> stuff that iterates over all files might find an unexpected symlink, or might find files twice, etc.
<cjwatson> hm, not that I've seen, but OK - in that case, I'd rather go with -backports for now
<cjwatson> rather than more divergent code changes
<pitti> ack
<cjwatson> flushing
<Riddell> ev: bug 727690
<ubot4> Launchpad bug 727690 in ubiquity (Ubuntu) "install requests change of CD (dup-of: 726581)" [Undecided,New] https://launchpad.net/bugs/727690
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu) "install stops half way through (affects: 3) (dups: 2) (heat: 26)" [Undecided,Incomplete] https://launchpad.net/bugs/726581
<ev> thanks a bunch
<ogra> ev, all i can see is a denconf-communicate -fnoninteractive ubiquity in ps
<ogra> nothing special beyond that
<ev> ogra: could you please attach the full listing to the bug?
<ogra> from the ps ?
<ogra> sure
<ev> thanks
<ogra> the prob is that it doesnt hang actually it dies, i'm not sure i'm fast enough to capture the exact moment
<ogra> attached
<ogra> ev, anything special you see there ?
<ev> indeed not
 * ogra is running out of ideas how to debug that
 * ogra will tyr ps in a loop
<davmor2> cjwatson, pitti:  is the top bar on install meant to be so small?  it looks to be about 4 px
<pitti> davmor2: the panel you mean? no, should be some 30 pixel, the usual panel size
<davmor2> pitti: is it a known bug?  and yes panel was the word I couldn't remember
<pitti> not to me, anyway; I think you should report it
<davmor2> pitti: will do
<cjwatson> davmor2: ev deals with that stuff nowadays
<pitti> thanks
<davmor2> cjwatson: cool thanks
<davmor2> ev: it's all your fault cjwatson said so ;)
<ev> bug please
<davmor2> ev: doing it now I have photos
<davmor2> ev: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/727726
<ubot4> Launchpad bug 727726 in gnome-panel (Ubuntu) "gnome panel is about 4px instead of 30 on install (affects: 1) (heat: 6)" [Undecided,New]
<davmor2> only happens durring install panel is right size post install
<seb128> it's an ubiquity bug
<seb128> the "install" mode bar is not gnome-panel
<seb128> it's a custom ubiquity thing
<davmor2> seb128: My bag
<ogra> ev, attached three new files to the bug, i see a defunct debconf process while it dies, but i dont expect that to be much more informative
 * ogra wonders if anyone else succeded doing an oem install on non armel
<ogra> davmor2, i see the small panel too on armel oem installations
<ogra> i think GrueMaster filed a bug for it
<davmor2> ev: Yay I'm not the only one either is appears ^
<ogra> davmor2, is that oem-config or plain ubiquity
<davmor2> plain
<ogra> k
 * ogra is desparate
<ogra> cjwatson, so how does some basic installer knowledge help me, debconf dies silently underneath the installer, setting DEBCONF_DEBUG=developer doesnt reveal any additional info beyond using --debug for oem-config
<ogra> ps only shows a defunct debconf process when dieing
<ogra> i'm really out of ideas how to debug that and would be happy for any kind of suggestion
<ogra> (i even upgraded to the most recent ubiquity and dpkg versions in my preinstalled image without any results)
<cjwatson> strace?
<ogra> of what ? the debconf-communicate subprocess call ?
<ogra> what i see is that debconf-communicate survives but the backend is gone
<cjwatson> of everything
<cjwatson> strace -f -o /root/oem-config.trace -s 1024 oem-config, or similar
<cjwatson> modify whatever starts it
<ogra> ah, from the upstart job  then
 * ogra will try that, thanks !
<cjwatson> I think I'd recommend a bit lower than that, otherwise you'll end up stracing X
<ogra> oh, indeed
<cjwatson> oem-config-wrapper should do
<ogra> yep, just inspecting
<ogra> the fun is that all the other debconf communication just works, its so weird to have it die later then
<jibel> I have a different issue with oem on Ubuntu desktop - bug 727783
<ubot4> Launchpad bug 727783 in ubiquity (Ubuntu) "oem-config is not installed after initial system installation, and the user can't proceed with the step 'prepare for shipping' (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727783
<jibel> 727783 is confirmed by pedro on i386 as well
<jibel> ev, ^
<ogra> ev, cjwatson, strace info attached to the bug, i see a sigpipe even before the traceback kicks in there .... during some access to /etc/apt/apt.conf.d/ files
<ogra> 2274  unlink("/etc/apt/apt.conf.d/00AllowUnauthenticated") = -1 ENOENT (No such file or directory)
<ogra> 2274  write(1, "PROGRESS STOP\n", 14)   = -1 EPIPE (Broken pipe)
<ogra> 2274  --- SIGPIPE (Broken pipe) @ 0 (0) ---
<ogra> but the output doesnt seem to be completely in order, its very hard to read
<jibel> skaet_, OEM install is broken on desktop images
<ogra> and on preinstalled images
<ogra> :(
<cjwatson> ogra: we need to find out what happened to the other end of that pipe
<ogra> cjwatson, yeah, thats what i'm trying since yesterady :)
<mterry> Heyo!  Are images for A3 done?
 * cjwatson looks at the trace
 * ogra knows what he is looking for, just not how to get it 
<pitti> mterry: we might rebuild the armel ones (if we get a fix in time), but so far the others look okay
<mterry> I have a patch for a bad crasher in unity if you have a11y turned on, but not sure whether it would make it or should make it
<ogra> i made an excerpt, the fully syslog is 65M
<ogra> *full
<mterry> pitti, ok, so no reason to respin just for this probs
<pitti> mterry: upload away, but I don't think we'll respin; it's not an install failure, people can upgrade afterwards
 * cjwatson is not interested in strace excerpts
<ogra> k
<mterry> pitti, agreed
 * pitti needs to disappear for supermarket, bbl
<ogra> i thought i should filter by PID
<cjwatson> that's counterproductive - the thing we need to find out is what's happening to processes *other* than plugininstall.py
<ogra> oh, k
<cjwatson> the other end of the pipe is pid 728
<cjwatson> which was killed by SIGSEGV a bit further up
<cjwatson> after a huge pile of cacheflush calls
<cjwatson> it is not clear to me exactly what it's doing, apart from talking to X
<cjwatson> FWIW that's the top-level oem-config process
<cjwatson> it might be useful to attach gdb to the top oem-config process from a separate terminal before it segfaults, and hopefully get a stack trace
<cjwatson> failing that, 'ulimit -c unlimited' before starting it so that you get a core dump
<ogra> oh my ...
<ogra> oh, i just noticed i have a crash report from ubiquity-dm in /var/crash
<ogra> (unlikely thats helpful, but i'll attach it to the bug anyway)
<ogra> hmpf, trying to produce a core file is pretty unsuccessfull here
<ogra> it dies but moves on removing ubiquity and doesnt produce a core at all
 * ogra has to redo the image now ubiquity is gone ... sigh
<GrueMaster> Interesting.  I am able to get oem-config running on x86 after some image manipulation, but I am not able to reproduce the crash seen on armel.
<doko> pitti: is there a reason removing the milestone for 705689?
<pitti> doko: see https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/705689/comments/32
<ubot4> Launchpad bug 705689 in qt4-x11 (Ubuntu Natty) (and 6 other projects) "Qt applications crash with segfault error on armel when Qt is built with gcc 4.5 on natty (affects: 2) (heat: 30)" [High,Invalid]
<doko> pitti: ScottK seems to disagree
<cjwatson> pitti: it seems like it should be milestoned somewhere though
<cjwatson> beta-1?
<cjwatson> if it's blocking KDE using gcc-4.5 ...
<ScottK> pitti: I agree it's not an Alpha 3 blocker, but I don't think we want to release Natty with Qt/KDE built on GCC 4.4, so it should be milestoned somewhere.
<ScottK> Although lack of it now means we'll have to build with 4.4 when we upload KDE 4.6.1.
<ScottK> doko: When in March is it due out?
<doko> linaro releases are always the 2nd Tue of the month
<doko> ScottK: is there a reason to use 4.4 on all archs?
<ScottK> doko: No.  Just on armel.
<pitti> well, *shrug*, feel free to add beta-1, if you prefer
<pitti> but it'd be fine to fix after beta-1 as well from my POV
<pitti> it's still a release critical bug for natty, after all
<ScottK> pitti: The problem is we'll have to rebuild a large number of packages on arm after it's fixed to get them built with gcc4.5.  That's not something we want to do at the last moment.
<pitti> ScottK: so, beta-1 then?
<ScottK> I'll mark it.  Hopefully it's resolved next week anyway.
<pitti> nice; my primary objective was to clean up the alpha-3 blocker list; this one isn't one
<ScottK> Agreed.  It just would have made the next week a lot easier if we'd gotten it.
<Daviey> smoser Is having a hard time at the moment testing potential cloud image candidates for A3, as some of the regional AWS hosted mirrors seem broken.  Canonical IS who maintains the mirrors has an RT ticket open.
<smoser> well, that will cause some tests to fail. we still dont have all images published yet. and IS is working on it, the cause has been elusive before.
<smoser> i expect that ~ 3:30 US/Eastern I will have all images published.  I've one so far and it seems fine.
<cjwatson> bug 727783 is another "can I just shoot myself now" bug
<ubot4> Launchpad bug 727783 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config is not installed after initial system installation, and the user can't proceed with the step 'prepare for shipping' (affects: 2) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/727783
<cjwatson> the interaction with apt-cdrom has got confused *again*
<cjwatson> I'll see what I can do but can't make any promises about timescales, since I have to go out shortly
<skaet_> cjwatson,  understood.   Anyone else able to look into it?
<cjwatson> ev if he has time but I don't know if he does, we're on the same timezone
<cjwatson> I'm attempting to strace it now
<cjwatson> hmm, this 1GB strace file may not be uploadable to a bug ...
<cjwatson> might have a fix, testing now
 * skaet_ keeping fingers crossed.
 * ogra gave up on crossing fingers ... makes typing so hard 
<skaet_> lol
<cjwatson> I think bug 723357 has a similar cause, but would rather try to limit the amount of stuff I upload for a3
<ubot4> Launchpad bug 723357 in casper (Ubuntu) "ISO filesystem not mounted properly on Live USB disks (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/723357
<cjwatson> grr.
<skaet_> grr ??  hmm, should I be worried?
<cjwatson> first approach didn't work
<charlie-tca> skaet_: I would like to release note the bug 71234
<ubot4> Launchpad bug 71234 in eog (Ubuntu) (and 1 other project) "Eye of GNOME (eog) grabs keyboard when in full-screen. (heat: 2)" [Low,Invalid] https://launchpad.net/bugs/71234
<charlie-tca> valid workaround is to do a full shutdown after first login.
<charlie-tca> Then run update-manager
<skaet_> charlie-tca,  thanks for flagging.   ok will add now.
<charlie-tca> Thank you
<skaet_> charlie-tca is bug 71234 the right bug number??    looks pretty stale/invalid.
<ubot4> Launchpad bug 71234 in eog (Ubuntu) (and 1 other project) "Eye of GNOME (eog) grabs keyboard when in full-screen. (heat: 2)" [Low,Invalid] https://launchpad.net/bugs/71234
<charlie-tca> nope
<charlie-tca> I seem to have missed that when I copied it
<charlie-tca> the right one is bug 712346
<ubot4> Launchpad bug 712346 in update-manager (Ubuntu) "update-manager crashed with TypeError in _get_last_apt_get_update_text(): unsupported operand type(s) for /: 'NoneType' and 'int' (affects: 16) (dups: 3) (heat: 202)" [Medium,Triaged] https://launchpad.net/bugs/712346
<charlie-tca> I guess the 6 on the end matters
<skaet_> heh,  thanks charlie-tca that makes more sense now ;)
<charlie-tca> thanks for catching that mistake
<doko> ogra: is openjdk on any arm image?
<ogra> doko, not that i can think of, no
<ogra> iirc it went away with OO.o
 * ogra checks manifest
<ogra> doko, confirmed, not on the images
<GrueMaster> Just tested http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110301/natty-preinstalled-desktop-armel+omap4.img.gz and oem-config doesn't even start.  Boots straight into kdm.  Looking over boot logs now, but may be a race condition with unity.
<GrueMaster> I was trying it as a debug measure for our netbook images.
<mvo> thanks charlie-tca I look into the u-m crash tomorrow
<ogra> cjwatson, ha !
<ogra> cjwatson, looks like uninstalling the slideshow fixes the armel bug (seems to be webkit related)
<charlie-tca> No problem, mvo
<ogra> skaet_, ^^^
<skaet_> :)
<ogra> skaet_, NCommander is preparing a hack in livecd-rootfs that removes the slideshow from arm builds
<ogra> we will need to get that into the archive and need a respin then
<skaet_> ogra, heh, that was going to be my next question... are we getting updates for new images.
<rsalveti> skaet_: ogra: yup, was able to install it successfully after removing this package
<rsalveti> seems the bug is inside webkit
<ogra> oh my
<NCommander> ogra: skaet_ someone will have to smack the livecd builders to pull from the archive
<ogra> our error reporting in ubiquity needs to become better
<ogra> it should have told us "hey webkit is broken" in the first place :P
<ogra> NCommander, they do that automatically since maverick
<ogra> only BuildLiveCD isnt autosynced afaik
<NCommander> oh, aweseome
<rsalveti> ogra: hard to say that when python is crashing with sigsegv
<ogra> heh, indeed
<ogra> i wasnt serious
<skaet_> rsalveti,  thanks.  :)
<ogra> i'm just so happy after two days of debugging
<rsalveti> :D
<ogra> that was really painful
<rsalveti> for sure it was, but cool, at least I learned more about oem-config :-)
<ogra> :)
<NCommander> ogra: http://paste.ubuntu.com/574629/ - how's that for sanity?
<pitti> ogra: I recently fixed webkit on amd64, it tried to allocate 1 GB of RAM; but on arm it should only try 16 MB, which doesn't sound too much
<pitti> ogra: I'm curious, how is the slideshow involved in arm preinstalled builds at all
<NCommander> pitti: used as part of oem-config
<pitti> ah, of course
<rsalveti> pitti: once python tries to use the webkit bindings, it crashes with sigsegv
<pitti> it would be interesting if /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher crashes by itself on an arm system
<rsalveti> and then oem-config is gone
<pitti> if so, that'd be a lot easier to debug
<rsalveti> pitti: nops, working fine
<rsalveti> could be related with the python bindings
<pitti> *nod*
<rsalveti> ooops, too soon to tell, got a sigsegv
<pitti> rsalveti: with a particular web page? or just at startup?
<rsalveti> pitti: it loads google, and then after some seconds it crashes
<pitti> rsalveti: do you get an apport .crash?
<NCommander> rsalveti: is it the python bindings or webkit in general?
<rsalveti> webkit in general
<pitti> /usr/lib/webkitgtk-1.0-0/libexec/GtkLauncher is webkit itself
<NCommander> ah
<NCommander> right :-)
<rsalveti> pitti: will check
<pitti> rsalveti: thanks; perhaps it can be replicated in xvfb on a porter box or so
<rsalveti> argh, gdb kills the board when running with webkit
<rsalveti> webkit is huge
<rsalveti> pitti: yup, got the crash file
<ogra> pitti, bug 727468
<ubot4> Launchpad bug 727468 in ubiquity (Ubuntu Natty) (and 3 other projects) "oem-config crashed during install on armel (affects: 1) (heat: 8)" [Critical,Confirmed] https://launchpad.net/bugs/727468
<NCommander> ogra: test spin going with hack to remove slideshow
<ogra> NCommander, packagename is wrong
<rsalveti> ogra: should I open a new bug for this webkit issue? or just link the oem-config with webkit?
<rsalveti> argh, corrupted stack
<rsalveti> need to install webkit dbg symbols, but first need space for it :-)
<ogra> NCommander, and you should actually put your hack *after* the code that installs LIVELIST ;)
<ogra> helps a lot to remove somethig *after* it was installed ;)
<rsalveti> hehe :-)
<ogra> rsalveti, i just changed the title of the bug ... we need other tasks and close the ubiquity one
<ogra> i think it helps that we have the debug data on it already
<ogra> even though if it might only show fallout
<pitti> rsalveti: right, we don't have retracers for armel ATM :/
<ogra> pitti, on NCommander's todo, but he was busy fixing mono
<pitti> rsalveti: but if you can salvage the .crash file anyway, we might be able to fake it on the porter boxes
<ogra> we might have them back right on release day ;)
<rsalveti> pitti: np, can install the dbg symbols and try to get a proper trace
<pitti> we can do that the plain old way with the core dump and installing -dbg in the porter box dchroots
<pitti> rsalveti: even better :)
<pitti> ogra: just to triple-check is removing ubiquity-slideshow ok? on amd64 our workaround was to remove ubiquity-slideshow-ubuntu
<ogra> pitti, thats what i meant above
<pitti> ubiquity-slideshow is purely virtual usually
<ogra> <ogra> NCommander, packagename is wrong
<pitti> ah, ok
<pitti> sorry
<ogra> well, michael didnt get that either i think
<ogra> NCommander, ^^^^
<ogra> NCommander, ubiquity-slideshow-ubuntu is the package
<ogra> NCommander, and move it down a bit ... right above "# remove our diversions" i'd say
<NCommander> ogra_: yeah, saw that mistake myself, replacedit with ubiquity-slideshow-*, although I'm happy with its position as its just below where we do the last package manipulation on the image
<smoser> skaet_, http://uec-images.ubuntu.com/server/natty/20110302.2/published-ec2-daily.txt has the ec2 images data to populate tracker
<ogra_> NCommander, not really
<smoser> i know that cjwatson and slangasek have done that before, not sure if you have.
<ogra_> NCommander, chroot $ROOT apt-get -y --purge install $LIVELIST </dev/null
<ogra_> NCommander, that line actually installs the slideshow
<ogra_> NCommander, your hack needs to be below it
<skaet_> smoser,  ok,  will go in and populate it.
<ogra_> NCommander, thats why the checkpoint says "Installing live packages" ;)
<pitti> skaet_: need anythign from me tonight still?
<pitti> ogra_: or you? (I think you can retrigger the armels yourself, right?)
<ogra_> i can do it myself, yeah
<ogra_> but would like to finish my day too at some point
 * pitti hugs ogra_, great to see this working at last
<ogra_> but NCommander can do that too
<slangasek> skaet_: you have the post-amis-to-iso-tracker script for this, right?
<skaet_> pitti, can you take a pass through the TechOverview?
<pitti> ogra_: I can also set up a trigger to start building them once a fixed livefs-build package is published for arm
<skaet_> slangasek, its in the iso build loads, but if that doesn't work, I'll let you know.
<ogra_> pitti, nah, NCommander and i can take care
<pitti> ok
<slangasek> skaet_: hmm, iso build loads?
<skaet_> iso tracker,  sorry.
<slangasek> skaet_: doing this by hand is *verry* tedious and error-prone if you want to be able to accurately track the individual AMIs on the iso tracker, so I hope you're using the script :)
<skaet_> slangasek,  nope what I was trying didn't work.  so I'm missing something.
<NCommander> ogra_: gah, hoops
<skaet_> slangasek, wasn't using the script, so time for a bit of training for me I guess. ;)
<slangasek> skaet_: lp:~ubuntu-archive/ubuntu-archive-tools/trunk/; script called 'post-amis-to-iso-tracker.py'; takes smoser's linked file as input
<slangasek> though fwiw I've always snarfed that file via ssh instead of http, since the http connection provides no assurance of data integrity... I'd hate to accidentally post a link to an OpenSuSE AMI to the tracker
<slangasek> :)
<skaet_> heh.
<skaet_> slangasek,  ok, trying.
<pitti> skaet_: TechOverview> for content? or also for language already?
<skaet_> pitti,  both please ;)
<pitti> skaet_: (still missing quite a lot, so I propose to leave the language fine-tuning for tomorrow)
<skaet_> sure,  just get me some contents, and I'll do more scrubs on it later.
<pitti> skaet_: not too much new contents, but some clarifications and language fixes: https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview?action=diff&rev2=102&rev1=101
<skaet_> thanks pitti.    Glad its had your eyes over it.    When you get in tomorrow,  take a look through the bugs too.  They'll be being added today.
<skaet_> have a nice evening.
<pitti> skaet_: yup
<pitti> skaet_: almost -- just saw the new load of kernels coming in..
<pitti> good night
 * slangasek waves. 'night, pitti!
<skaet_> good night pitti
<highvoltage> night pitti
<skaet_> smoser, can you confirm the images are available now?
<smoser> yeah, tests are being run.
<smoser> did someone tell you they weren't available ?
<smoser> because for a small point, they were not. but they're back.
<skaet_> just confirming that the script actually did what it should have.  :)
<smoser> skaet_, i have the tets running now, i'll fill in the results sometime tonight.  they're looking fine.
<smoser> and i've got the "pre-publish" for alpha3 running on those images. so we'll be all set tomorrow.
<skaet_> smoser,  good to know. :)
<skaet_> thanks for the update.
<jibel> skaet_, bug 728088 iSCSI test in server amd64
<ubot4> Launchpad bug 728088 in debian-installer (Ubuntu Natty) (and 1 other project) "iscsi root (amd64) with or without auth fails to boot (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/728088
<skaet_> thanks jibel,  adding it to the hot list
<skaet_> smoser, is anyone around from the server team who can look at this new one?  ^  or do we need to wait for UK to come online?   At this stage, we'll probably release with it, and document.
<charlie-tca> skaet_: only change I see for release notes is to add gmusicbrowser replaces exaile in xubuntu
<GrueMaster> skaet_: Ok, we have an update to livecd-rootfs to remove ubiquity-slideshow-ubuntu from the armel images.  This should at least get us a working image for A3.
<GrueMaster> I have been testing with this workaroung and haven't seen any other gotchas.
<cjwatson> iscsi> for the record I have a feeling that we need to update open-iscsi to a new upstream version to match kernelspace.  probably not something that can be done in a day.
<skaet_> cjwatson,  ack.   we'll go with what we have at this point.
<skaet_> GrueMaster,  sounds good.   What is the upload status?
<skaet_> charlie-tca, please go ahead and add/make changes for Xubuntu overview (and any other signifcant bugs you want to highlight)
<GrueMaster> Uploaded livecd-rootfs, waiting to be published.  Once it gets published, someone can kick image rebuild.
<GrueMaster> Once the images are there, I can test them and get the data in to the tracker.
<charlie-tca> okeydokey
<skaet_> Gruemaster,  sounds good.
<NCommander> skaet_: saw that GrueMaster updated you. Publisher should start running in 5 minutes. once its done, i'll kick the image build and publish a new armel+omap4 image
#ubuntu-release 2011-03-03
<GrueMaster> NCommander: We'll need omap as well.
<skaet_> NCommander,  thanks for chiming in.  :) perfect.
<charlie-tca> skaet_: release notes done for xubuntu. Thank you
<NCommander> skaet_: GrueMaster:  smbclient : Depends: samba-common (= 2:3.5.6~dfsg-5ubuntu2) but 2:3.5.6~dfsg-5ubuntu3 is to be installed
<NCommander> $%$#@!
<NCommander> That's preventing me from spinning new test images
<NCommander> ArGH
<NCommander> oh nifty
<NCommander> we're published
<NCommander> GrueMaster: at least another hour before I'll actually be able to spin. samba is currently building on ARM, and skews the archive
<GrueMaster> sigh
 * NCommander however does a test build to insure livecd-rootfs will properly update on sycamore
 * skaet_ --> dinner,  back later.
<NCommander> skaet_: GrueMaster; livecd-rootfs updated on the ARM image buildds
<NCommander> $#!@#$%#$%#$%
<NCommander> samba is STILL building
<NCommander> if it doesn't finish soon, its going to miss the publisher window
<NCommander> ^- GrueMaster
<NCommander> the chroot is tearing down
<NCommander> it should make it
<wgrant> With a little luck we'll be able to double publisher frequency in a month or so :)
<NCommander> wgrant: I'm more annoyed that people like to ignore freezes. If the build failed on armel, then we'd be absolutely foobared
<wgrant> Heh.
<NCommander> wgrant: just on a technical point, is it possible to freely freeze/unfreeze the archive?
<wgrant> NCommander: Yes. But Ubuntu moved to soft freezes around milestones a couple of years back.
<NCommander> wgrant: an unfortunate policy change IMHO
<wgrant> It does occasionally prove bad.
<slangasek> samba is accepted, so you're fine on the publisher
<slangasek> was this a package that was uploaded in violation of the freeze?
<slangasek> "soft freeze" doesn't mean "go ahead and upload whatever you want and ignore the release team"
<slangasek> yes, this was definitely a freeze violation
<NCommander> slangasek: yeah, I looked at the changelog, and nothing here required an upload T-24 to milestone freeze
<NCommander> slangasek: this isn't the first time a last minute upload has caused issues for the ARM builds. I'd *love* to see milestones have hard freezes return TBH :-/
<slangasek> that's very high-load on the release team, and shouldn't be required - we should be able to trust Ubuntu developers to follow simple guidelines wrt milestone uploads
<slangasek> so I would consider restoring hard freezes a last resort
<skaet_> hmm, does this mean that we should be collecting some beer from some one?  ;)
<slangasek> perhaps you could email Chuck and point him to the freeze email, and explain why this was a problem?
<NCommander> slangasek: I thought setting the freeze was simply a matter of going to the distro series, and changing it from development to pre-release freeze
<NCommander> (doable via web UI)
<NCommander> or are you referring to approving uploads?
<slangasek> NCommander: *setting* the freeze is not the problem; managing freeze *exceptions* is
<slangasek> (also, last I knew, only LOSAs had access to the button to set the freeze state)
<NCommander> slangasek: ah :-). yeah, I didn't quite realize that until a moment after I said the first thing
<NCommander> slangasek: 20:04:00 < slangasek> (also, last I knew, only LOSAs had access to the
<NCommander>                       button to set the freeze state)
<NCommander> %$!@#!$$@^%$#
<NCommander> 20:04:01 < NCommander> slangasek: ah :-). yeah, I didn't quite realize that
<NCommander>                        until a moment after I said the first thing
 * NCommander grumbles that "proper" beahvior isn't proper
<NCommander> slangasek: I get your point, and I can see that approving freeze exceptions can be a massive workloadincrease, at cost that when someone violates the freeze, specific images can be foobared due to archive skew
<NCommander> ok, published
 * NCommander kicks buildlive
<NCommander> slangasek: is there a way to see if publisher is done? I can't lynx onto ftpmaster.internal to see if the package is in the pool ...
<slangasek> well, you know the publisher is done when the mirror you're pulling from has the package?
<slangasek> there's no direct test for this, no
<ScottK> So you need a script that hits the mirror two or three times a second to let you know when the package arrives ...
<wgrant> slangasek: (any Launchpad developer should be able to freeze/unfreeze a series now)
<slangasek> wgrant: "launchpad developer"?  I would think the LOSAs are still who those requests are meant to be directed to, aren't they?
<wgrant> I'm not sure if the policy has changed, but the technical restrictions certainly have.
<NCommander> about 3 hours ago - by Jon Stokes | Posted in: Law & Disorder
<NCommander> The government brought 22 new charges against Pfc. Bradley Manning, the soldier who allegedly provided a giant trove of classified cables to WikiLeaks.
<NCommander> sorry
<NCommander> damn paste bug
<charlie-tca> He signed a agreement when he enlisted. He is in trouble
<ScottK> Yep.
<charlie-tca> but I do worry about Assange
<ScottK> This probably isn't the best place for the discussion though.
<rsalveti> NCommander: lol :-)
<rsalveti> NCommander: the the image built fine?
<rsalveti> *did the
<rsalveti> seems it failed, and no logs
<NCommander> rsalveti: build is still ongoing. samba's upload skewed the image so i ttook awhile for the archive to get to the point I could build
<rsalveti> NCommander: oh, ok
<NCommander> rsalveti: there were a bunch of test builds which I expected to fail
<rsalveti> yeah, just saw that samba was the culprit
<NCommander> rsalveti: you could say I was less than pleased about that :-/
<NCommander> sycamore.buildd finished at Thu Mar  3 02:40:15 UTC 2011 (success)
<NCommander> acorn.buildd finished at Thu Mar  3 02:41:07 UTC 2011 (success)
<NCommander> running the image build
<rsalveti> cool
<skaet_> :)
<NCommander> GrueMaster: http://cdimages.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110303/
<GrueMaster> Someone alive that can poke iso.qa.ubuntu.com for me?  I'm pulling these images now, and can start feeding in data asap.
<skaet_> GrueMaster, iso.qa.ubuntu.com has been poked.
<skaet_> NCommander,  is it worth building the kubuntu Netbook ARM?
<GrueMaster> skaet_: In my earlier testing of it, it will have the same issue, but oem-config wasn't even starting.
<skaet_> GrueMaster,  should I just go ahead and remove kubuntu netbook ARM then from the iso tracker?
 * skaet_ thinking its a bit late anyhow...
<GrueMaster> Give me a minute to start a sanity check of these images.  If they work, we can kick start kubuntu.
<GrueMaster> So far so good!
<GrueMaster> omap passed Alpha 3.  Will log issues in the tracker, but nothing critical.
<GrueMaster> omap4 is underway.
<GrueMaster> As to kubuntu, NCommander has kicked antimony, but they won't be ready for another ~2 hours.  I'll take the 20110301 omap4 and try our fix manually.  I doubt it will work.
<GrueMaster> I won't be able to test them tonight.
<rsalveti> GrueMaster: so we're kind of done for A3?
<GrueMaster> Well, for the most part.  I am adding test results to http://iso.qa.ubuntu.com
<GrueMaster> I'll be another 30 minutes I think.
<GrueMaster> But for the most part, yes.  Nothing critical to hold up release at this point.  :D
<skaet_> pitti,  cjwatson,  could you please add the kubuntu images to the .iso tracker when you get in, and let ogra know.
 * skaet_ is assuming NCommander won't be around when the kubuntu images come off
<skaet_> GrueMaster,  good news indeed.   Thanks!
<GrueMaster> skaet_: Didn't think you'd still be up.
<skaet_> GrueMaster, working on TechOverview for tomorrow - lots of bugs to document :P
<skaet_> am probably going to call it a night though now... suspect tomorrow will be a longish day as well.
<GrueMaster> Well, I still have bugs to add to my results, so don't wait up for me.  I'll have them ready for you when you get up in the morning.  :P
<NCommander> skaet_: probably not
<skaet_> cjwatson, pitti, ^^
<GrueMaster> Looks like the kubuntu respin may be for not.  I took the 20110301 image and remobed ubiquity-slideshow-*, but oem-config still crashes, this time before X starts.
<GrueMaster> So, no kubuntu-preinstalled on armel for this release.
<skaet_> GrueMaster, ack.   Thanks for looking into it.
<pitti> Good morning
<pitti> sorry, server crash over the night, I lost backscroll
<pitti> cjwatson, skaet_, slangasek: ^ if you said something to me over night, please repeat
<Laney> pitti: you can check the logs online ;-)
<pitti> (reading irclogs.u.c. now)
<pitti> Riddell, ScottK, ogra_: do you know why kubuntu netbook arm was set to rebuilding? is it affected by the slideshow crash as well?
<pitti> ^ nevermind, saw it on irclogs.u.c. now
<pitti> cjwatson: my feeling about bug 727783  is that OEM installs are not an utterly important use case for alphas, so that we'll release note OEM install as broken (or explain the workaround), and move the bug to b1; I don't think it's important enough to delay a3, WDYT?
<ubot4> Launchpad bug 727783 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config is not installed after initial system installation, and the user can't proceed with the step 'prepare for shipping' (affects: 3) (dups: 1) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/727783
<cjwatson> pitti: I'm not going to have it fixed for a3 :-(
<cjwatson> I mean, I think I have an idea
<pitti> cjwatson: right, if we kept the milestone, we'd need to delay by a couple of days
<pitti> but I'd like to avoid that
<cjwatson> but the test cycle is long, and I have to go out for a couple of hours shortly
<cjwatson> (usual Thursday morning sign class)
<pitti> cjwatson: are you ok with moving to b1 and just documenting it?
 * pitti will go over tthe bugs now and add them to Tech Overview
<cjwatson> yeah
<cjwatson> one thing to note is that I fear it may impair language pack installation off the CD too, so I suspect that will only work if networked
<cjwatson> that's just a guess but an educated one
<cjwatson> but language-selector is fairly good these days, so I don't think that's vital either
<pitti> cjwatson: not that we actually had a lot of langpacks on the CDs..
<pitti> right
<pitti> cjwatson: I'll give that a quick test in kvm -net none
<cjwatson> there is that too :-/
<cjwatson> thanks!
 * pitti ponders whether he'd be lost more in a French or Bengali live system
<pitti> those two, Spanish, and zh-hans is all we have now
<pitti> oh, not even French any more
<pitti> so, Spanish it is
<Riddell> hola, how are we doing?
<pitti> Buenos dÃ­as, hÃ©roe de Kubuntu!
<pitti> Riddell: we just declared oem mode officially broken for a3, I'll document it (and a workaround)
<pitti> otherwise it looks pretty ok, I think
<Riddell> except for Kubuntu desktop and DVD being broken
<Riddell> I take it someone has done an ubuntu desktop install on real hardware to confirm they don't have the same issue?
<pitti> hm, I saw a few successful test cases, too
<pitti> (for Kubuntu)
<Riddell> yes because the QA team only tests on virtual machines
<Riddell> real hardware isn't so lucky
<pitti> bug 726581 I tak eit
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu Natty) (and 1 other project) "install stops half way through (affects: 4) (dups: 2) (heat: 30)" [High,Confirmed] https://launchpad.net/bugs/726581
<Riddell> yes, which leaves the install with an unbootable hard disk so I don't want to release images with that bug
<pitti> I'll run a test install on my mini 10
<seb128> can do that as well
<seb128> is there any special install scenario that needs testing?
<pitti> more tests are better, yes
<pitti> I don't think it's crashing during partitioning, so full disk should be okay
<pitti> Riddell: what did you try when you saw this?
<Riddell> live session -> ubiquity -> use full disk
<pitti> cheers, will try that as well
<pitti> cjwatson: Spanish langpacks were copied properly in my offline install test
<pitti> Riddell: online or offline?
<Riddell> pitti: both
<pitti> well, can't go online with the mini in the live system anyway
<pitti> Riddell: no CD drive in the mini, I'm using USB stick; were you using an actual CD? (given the weird media change log entries this might be relevant)
<Riddell> I had the problem with both CD and USB
<pitti> installed, booted, bug updated
 * pitti looks for that string in the sources, to see what could trigger it
<seb128> ubiquity in natty is still not nb screen friendly
<seb128> did anybody else got keyboard configuration issues? or a weird question about keyboard after the tz selection?
<pitti> not me; just a compiz crash on startup
<pitti> hm, I can't find that string
 * pitti greps /usr
<pitti> ah, it's from python-apt
<pitti> mvo: do you know under which circumstances apt/python-apt would call media_change()?
<pitti> mvo: (for bug 726581)
<ubot4> Launchpad bug 726581 in ubiquity (Ubuntu Natty) (and 1 other project) "install stops half way through (affects: 4) (dups: 2) (heat: 30)" [High,Confirmed] https://launchpad.net/bugs/726581
<mvo> pitti: either if the sources.list cdrom source is before the http source or if the pkg is not available from the network (e.g. missing cache update)
<pitti> it allegedly also happens offline
<pitti> and online
<pitti> mvo: i. e. it tries to install a package which isn't in the live system or on teh CD?
<Riddell> Ubuntu Desktop isn't looking healthy, compiz crashes, random messages about CD with packages in it, blank desktop
<pitti> yeah, I think we need to teach casper to disable the apt media check
<pitti> it didn't annoy you with these earlier
<seb128> ok, I just did an ubuntu desktop i386 custom partition install, worked fine, unity starts
<pitti> mvo: ^ did that change in natty in any way?
<jibel> seb128, yes I did, but I'm unable to find the steps to reproduce. It looks like being linked to the timing when you proceed to the keyboard layout screen.
<seb128> jibel: ok, seems to happen every time here
<seb128> pitti, is jockey supposed to manifest itself after first login?
<pitti> "Skipping nonexistent file /cdrom/dists/natty/main/binary-i386/Packages" -> I have that on a successful install as well, so that's not it
<pitti> seb128: actually yes (on the mini, for the wl driver, unless you installed online)
<seb128> pitti, it doesn't here
<mvo> pitti: uhhh, possible, the mountpoint is /media/cdrom by default now
<seb128> pitti, ok, .xsession-errors says it crashes on " TypeError: an integer is required"
<seb128> in update_repository_indexes
<jibel> mvo, update-notifier is now showing up during install from a live session. Is it expected ?
<pitti> seb128: ah, bug 711225)
<ubot4> Launchpad bug 711225 in python2.7 (Ubuntu Natty) (and 1 other project) "subprocess.Popen() crashed with TypeError in _cleanup(): an integer is required (affects: 3) (heat: 28)" [Medium,Confirmed] https://launchpad.net/bugs/711225
<seb128> pitti, indeed
<seb128> pitti, thanks
<mvo> jibel: no, not at all
<mvo> jibel: showing up in what way?
<seb128> jibel: let me know if you open a bug about the keyboard thing, I will confirm it
<pitti> seb128: fun, I never got that on my workstation, can reproduce on the mini
<jibel> mvo, bug 722580
<ubot4> Launchpad bug 722580 in update-notifier (Ubuntu) "update-notifier is launched while ubiquity is running (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/722580
<pitti> mvo: it keeps popping up dialogs with "an install medium found, want to open blabla"
<seb128> pitti, your workstation is online and get an index update
<seb128> pitti, it's a chicken-egg issue on the 10v
<seb128> no wifi no internet no index
<jibel> seb128, no I didn't filed a bug because I have no useful information to provide.
<seb128> jibel: well the prompt seems buggy and you get an english keyboard after installation
<pitti> mvo: so that media change thing could be related to the changed mount point? did that change after a2?
<mvo> pitti: yeah, its quite likely, I can revert it for now
<pitti> mvo: does that depend on anything else? I wonder why we only see it on kubuntu
<mvo> pitti: maybe its just kubuntu that triggers a additional pkg install from the cd?
<mvo> pitti: and the normal ubuntu does not
<pitti> hm, perhaps that's what breaks oem-install as well, checking logs
<pitti> Mar  2 13:10:38 ubuntu plugininstall.py: FetchFailedException: Failed to fetch cdrom:[Ubuntu 11.04 _Natty Narwhal_ - Alpha amd64 (20110302)]/pool/main/u/ubiquity/oem-config-gtk_2.5.22_all.deb File not found
<pitti> mvo: so, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/727783/+attachment/1880803/+files/UbiquitySyslog.gz (log from the failed oem install) doesn't have a "Media change" notification, but above ^
<ubot4> Launchpad bug 727783 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config is not installed after initial system installation, and the user can't proceed with the step 'prepare for shipping' (affects: 3) (dups: 1) (heat: 20)" [High,Confirmed]
<mvo> pitti: I can do a new upload now, its a likely candidate and the only one I can currently think of
<pitti> mvo: is that in the binary bits or in python?
<pitti> mvo: it could be worth locally installing that reversion on a kubuntu live system, and checking if it installs
<seb128> pitti, so the jockey issue is solved if you do an apt-get update iirc
<pitti> mvo: if you have a package, I can do a parallel test with OEM, to see whether it affects that as well
<pitti> seb128: right; I'll investigate the python crash later on
<seb128> pitti, i.e find an ethernet cable, do apt-get update and it will work
<pitti> seb128: now that I can reliably reproduce it
<seb128> pitti, ok
<pitti> seb128: right; I'm actually eager to keep it breaking, as this looks like a weird bug in python's subprocess.py
<seb128> pitti, just letting you know as a piece of information
<mvo> pitti: it should be enough to add a symlink from /media/cdrom to /cdrom for testing
<seb128> pitti, running the command in the python interpreter works, so it's weird
<mvo> pitti: its the binary bits
<pitti> mvo: that would be equivalent to the reversion? good
<Riddell> I don't have the problem during Ubuntu Desktop install
<Riddell> mvo: I'll try a Kubuntu install with that change
<pitti> let's try that
<pitti> Riddell: can you try Kubuntu? I'll try Ubuntu oem
<Riddell> yep
<pitti> /media/cdrom -> /cdrom, right?
<pitti> /cdrom is already mounted
<mvo> could you please link the other way around then?
<pitti> no, I can't
<mvo> are both directories?
<pitti> /cdrom is existing and mounted, I can't replace it with a symlink to /media/cdrom
<pitti> mvo: /media/cdrom doens't exist by default; I created it as  a link to /cdrom
<mvo> cool
<mvo> the important bit is that apt finds something at /media/cdrom
<mvo> so that should be good now
<pitti> running
 * mvo crosses fingers
<pitti> ls -l /media/cdrom/dists/ -> natty
<pitti> running
<mvo> nowdays apt-cdrom/cdrom.cc will use udev unless explicitely disabled, I guess the installer disabled that bit during install
<ev> indeed it does
<pitti> mvo: is that related in any way with the "install cd has been detected" spam?
<mvo> it might be, I can currently not think how though, but it sounds likely
<pitti> install finished; booting and crossing fingers..
<pitti> hah! worked
<Riddell> my install is at 65%! it always got stuck at 64% before
<pitti> go! go! go!
<pitti> the 64th percent is always the hardest
<pitti> mvo, ev: so what would be the correct fix for this? does ubiquity/d-i make assumptions about /cdrom? or does this need to be fixed entirely in apt?
<pitti> or would the correct fix take longer, and as a workaround we just upload a casper which creates the symlink?
<pitti> OEM configure step now complete, I'm in the user session
<mvo> pitti: I don't have a strong opinion on this, I'm fine reverting
<pitti> mvo: what do you want to revert in particular, the default mount point if udev is disabled?
<mvo> the default mount point
<mvo> it got changed because of a debian bugreport from kfreebsd where no udev is available
<pitti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611569
<ubot4> Debian bug 611569 in apt "apt-cdrom doesn't work on GNU/kFreeBSD" [Important,Fixed]
<mvo> for all clients (including apt itself) the dir should not matter when udev is used, it will just detect it
<mvo> yep
<pitti> ah, seems cjwatson already identified that as probable cause
<pitti> so reverting this doesn't sound optimal then
<mvo> it eventually got fixed in a different way for kfreebsd
<pitti> mvo: so the problem is that the installer/casper/etc. still use and assume /cdrom ?
<pitti> FWIW, http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/3a3826b3871c8c2f480bcba820c6da8f86700143 :)
<pitti> it might not take that long any more
<mvo> heh, woah!
<pitti> mvo: should we perhaps just quickfix this in casper, to get a3 out of the door?
<Riddell> kubuntu install completed, awesomeage
<pitti> I propose we only rebuild the Kubuntu CD/DVD, not the entire set, and document that OEM install is broken (and how to fix it)
<pitti> Riddell: \o/
<pitti> I wonder if this can be done even quicker with a cdimage hack
<pitti> hm, no, this would keep the symlink in the installed system
<mvo> pitti: sure, thats fine with me
<mvo> pitti: just a symlink
<pitti> Riddell: I'll upload a new casper then, ok?
<Riddell> yes, thanks
<pitti> chroot /root apt-cdrom -o Acquire::cdrom::AutoDetect=false -m add
<pitti> mvo: ^ is that what is supposed to disable the CD check?
<mvo> pitti: yes, thats the one
<pitti> so apparently it stopped working?
<pitti> +# temporary hack for LP#727783
<pitti> +mkdir -p /root/media
<pitti> +ln -s /cdrom /root/media/cdrom
<pitti> +
<mvo> well, if the autodetect is disabled, then it will look at the default cdrom path, that used to be /cdrom and now its /media/cdrom
<mvo> would be nice to just have auto-detect true here, but I guess the problem is the chroot
<mvo> your diff looks good
<pitti> uploaded; let's see how fast it can build
 * pitti runs process-upload manually and then stops the publisher
<pitti> Riddell: alternates are ok, right?
<pitti> marked Kubuntu desktop and DVD for rebuild
<Riddell> pitti: yes
<mvo> can I upload a new software-center for immediate publication after a3 - or wll that interfere with your workflow (new reviews server got deployed last night :-D
<pitti> mvo: can you still wait a bit please? just in case I screwed up and we need a new casper
<mvo> sure
 * mvo will just have lunch then :)
<pitti> . o O { the chroot upgrade on the amd64 buildd takes aages.. }
<pitti> congrats, armel beat amd64
<ogra> :)
<ogra> yeah, its the fjutscha :)
<pitti> accepted, publisher running
<pitti> ogra: wÃ¤rrie well
<pitti> WTH, publisher crashes
<pitti> mkdir: cannot create directory `/srv/launchpad.net/ppa': Permission denied
<pitti> seems more happy now
<jibel> ev, any idea about  bug 728205 when mswindows is the primary os ?
<ubot4> Launchpad bug 728205 in ubiquity (Ubuntu) "Ubiquity: there is no install "alongside other operating system" (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/728205
<ev> jibel: bug updated
<ev> apologies for the delayed responses.  I'm helping a Millbank intern get set up with our tools and trying to get caught up myself after being without a working computer for much of yesterday.
<wgrant> pitti: Were you running it without LPCONFIG set?
<pitti> wgrant: I think I did at first, yes
<wgrant> Great. Was hoping it wasn't some new issue :/
<pitti> Riddell: I'll set up a trigger for new casper, and rebuild Kubuntu desktop and DVDs
<Riddell> pitti: a trigger?
<pitti> wait-for-package
<Riddell> clever
<cjwatson> pitti: oh, the langpacks are on the livefs, so that would work yes
<pitti> cjwatson: wb
<cjwatson> pitti: I'm sure there's some other case that wouldn't, maybe something or other on the DVD
<pitti> cjwatson: so, the woes with OEM and Kubuntu is all due to the same bug, I updated it accordingly
<pitti> cjwatson: we figured the fastest way was to install a /media/cdrom -> /cdrom symlink (verified to work), I changed casper
<cjwatson> whoa
<cjwatson> um
<cjwatson> you sure that won't break things later?
<cjwatson> I knew it was all due to basically the same bug
<pitti> changing casper, ubiquity etc. for /media/cdrom seems like an awful lot of change and testing
<cjwatson> I was in the middle of figuring out a proper fix
<cjwatson> (though not for a3)
<pitti> cjwatson: it's only in the live system, not on the actual CD
<cjwatson> but the chroot needs to match
<pitti> it completely breaks Kubuntu, we can't release it like that
<cjwatson> which means you'll be installing a symlink in /media in the installed system
<cjwatson> which is going to get complicated
<jibel> ev, thanks
<cjwatson> the correct fix IMO is to install proper apt configuration during installation.  we already do this, it just needs to be updated
<pitti> cjwatson: I don't have a symlink in the installed system
<pitti> Riddell: ^ do you?
<cjwatson> then it still won't work entirely right, if you've done neither that nor the proper fix
<cjwatson> if it works well enough for Kubuntu, great
<cjwatson> but please don't close the bug
<pitti> it also works for OEM
<pitti> cjwatson: no, it's open, just moved to b1; I just added a casper task for a3 (the hack)
<cjwatson> yep, the casper hack sounds fine
<cjwatson> thanks for looking into that
<pitti> this should totally disappear again right after a3
<pitti> cjwatson: I still propose to not rebuild ubuntu CD/DVD; I'll document the sudo ln -s /cdrom /media/cdrom in teh release notes instead
<cjwatson> d-i and ubiquity do make assumptions about /cdrom, they're quite pervasive
<cjwatson> agreed
<pitti> cjwatson: ^ that's what I thought, too, and why we opted for the link
<cjwatson> I'm surprised Kubuntu broke hard, what's different there?
<pitti> cjwatson: presumably it always installs a package from the livefs repo
<pitti> hard to tell from the log, it doesn't say which package it's about to install
<cjwatson> Riddell: do you know?  I'm curious
<Riddell> I have no symlink /media/cdrom
<pitti> wait-for-package casper_1.259 && echo kubuntu desktop && buildlive kubuntu daily-live && (for-project kubuntu cron.daily-live &) && buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd
<pitti> is what I have queued now
<pitti> publisher finished
<pitti> builds started
<pitti> cjwatson: hm, seems installation of third-party software also breaks (bug 728360)
<ubot4> Launchpad bug 728360 in ubiquity (Ubuntu) "Natty 20110302, apt require insertion of /media/cdrom during a usb installation, causing lock and hard reboot (dup-of: 727783)" [Undecided,New] https://launchpad.net/bugs/728360
<ubot4> Launchpad bug 727783 in ubiquity (Ubuntu Natty) (and 3 other projects) "Installing packages from CD repository fails due to changed CD-ROM default mount point (affects: 7) (dups: 5) (heat: 50)" [High,Confirmed] https://launchpad.net/bugs/727783
 * pitti documents
<cjwatson> pitti: I can believe it
<pitti> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview#Known%20issues updated
<pitti> Riddell: http://cdimage.ubuntu.com/kubuntu/daily-live/20110303/ coming in
 * pitti adds to tracker
<pitti> Riddell: perhaps right after booting the live system you could check whether the symlink is okay?
<pitti> jibel: ^
<pitti> DVDs will still take a bit, grabbing quick lunch
<Riddell> yep
<Riddell> yes I have the symlink on the live CD
<jibel> skaet_, bug 728435 on server amd64
<ubot4> Launchpad bug 728435 in debian-installer (Ubuntu) "raid1 boot degraded mode fails (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/728435
<cjwatson> more likely to be mdadm, reassiging
<cjwatson> +n
<skaet_> good morning all
<cjwatson> pitti: I have a proper fix now :)
<jibel> Good morning skaet_
<skaet_> good morning jibel,  sorry for delayed response, catching up on the backscroll
<skaet_> Riddell, looks like we've got some new images for Kubuntu CD/DVD then.   cool.
<pitti> hey skaet_
<skaet_> pitti, cjwatson,  I talked to Rick about the OEM issue on Ubuntu last night as well, and he's ok with releasing with it as well (not happy, but ok ;) )
<cjwatson> it should be fixed comprehensively for b1
<pitti> skaet_: we have a simple workaround now, documented
<pitti> skaet_: I don't think it's worth a rebuild and retest
<skaet_> pitti, cjwatson - excellent
<cjwatson> I'm just completing a test of my changes, even without pitti's workaround
<cjwatson> they look successful
<skaet_> :D
<cjwatson> I see no reason not to leave pitti's workaround in place permanently anyway
<cjwatson> no harm in defence in depth
<skaet_> ok.
<skaet_> :)
<pitti> cjwatson: hm, I thought we'd move /cdrom to /media/cdrom consistently?
<cjwatson> and this is like the 10th time I've fixed this kind of bug, I really don't want to do it again
<cjwatson> pitti: that will take longer
<cjwatson> eventually, I guess
<pitti> ok
<cjwatson> but I'm in no rush
<skaet_> Anything stopping us from starting to publish the rest of the images (other than kubuntu dvd/cd) ?
<skaet_> Doesn't seem like there are any blockers ( lots of yuchs ) but...
<pitti> no
<pitti> skaet_: I was going to wait a tad more for the "ok" from Riddel for kubuntu desktop
<pitti> but I can just as well start now, and re-do the thing later in case it breaks
<skaet_> thanks pitti.
<pitti> skaet_: I updated TechOverview with the recent bugs, and made some corrections, FTR
<pitti> at least I can alread archive alpha-2, etc.
<skaet_> pitti,  :)  great!  It needed some corrections, lol.   Still some projects I'm waiting on input from before it will go out with the announce, but its starting to gel.
<skaet_> Need to do a pass through the current iso tracker, and add some more bugs to it as well. :P
<pitti> skaet_: that's what I did about two hours ago; I caught all but some extra LTSP ones, which I wasn't sure about (ran out of time due to the /cdrom issue)
<skaet_> pitti,  cool.   Will focus on that, and the bugs from the weekly agenda then.
<skaet_> pitti,  Riddell,  From the comments,  I'm infering that since Riddell will be having his hands full with Kubuntu images,  pitti will be running the push out?  (Riddell was on rotation for this cycle for the release engineering tasks).
<pitti> skaet_: yeah, doing
<pitti> skaet_: ah, I thought I was
<skaet_> pitti,  heh,  Riddell owes you beer/wine ;)
<Riddell> thanks pitti
<pitti> drwxrwxr-x  4 cdimage  cdimage  4096 2011-03-02 08:43 www.prev
<skaet_> Riddell,  how long do you estimate it will take to test out the new Kubuntu images?
<pitti> ogra, Riddell, cjwatson ^ looks like someone wanted to start pre-publishing this morning already? can I wipe this?
<ogra> wasnt me
 * ogra makes an innocent face
 * skaet_ has kept her paws out as well
<jibel> skaet_, kubuntu amd64 are done, wubi failed without surprise, pedro is on i386 and I'm starting DVD
<cjwatson> not I
<Riddell> I've done an install with both amd64 and i386 kubuntu CDs, working fine
<cjwatson> pitti: that was yesterday morning though, from the timestamps
 * skaet_ had better head back into editing the tech overview... sounds like we may get this pushed out earlier rather than end of day for a change.  ;)
<pitti> Riddell: \o/
<skaet_> Riddell: yay!
<skaet_> jibel,  thanks!
<Riddell> skaet_: did claydoh update the tech overview for Kubuntu?
<skaet_> Riddell,  yup changes went in last night from him,  but feel free to review/update.  ;)
 * skaet_ was planning on having to add words about the Kubuntu CD/DVD not shipping, but is glad that will no longer be the case
<Riddell> all thanks to the debugging work of pitti and mvo
<ev> skaet_: I've added about about the installer partitioning redesign to the notes, at the request of robbiew.  Feel free to tweak or move that around.
<skaet_> ev, thanks!
<ev> sure thing
<pitti> images published, starting the Big Mirror Sync
<pitti> took a while, sorry; botched the first try (had to fix a bug in ./publish-image-set.py)
<pitti> smoser: can you please publish the milestone UEC images on uec-images.ubuntu.com?
<pitti> (or did you already?)
<smoser> ie, make public ?
<smoser> pitti, ^
<pitti> smoser: yes
<pitti> smoser: (if they are alright, but seems so)
<smoser> yeah.
<pitti> smoser: I'm publishing the other images to cdimage.u.c. now
<pitti> skaet_: I cleaned up https://bugs.launchpad.net/ubuntu/natty/+bugs?field.milestone=33573, now bug 693671 is the only one left
<ubot4> Launchpad bug 693671 in Ubuntu Natty (and 3 other projects) "wubi install will not boot - phase 2 stops with: Try (hd0,0): NTFS5 (affects: 6) (dups: 2) (heat: 81)" [Critical,Confirmed] https://launchpad.net/bugs/693671
<pitti> but I guess it's not gonna happen for a3, so we'll just declare wubi broken for a3?
<skaet_> yes,  it was broken for A2 as well, so we'll need to consider it broken again....
 * skaet_ is looking forward to the fact that now that the features are in,  some of these ugly bugs will get some love. ;)
<pitti> ok, a3 list is empth herewith
<skaet_> \o/
<jibel> skaet_, bug 717166 on UEC
<ubot4> Launchpad bug 717166 in eucalyptus (Ubuntu Natty) (and 2 other projects) "Broken with v4 isc-dhcp-server in Natty (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/717166
<skaet_> Thanks jibel.
<jibel> kubuntu dvd amd64 is fine. kubuntu desktop i386 looks good too (1 test remaining)
<skaet_> slangasek, around?
<skaet_> pitti, Riddell, cjwatson, can you review http://paste.ubuntu.com/575030/  I'm thinking we should probably also mention Unity's version here as well as a new package, thoughts?  Any other significant packages I missed?
<cjwatson> seems reasonable
<cjwatson> (to mention Unity's version)
<pitti> skaet_: looks fine to me; as unity is a highly focussed component in natty, I agree to add it here
<doko_> if I start a rebuild of the gcc-4.5 version in natty on i386, it fails to build with:
<doko_> Unsupported CPU used in --with-cpu=, supported values:
<doko_> generic atom core2 nocona x86-64 amdfam10 barcelona k8 opteron athlon64 athlon-fx athlon64-sse3 k8-sse3 opteron-sse3
<doko_> make[4]: *** [configure-stage1-gcc] Error 1
<doko_> so something seems to be broken ...
<pitti> skaet_: ugh @ https://launchpad.net/ubuntu/+milestone/ubuntu-11.04-beta-1 ..
<skaet_> pitti, cjwatson - Unity 3.6.0 is the one I'm spotting from -changes.
<pitti> skaet_: confirmed
<skaet_> pitti, re ubuntu-11.04.beta-1 - yeah,  and they don't have the unmilestoned ones, that need to still be sorted by the end of the release.  :P
<skaet_> s/sorted/fixed/
<jibel> skaet_, what's Kubuntu Netbook Arm (omap) (rebuilding...) on the tracker ? what the status of this image ?
<skaet_> doko,  urk, looks like some misconfiguring.   is there a bug?
<skaet_> jibel,  decision was made yesterday that that wouldn't be rebuilt.  Should have removed it.  Sorry.  Please go ahead and do so.
<jibel> skaet_, k
 * doko_ curses the person who uploaded bash, which seems to be broken
<cjwatson> who might that be? :)
 * pitti fixes bad CamelCase wiki links on TechOverview
<pitti> skaet_: looks good to me, should we just drop the software-center todo?
<skaet_> pitti,  yeah.
<pitti> skaet_: done
<GrueMaster> Sorry about the kubuntu armel rebuild confusion.  I made the call to have it rebuild with the temprary ubiquity-slideshow fix in the hopes that it would make the image workable, but it appears to have other issues.
<GrueMaster> I was working with the 301 image that I manually hacked to resemble what would have built last night.  Fails badly though.
<skaet_> GrueMaster, thanks for the explanation.  :)
 * skaet_ is sorry it didn't work out though...
<GrueMaster> I'll do a quick test on it to make sure it wasn't my hacked image, but I seriously doubt it (all I did was remove ubiquity-slideshow-*).
<pitti> skaet_: sync complete; all image links on https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview confirmed to work
<pitti> iso image that is (not pictures)
<skaet_> *\o/*
<pitti> can we lift the archive freeze?
<skaet_> ok,  waiting for some final reviews of the contents of the TechOverview to come in,  and then I'll press send on the announce.
<skaet_> yes,  we can lift archive freeze.  :)
<GrueMaster> What, it was frozen?  Then how did samba update slip through, delaying our rebuild by two hours?
<pitti> it shouldn't have happened
<pitti> (the upload)
<pitti> it's in #u-devel topic, planet, and u-d-announce@..
<cjwatson> GrueMaster: soft freeze, it relies on developers honouring it
<cjwatson> (the alternative was bad in other ways)
<GrueMaster> Ah.
<highvoltage> I'm putting together the pieces for the alpha 3 announcement on the edubuntu site: http://edubuntu.org/2011-03-03/edubuntu-1104-alpha-3-released - Let me know if I'm missing anything important!
<ogra> GrueMaster, you earned beer from the person doing the upload though ;)
<GrueMaster> Beer==good.
<ogra> freeze breakage generally requires beer compensation
<GrueMaster> (Lots of beer)==(complete absolution)
<GrueMaster> skaet_: Kubuntu armel image broken as predicted.
<slangasek> skaet_: pong
<pitti> skaet_: cdimage cronjobs back on, FTR
<skaet_> slangasek,  hi, could you take a look at the TechOverview and make sure my discussion of dpkg is accurate.  Also, any other new packages that should have been highlighted?
<skaet_> pitti.  thanks!
<slangasek> skaet_: full link?
<skaet_>   https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
<slangasek> thanks :)
<slangasek> well, moin doesn't like git uris I see
<slangasek> skaet_: tweaked the language a bit, let me know how that looks to you
 * skaet_ looking
<skaet_> slangasek,  looks fine.  Thanks!
<pitti> skaet_: do you need anything from me in the next hour? if not, I'd like to go AFK a bit and reinstall my main workstation
<skaet_> pitti,  I think we're good.   Just starting to coord with the web team now, and pick up the last edits.
<pitti> skaet_: ok, good luck with the rest then!
<pitti> *uff* what day .. or three of 'em
 * skaet_ nods
<Riddell> Kubuntu CDs and DVDs seem good to publish
<Riddell> ah good, already in
<Riddell> skaet_: ETA on release?
<bjf> skaet_, at an archive admins convenience, could the linux-firmware packages for lucid and maverick get promoted from -proposed to -updates ?
<skaet_> Riddell, all edits are in now,  (that I was expecting ;) ) so I think we'll be released shortly.
<Riddell> bjf: that's something that needs approval from ubuntu-sru
<skaet_> bjf,  pitti will probably be back in a bit.
<pitti> bjf: they didn't get any testing feedback
<bjf> pitti, tim just marked them tested
<pitti> bjf: done
<pitti> and with that, good night everyone!
<bjf> pitti, thanks
<skaet_> pitti, cjwatson, Riddell, slangasek, NCommander, ogra  - Announce has been sent out and web site updated.  Thanks for the awesome work this week getting those images stabilized and usable!
<slangasek> skaet_: great, thanks - and apologies for my role in derailing that stabilization with dpkg... :)
<marjo_> skaet_ congrats! thx to all
<ogra> skaet_, we only followed a great leader ;)
 * highvoltage hits publish button on edubuntu alpha 3 blog post
<skaet_> lol
 * skaet_ is still in awe at the teamwork shown through this week to actually get images out the door.   you guys rock!
<skaet_> slangasek,  you probably owe cjwatson and pitti some beers ;)    Am just delighted it all came together, esp with getting Kubuntu resolved and ARM images as well.   whew!  such a different place from Tuesday morning.
<slangasek> skaet_: yes, I think I do at that
<jdstrand> skaet_: hey. so wrt bug #727478, the bug is now triaged and a fix being prepared
<ubot4> Launchpad bug 727478 in mysql-5.1 (Ubuntu Natty) (and 4 other projects) "mysql upgrade hang at 'installing new version of config file /etc/init/mysql.conf' during upgrade from 10.10 to 11.04 (affects: 1) (heat: 3498)" [High,Invalid] https://launchpad.net/bugs/727478
<skaet_> jdstrang,  just looking at it.   Glad you found the root cause.    Very good to get that fixed.  :)
<slangasek> cjwatson: who's owning plymouth this cycle?  (bug #728611)
<ubot4> Launchpad bug 728611 in plymouth (Ubuntu Natty) (and 1 other project) "[natty] text does not display in plymouth (disk check, passphrase prompts) (affects: 2) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/728611
<slangasek> hmmm, I hope it's not related to the new upstream freetype
<cjwatson> no particularly strong ownership, I've been trying to hoover some things up though
<cjwatson> in my copious free time :-/
<slangasek> yep
<cjwatson> I'm happy to look at that one
<cjwatson> well, "happy"
<slangasek> or could someone else on foundations look at it?
<cjwatson> dinnertime
<cjwatson> well, I might pass it to jhunt
 * slangasek nods
<skaet_> jdstrand,  sorry 'bout the typo in your nick.   ^^
<slangasek> cjwatson: timing-wise, the appearance of this bug comes very close to a new upstream version of freetype, and I've seen other contexts where text is not being rendered with freetype 2.4.4, so maybe that's a useful avenue of investigation (and one that lets you reassign the bug back to me ;)
<jdstrand> skaet_: well, *I* didn't find it. I am just the messenger :)
<jdstrand> skaet_: but I will be doing the upload
<skaet_> :)
#ubuntu-release 2011-03-04
<doko> ScottK: gcc-4.5 test packages available in the ubuntu-toolchain-r PPA. feedback appreciated
<ScottK> doko: I'll see if I can get someone to test them.
<pitti> skaet_, slangasek: (dpkg) that's fine -- after all, I actually said I'd want it for a3, to give it more testing :)
<ScottK> doko: I'm told if we built qt4-x11 with gcc4.5 and then build phonon or kde4libs a build success will be indicative of success.  Could you grab qt4-x11 from the archive, drop the bit that forces it to gcc4.4, and upload it to the toolchain PPA?
<cody-somerville> lamont, Has mksquashfs ever hung before that you know of (with regards to Ubuntu image builders)?
<lamont> cody-somerville: not that I've seen
<rww> Hi. Did Ubuntu Alpha 3 come out? I don't see an email about it on the ubuntu-devel-announce web interface, but people keep saying it has :(
 * rww throws a 'Natty' in there somewhere
<charlie-tca> rww: announcement might be stuck in the queue
<charlie-tca> here is the one to qa, though:
<charlie-tca> https://lists.ubuntu.com/archives/ubuntu-qa/2011-March/001458.html
<charlie-tca> ubuntu-devel-announce does not have this yet
 * slangasek pushes it through
<rww> slangasek, charlie-tca: Thanks :)
<slangasek> rww: thanks for letting us know!
#ubuntu-release 2011-03-05
<stgraber> hmm, there's something wrong with the livefs builder ;)
<stgraber> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/20110305/livecd-20110305-amd64.out
<stgraber> guess I'll have to wait till Monday to get a new edubuntu build ;)
<stgraber> lamont: ^ (in case you're around)
<lamont> stgraber: sigh
#ubuntu-release 2012-02-27
<stgraber> Could someone from -cdimage apply http://paste.ubuntu.com/858701/ to the debian-cd branch and respin Edubuntu?
<stgraber> I believe that's the missing change to make wubi appear on Edubuntu
<stgraber> pitti: good morning. As I'm going to sleep soon, I just wanted to mention bug 939450 as something we probably want fixed for beta1. It's assigned to ubiquity but I tracked it down to gtk's atk-bridge module. I poked TheMuso on IRC and subscribed him to the bug (so far no response)
<ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
<infinity> stgraber: Hrm.  So, every live image gets add_winfossed now?
<stgraber> infinity: looks like it
<stgraber> infinity: well, at the moment, any of them except for Edubuntu ;)
<infinity> stgraber: What about the next stanza down?
<stgraber> infinity: that's old code for when Edubuntu was an addon CD on top of Ubuntu
<infinity> stgraber: Was that a mistake, or do we really want edubuntu alternates to also get that (and nothing else)?
<stgraber> infinity: back then (before lucid IIRC) it was actually working
<stgraber> it just never got updated when we switched to DVD apparently
<infinity> Should I remove that bit while I'm in there?
<stgraber> yep
<infinity> Well, your diff didn't have that part. :P
 * infinity fixes.
<stgraber> there's also code for that bit in ubuntu/tools/add_winfoss if you want to get rid of it there too
<infinity> if [ "$PROJECT" = edubuntu ] && [ "$CDIMAGE_ADDON" != 1 ] && [ "$CDIMAGE_DVD" != 1 ]; then
<stgraber> (the whole CD=cd2 stuff where $CD isn't actually used anywhere ;))
<infinity> ^-- That bit?
<stgraber> yeah that one, it doesn't seem relevant anymore and the variable isn't used (unless the script is sourced)
<infinity> Sure, the variable is used.
<stgraber> well, actually it's but for some old FOSS stuff we don't ship for a while
<infinity> Yeah.
<infinity> http://paste.ubuntu.com/858747/
<stgraber> I doubt we still have any media shipping with firefox/thunderbird 1.0 :)
<stgraber> looks good to me
<infinity> Yeah, probably not.  But removing one feature per commit (ie: edubuntu addon CDs, in this case) is sane.
<infinity> I could remove the old FOSS bits in another run.
<infinity> stgraber: Alright, committed and pulled.
<infinity> stgraber: Did you need a respin?
<stgraber> yep, a respin would be great so I can make sure wubi now works fine
<infinity> Incoming.
<stgraber> thanks
<infinity> I have an empty M&Ms bag taunting me.
<infinity> "Adam you want more of us, go to the store, get fatter..."
<infinity> Jerk M&Ms.
<stgraber> heh
<ScottK> superm1: Is mythbuntu still using mysql5.1?  There's an upload in queue and it'd be good to know if you need it in for beta 1?
<stgraber> pitti: just got an answer from Luke, he's having a look at the bug, I'll see what's the status when I wake up tomorrow then
<superm1> ScottK: 5.5 now
<ScottK> superm1: OK.  5.1 is still in your packageset, you might want to get that changed.
<micahg> that should be an autogenerated packageset
<micahg> ScottK: superm1: it's not shown as seeded, so the next time the packageset update scripts are run, that should be fixed
<ScottK> Someone should do that.
<ScottK> This is probably a good time.
<micahg> well, the person who normally does that is on vacation and I"m not sure anyone else knows how :)
<micahg> hmm, I still have to fix Ubuntu Studio images, don't I...
<infinity> stgraber: Builds should be done, BTW.
<infinity> Daviey: Why are we fixing mysql-5.1 instead of just dropping it from the archive?
<infinity> Daviey: Does it still have rdeps?
<infinity> Daviey: And if so, why? :P
 * pitti checks the universe syncs in unapproved
<Riddell> morning
<pitti> hello Riddell, how are you?
<Riddell> bright and breezy
<pitti> FTR, my poppler and v4l-utils uploads can wait until after b1
<micahg> Riddell: would you be ok respinning powerpc images for Firefox powerpc (I can do the build in a PPA to prevent arch skew)
<Riddell> micahg: you want images with a PPA enabled?
<micahg> Riddell: no :), I can have them copied once they're built on all archs
<Riddell> micahg: can PPAs do powerpc or that would only stop i386/amd64 being skewed?
<micahg> Riddell: no, I'd build it in one of the security PPAs, so I'd get all archs
<pitti> micahg: but, we would lose all 0 testing results!
<micahg> pitti: :)
<micahg> Riddell: I think it's just the Ubuntu powerpc image that's affected
<pitti> micahg: IOW, I see little problem with this -- there is very little, if any, interest in those images anyway
<Riddell> micahg: is the package diff one that can only affects powerpc?
<pitti> I can't remember when we actually released a milestone ppc image the last time
<micahg> pitti: oh, if we're not releasing the images, I won't bother
<Riddell> micahg: ah you're not expecting to test the images as well?
<pitti> micahg: well, if someone tests them, we can
<micahg> I don't have hardware, I'd just prefer the image not to ship with Firefox 100
<micahg> *Firefox 10.0
<Riddell> micahg: if you've a foolproof plan to build the packages and copy them over that's good with me
<Riddell> but it might well not be worth it indeed
<pitti> micahg: yeah, I'd just commit the fix to bzr and let the next regular upload sort it out
<infinity> micahg: I plan to test and release Beta2 and Final on PPC, but I have no idea if anyone's testing Beta1.
<micahg> infinity: alright, I'll skip this round (I have enough to do anyways)
<Riddell> pitti: whoopsie-daisy has been in the queue for 17 hours, does that mean it's not to be accepted?
<pitti> Riddell: I don't know
<pitti> but at this point I only accept stuff which isn't seeded or links to RC bugs
<pitti> unless people (hello ev) poke me about it
<pitti> but everything that's seeded requires an image respin
<pitti> Riddell: if we get an ubiquity upload or other reason for respin, I think it's fine to accept along, it's a small and quick build
<Riddell> that's logical
<Riddell> does anyone know if bug 940908 affects all images or just kubuntu?
<ubot2`> Launchpad bug 940908 in console-setup "Cannot localize keyboard at startup in live session" [Undecided,Confirmed] https://launchpad.net/bugs/940908
<pitti> Riddell: unknown, I'll test
 * pitti rsyncs latest image
<pitti> I fixed the python3 priorities over the weekend and respun
<pitti> we are still about 1 MB oversized if you consider 703 MB the real physical limit
<pitti> Daviey: is http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html on your radar? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg is an alternative view for the new dependencies in universe)
<Riddell> pitti: http://cdimage.ubuntu.com/daily-live/20120225/ says ubuntu i386 is 708MB, surely that's lots oversized?
<Riddell> kubuntu i386 is 700MB and that still gets the oversized warning
<pitti> Riddell: http://cdimage.ubuntu.com/daily-live/20120226/
<pitti> Riddell: that's what I meant with "respun over the weekend"
<Riddell> oh I'm behind the times :)
<pitti> Riddell: yes, cdimage's limit is still 700 MiB, but we determined that you can actually put on 703 on pretty much every burner/media
<infinity> pitti: Speaking of checking scripts.  Is your new and fancy NBS stuff actually checking the whole archive, or just main, or..?
<pitti> infinity: whole archive of course
<pitti> infinity: oh, hang on
<Riddell> pitti: ok so kubuntu i386 is fine, but kubuntu amd64 isn't
<pitti> infinity: .svg is only source promotions
<micahg> pitti: hpijs can save you 5k :)
<pitti> infinity: .txt is the whole archive
<infinity> pitti: Cause I've done some NBS removals over the last week that weren't represented in your output.
<infinity> pitti: NBS, not mismatches.
<pitti> infinity: I'm confused again; .txt/svg was component-mismatches
<pitti> infinity: anyway, http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> this covers the whole archive
<pitti> oh, we can do some removals, /me runs
<infinity> Yeah, then I think it might be inaccurate.  The next time I run across something it doesn't show, I'll bring it up.
<pitti> on Friday we were down to libcegui-mk2-1 and the lightdm greeter which needs packaging
<infinity> I should have done so a few days ago, I guess. :/
<pitti> infinity: do you still remember what you removed?
<pitti> I'm watching it fairly closely and didn't notice oddities
<micahg> pitti: if we could drop libdb4.8, that would do it :)
<pitti> infinity: c-m and perhaps NBS was a bit broken last week because germinate didn't update
<pitti> but that got fixed
<pitti> micahg: oh, I thought I did already, let me check
<pitti> micahg: oh, I only fixed unity-lens-applications upstream, but it didn't land in ubuntu yet
<infinity> lp-remove-package.py -u adconrad -s precise -b libreoffice-report-builder-bin -m 'NBS'
<pitti> infinity: that indeed went away
<infinity> ^-- I don't think it showed me this before I removed it.  But that might have been me just being impatient.
<pitti> now the openoffice.org transitional source needs fixing
<infinity> pitti: But I was sure I remembered something else.
<infinity> pitti: Yes, I know it went away, I removed it. :P
<pitti> I mean from the report
<infinity> pitti: My point was that it didn't show on any reports. But I may have just been impatient.  I dunno.
<micahg> pitti: that looks like it would do it for the desktop image
<infinity> (And that's not the package I was thinking of, but danged if I can remember what I was actually concerned about)
<pitti> infinity: it definitively was there earlier last week
<infinity> Oh well.
<pitti> report-builder-bin I mean
<infinity> pitti: Anyhow.  Ignore me until I notice an oddity and bring it up real-time, I guess. :P
<infinity> pitti: Maybe it's just that I am/was unclear on how to read the new and shiny html output.
 * Riddell accepts universe package v4l-utils
<pitti> Riddell: ^ that's in main and on pretty much all images, FYI
 * Riddell doesn't accept
<pitti> not sure how worried we are about packages being out of date on beta-1 images
<micahg> [02:25] -queuebot/#ubuntu-release- New package: v4l-utils (main) [0.8.5-6ubuntu1 => 0.8.6-1ubuntu1] (core)
<Riddell> mm, never trust apt-cache show v4l-utils when working out if it's in main or universe
<pitti> the binary is indeed
<micahg> Riddell: you either want apt-cache showsrc or rmadison
<pitti> ^ fixes ratings in unity, and drops libdb4.8
<pitti> if we are in a respinning mood, it's a good thing to include IMHO
<Riddell> micahg: yeah I know
<pitti> (- 700 kB)
<tumbleweed> or seeded-in-ubuntu, for the general question of: Will this upset ISOs
<Daviey> pitti: it is indeed.
<Daviey> infinity: it seemed smarter to apply a 1 line change, closing a bug.. before investigating further WTF we still have it.
<micahg> Riddell: I'm working on Ubuntu studio ATM, hopefully we should be able to respin the images in a few hours
<Riddell> micahg: nice
<pitti> Riddell: FWIW, bug 940908 was reported against ubuntu, not kubuntu
<ubot2`> Launchpad bug 940908 in console-setup "Cannot localize keyboard at startup in live session" [Undecided,Confirmed] https://launchpad.net/bugs/940908
<Riddell> pitti: ok that's good to know, I guess that's the "LiveMediaBuild" in the bug report
<micahg> Riddell: do we need to update lightdm-gtk-greeter for beta 1 or can we do that after beta 1?
<Riddell> micahg: well I already screwed that one up, what's the reamining issue?
<Riddell> micahg: still the wrong source package?
<micahg> Riddell: you didn't remove the one binary that's not easy to upload :)
<micahg> and please don't :)
<micahg> Riddell: the binary is NBS, but working, apparently, we need a merge of the Debian SVN with the old lightdm configurations
<micahg> so, mr_pouit prepared a package based on the last lightdm with with the greeter that I have to merge with the one I was preparing from Debian SVN
<Riddell> micahg: well it's probably not any gain for beta 1 at this stage
<micahg> right, that's what I figure, and if it breaks images at this point I would think that would be a negative
<micahg> I'll try to have it ready tomorrow night in case we need it, but I'd suggest keeping the current binary for beta 1 if it's working
<Riddell> is it bad protocol to accept my own upload from unapproved? (plasma-mobile)
<Riddell> micahg: quite a lot in that ubuntustudio-default-settings, you're wanting it in presumably?
<Riddell> vim seems to be a merge, assuming it's unimportant unless we get poked
<micahg> Riddell: yeah, but maybe wait until the lightdm package is ready as well, I'd like the meta to hit as close as possible to those 2 packages hitting the archive
<Riddell> someone accepted bzr-loom ?
<Riddell> " 3816792 | X- | bzr-loom             | 2.2.0-1              | 4 minutes"  hmm, remind me again what that X is for archive admins?
 * Riddell accepts his own plasma-mobile
<micahg> Riddell: AIUI, that's not good practice
<jibel> could bug 926859 be fixed for B1, it makes testing in VMs very painful
<ubot2`> Launchpad bug 926859 in unity "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Confirmed] https://launchpad.net/bugs/926859
<Riddell> micahg: probably not, but I can't really screw up kubuntu active, it doesn't exist yet :)
<Riddell> jibel: ask the unity team to upload a fix and we can let it in if we decide to respin?
<jibel> Riddell, k
 * Riddell accepts unity-mail into universe
<jamespage> good morning: please could someone review/ack/nack FFe bug 937632
<ubot2`> Launchpad bug 937632 in jenkins "[FFe] Please sync jenkins-instance-identity 1.2-1, jenkins-ssh-cli-auth 1.2-1 from Debian unstable" [Medium,In progress] https://launchpad.net/bugs/937632
<Riddell> jamespage: you're not wanting this for beta 1 but for post-beta1?
<jamespage> Riddell, post-beta1 is fine (my jenkins upload to Debian to enable this functionality is currently blocked on another isssue anyway)
<Riddell> well unseeded universe package anyway
<jamespage> well yes
<jamespage> :-)
<pitti> I cannot confirm bug 940908, asked for more info
<ubot2`> Launchpad bug 940908 in ubiquity "Cannot localize keyboard at startup in live session" [Undecided,Incomplete] https://launchpad.net/bugs/940908
<Riddell> jamespage: those are security related modules, any possible security issues?
<jamespage> Riddell: they have been in Jenkins upstream for some time; I have done some testing which looks OK to me
<jamespage> and they only expose the jenkins functionality so its fairly well sandboxed...
<Riddell> ok fine with me
<Riddell> pitti: for FF exceptions I just comment on the bug or any status I need to set as well?
<jamespage> Riddell, thanks - do you want me to wait until after beta-1 to sync?
<Riddell> jamespage: should be fine anytime after pitti confirms I'm following correct protocol
<jibel> stgraber, is bug 936115 on your list ?
<ubot2`> Launchpad bug 936115 in ubiquity "ubiquity crashed with TypeError in partman_popup(): popup() takes exactly 7 arguments (6 given)" [High,Triaged] https://launchpad.net/bugs/936115
<pitti> Riddell: approving an FFE usually means New -> COnfirmed
<Riddell> pitti: ok, it's in progress anyway so I'll just comment
<pitti> Riddell: or -> Incomplete if there's something missing or questionable (or Wontfix if it's clearly out of line)
<micahg> Riddell: can I get both ubuntustudio packages please?
<micahg> unless there's a problem with them
<Riddell> micahg: is the lightdm package you wanted in?
<micahg> yeah, ubuntustudio-default-settings and ubuntustudio-lightdm-theme
<Riddell> oh aye
<micahg> after they're published, I"ll respin the meta
 * Riddell cranks handles
<micahg> Riddell: can the 2 ubuntustudio packages be deNEWed please?
 * Riddell cranks more handles
<seb128> micahg, they have been already from the changes list
<micahg> seb128: binary NEW :)
<seb128> oh ok
<seb128> ^ gconf-editor would be good to get, the current version is almost impossible to use without hitting a segfault due to gtk changes
<seb128> the actual diff is trivial, just adding block_signal and unblock_signal around the model update function to avoid having callbacks triggering when the model is being updated, the diff is a bit less trivial because I moved a function to be after the one it blocks
<Riddell> seb128: is that on the CD?
<Riddell> oh no, universe?
<Riddell> yes
 * Riddell cranks handles
<seb128> Riddell, thanks
<seb128> yeah, universe, it's old gconf... ;-)
<Riddell> old but the only way to get gnome to act as you want it to I hear </nasty-troll> :)
<seb128> Riddell, ;-)
<seb128> Riddell, well "old" in sense of "deprecated by gsettings, dconf-editor"
<seb128> which is the new way to get gnome to act as you want ;-)
<Riddell> didrocks: do we want that nux?
<didrocks> Riddell: yes please, it forces running unity-2d if you are using llvmpipe
<didrocks> Riddell: it's particularly the case if you run in a vm
<didrocks> (otherwise, ,you end up in an empty session as unity-3d doesn't support it)
 * Riddell accepts apt-cacher-ng
<Riddell> didrocks: is it on the CD?
<didrocks> Riddell: it is, if you look at the linked bug, it's just been targeted for this beta by jibel
<didrocks> (I reset the target on nux instead of unity)
<seb128> Riddell, if you accept stuff on the CD can you accept gnome-desktop3 and indicator-appmenu?
<Riddell> didrocks: so it would need a respin
<seb128> they are both trivial diffs and small packages for builders
<seb128> Riddell, it's worth a respin
<Riddell> I guess it's up to the ubuntu desktop masters if you guys want that
<pitti> if we respin, we should also accept two others; do we?
<didrocks> Riddell: right, I think jibel was proposing that for that issue
<seb128> jibel said the current images can barelly be tested in a vm dur to it
<seb128> dur->due
<Riddell> pitti: seems didrocks and seb128 are for it, and I'm in no position to argue with the French (last time I did I ended up in hospital!)
<pitti> heh
<seb128> lol
<pitti> Riddell: so it seems so far we don't have a real dealbreaker, but a handful of "nice to have"s?
<pitti> but it's still early, so I'm fine with a respin
<didrocks> Riddell: heh ;)
<Riddell> that'll be ubuntu desktop and edubuntu images
<pitti> libjpeg8-empty adds a new libjpeg-dev which will unbreak upgrades
<Riddell> ok let's do this
<pitti> it doesn't change any actual bits
<pitti> so I'd recommend accepting it now for upgraders
<micahg> Riddell: can you free ubuntustudio-meta, then watch for binNEW when it's done, then kick off a rebuild for Ubuntu Studio once they're published (I would like to go to sleep now :))
<pitti> -empty only builds empty metapackages
<pitti> Riddell: ack, accepting the other two then
<Riddell> micahg: will do
<micahg> Riddell: thanks
<pitti> i-appmenu looks straightforward, pulling this in, too
<Riddell> what is Ubuntu Core?
<NCommander> pitti: I'm going to kick a new d-i install the queue to correct a bug with the armadaxp kernel (typo on mkimage causes a non-booting kernel)
<pitti> g-desktop3 is trivial as well, accepting
<pitti> NCommander: ack
<NCommander> pitti: its a oneliner, I cleared it through skaet on Firday
<pitti> Riddell: it's a minimal chroot tarball
<pitti> Riddell: I'm not entirely sure what it is being used for, it started out from the  arm team
<Riddell> NCommander: what new images does that need?
<NCommander> Its not used as the basis of any image as of writing; its designed as a minimal environment to use Ubuntu in embedded or highly customized installs
<pitti> Riddell: it's standalone, it just needs to be rebuilt by itself (and it's rather quick)
<Riddell> NCommander: and someone will test it before we release?
<NCommander> Riddell: I'll poke QA, not sure who is handling this anymore
<ogra_> Riddell, ubuntu-core is the output of debootstrap --minbase plus teh installation of apt and its deps (and then tarring that up)... if that wouldnt work, all other images would fail :)
<ogra_> i dont think there is a particular need to test it
<ogra_> as long as normal images build and apt works on them at least ;)
<Riddell> what is this error all about? http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-active/precise/daily-live-20120227.log
<Riddell> Couldn't open file: /srv/cdimage.ubuntu.com/scratch/kubuntu-active/daily-live/tmp/precise-i386/indices-non-US/md5sums at /srv/cdimage.ubuntu.com/debian-cd/tools/fast_sums line 32.
<Riddell> find: File system loop detected; `./ubuntu' is part of the same file system loop as `.'.
<Riddell> both those errors seems to be in the main kubuntu logs as well which carry on and complete
 * NCommander punks d-i into incoming
<NCommander> *punts
 * Riddell lunches
<Daviey> ScottK: I did check mysql-5.1 mythbuntu seed before uploading :)
<ScottK> Daviey: OK.  It was still in the packageset (which is what shows up in the LP U/I).
<NCommander> pitti: Riddell can you accept d-i?
<Daviey> ScottK: also shows to be in core, but it aint :)
<ScottK> Right, but it was in Universe, so I knew that was out of date.
<Riddell> NCommander: let me look
<Riddell> NCommander: and what respins will be needed with this?
<NCommander> Riddell: none. armadaxp netboot only is the only change
<Riddell> NCommander: what actually is armadaxp?
<doko> please accept both openjdk-6 and openjdk-7. the multiarch installation issue wasn't fixed in the Friday upload
<Riddell> doko: respins needed?
<doko> Riddell, openjdk-7 is universe, openjdk-6 on the DVD images
<NCommander> Riddell: we've got a fair bit of uninstallable packages and oversized CDs :-/
 * NCommander just saw the daily health report email
<ScottK> Since there was just a new DI, DVDs will need respun anyway.
<Riddell> ScottK: if we're not caring about the version alignment then that DI shouldn't affect DVDs
<ScottK> Are we to the point of not caring?
<Riddell> NCommander: mostly arm and unity isn't it?
<Riddell> ScottK: I don't know, why should we care?
<NCommander> Riddell: problems has nova and glance; daily health says they're uinstallable on ubuntu-server/daily :-/
<ScottK> Generally I thought we tried to have the archive and the images match.
<Riddell> Daviey: ^^
<Riddell> ScottK: I'm not sure how immportant that is on betas, we'll be uploading as soon as they're released anyway
<pitti> NCommander: yes, Daviey knows and they are on it;
<Riddell> NCommander: and nux?
<ScottK> Dunno.
<NCommander> pitti: well, looking at glance, its just a matter of promoting python-iso8601 it seems
<Riddell> ubuntu dvd will be needed anyway
<pitti> NCommander: yes, they will need 3 MIRs or drop the new dependencies again
<Riddell> ok letting openjdk in and respinning dvds
<NCommander> pitti: ok,is anyone handling trying to reclaim 4 MiB from the image?
<pitti> NCommander: the next builds should shrink by 700 kB
<pitti> NCommander: so amd64 should be OK at < 703 MB (which is our new limit)
<NCommander> pitti: seems you are far more on top of this than I :-)
<pitti> NCommander: i386 might still be a tad oversized
<pitti> but I'm not sure we can solve this properly by b1; do we care?
<NCommander> if i386 is still oversized, I'll see where we can cut some fat.
<Riddell> NCommander: 8 from kubuntu amd64 please!
<Riddell> for some reason
<NCommander> Riddell: I'll poke around and see what we can cut
<NCommander> Riddell: openoffice.org-hyphenation any idea why that's on the kubuntuCD?
<Riddell> NCommander: we seed it in live?
<NCommander> Yes, but what are you using it for?  OOo's modules are really big
<Riddell> I don't know, does open office use it for hyphenation?
<NCommander> oh, bah, I forgot libreoffice is in kubuntu.
 * NCommander hasn't reinstalled kubuntu from scratch in eons
<Riddell> it's also only 305kiB
<Riddell> NCommander: we saved a lot by removing amarok docs, I expect there are other docs that can be removed
<Daviey> Riddell: it's known, zul is ONE THE CASE, and will ping jdstrand for some help when he is alive for they day
<NCommander> Riddell: I'm just suprised the entirity of OOo is there; one would think some of the submodules (i.e. OOo draw) could be dropped from the livecd
<Daviey> Riddell: requires a handful of MIR's.
<NCommander> Daviey: I can look over any MIRs
<Daviey> NCommander: Okay, sounds great.
<Daviey> zul: have you raised the MIR's yet?
<Riddell> NCommander: oh it's still for python 3 on the CD maybe a respin would help
<Daviey> NCommander: they seemed to all be quite trivial.
<Riddell> pitti: how much does python 3 dropping save?
<zul> Daviey: ive stated it, when i actually get in they will be done
<Daviey> zul: rocking.
<Riddell> "Modify debian-cd/CONF.sh to set OFFICIAL" hmm what does that do?
<Riddell> I've only just done it, does it require a respin for images?
<ScottK> Riddell: IIRC Python3 is 4 or 5 mb
<Riddell> ScottK: that sounds like it would help our amd64 nicely
<NCommander> Riddell: I believe that OFFICIAL is a deep-voodoo from Debian
<NCommander> It causes images to have official branding and such. I don't remember ever manually setting it, but infinity/skaet probably know better
<Riddell> well looks like most things are being respun anyway
<Riddell> pitti: nux is in, what else did you let through that we want on the respin?
<Riddell> libjpeg in as well
<seb128> Riddell, the other GNOME stuff were gnome-desktop3 and indicator-appmenu and they should be fine as well, they are much smaller than nux to build
<Riddell> seb128: is gnome-desktop3 on the CD?
<seb128> yes
<seb128> Riddell, libgnome-desktop-3-2
<Riddell> ok gnome-desktop != gnome-shell I guess
<seb128> Riddell, yes, it's a library
<Riddell> ok let's respin half the world
<Riddell> Daviey: shall I mark ubuntu server as not being tested for now?
<doko> Riddell, and icedtea-web as well (as well only one the DVD)
<Riddell> doko: that's important for beta?
<doko> Riddell, for upgrade tests, yes. it doesn't add much build time, compared to openjdk-6
<Riddell> it's nice to have someone owe me beers for a change :)
<pitti> Riddell: unity-lens-applications
<pitti> Riddell: but should all be in now
<Riddell> pitti: hmm we got an e-mail saying this lockfile still exists /srv/cdimage.ubuntu.com/ftp/Archive-Update-in-Progress-nusakan.canonical.com
<Riddell> it's over an hour old
<Riddell> I think it's ok to delete
<pitti> Riddell: yes, there's only a buildlive kubuntu running from 8 mins ago, so shoudl be ok to delete
<Daviey> Riddell: no, it's fine
<Daviey> Riddell: the issues are in the on cd archive only, not installed as part of the testcases
<Daviey> Riddell: therefore, the iso's are good as is. Just the on-cd pool is a problem
<Riddell> royal.buildd is taking ages on these kubuntu images, is that the powerpc one?
<pitti> yes
<pitti> it's usually taking more than twice as long
<pitti> Riddell: there's an RT to move it to a faster buildd, but not done yet
<Riddell> micahg: "ubuntustudio-meta 0.97 produces uninstallable binaries: "
<zul> Riddell/Daviey: nova MIRs bug #941920, bug #941916, and bug #941913
<ubot2`> Launchpad bug 941920 in python-iso8601 "[MIR] python-iso8601" [Undecided,New] https://launchpad.net/bugs/941920
<ubot2`> Launchpad bug 941916 in python-tz "[MIR] python-tz" [Undecided,New] https://launchpad.net/bugs/941916
<ubot2`> Launchpad bug 941913 in python-babel "[MIR] python-babel" [Undecided,New] https://launchpad.net/bugs/941913
<Riddell> zul: best tell the ubuntu-mir team
<Daviey> NCommander: can you assist with the MIR's?
<Daviey> zul: I thought there was a further dep of the dep?
<zul> Daviey: python-tz
<zul> needed by python-babel
<Daviey> ah, good catch
<NCommander> Daviey: I can look them over and sponsor if need be. Will do in a few minutes
<Daviey> NCommander: thanks.
<Riddell> Daviey: NCommander isn't in ubuntu-mir, mterry is incharge of that
<Daviey> NCommander: ?  I didn't think you were.. which was why i was going to punt it to jdstrand. :/
<pitti> NCommander: no need to sponsor, unless we want to fix nova to drop the dependencies again
<Riddell> Daviey: or ask mterry, who is incharge of it
<NCommander> Riddell: I thought MIRs had to be sponsored by a core dev before going to the MIR team
<stgraber> jibel: can you try from a live session?
<stgraber> jibel: yesterday I discovered that the other manual partitioner crash happens only when you let the CD boot and install from there
<stgraber> jibel: as the accessibility module in gtk seems to be at fault
<stgraber> jibel: doing the same from ubiquity started from a live session didn't show the issue (bug 939450)
<ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
<stgraber> jibel: if you can only reproduce from a standard boot and not through the live session, it's most likely a duplicate of bug 939450
<Riddell> NCommander: not that I know of, it'll have to be uploaded by a core dev after
<Daviey> NCommander: zul and myself are both core dev's.. :)
<Daviey> Wait, and why would it need 'uploading' for a promotion?
<zul> i already pinged mterry on #ubuntu-devel
<Riddell> Daviey: it wouldn't
<jibel> stgraber, morning. 936115 is different and reproduced from a live session
 * jibel reading stgraber's reply on #ubuntu-installer
<stgraber> jibel: right, just came to the same conclusion (see -installer) :) looking at it now
<Riddell> new ubuntu images! http://cdimage.ubuntu.com/daily/20120227/
<Riddell> amd64 703MB, i386 not
<pitti> i386 seems fine
<pitti> amd64 probably just barely
<pitti> we really need to adjust cdimage's limits
<pitti> slangasek: ^ IIRC you determined the 703 MiB upper bound, did you? is it exactly 703 MiB?
<pitti> Riddell: if you are worried, I have little hesitation to drop the one remaining langpack from the alternate
<pitti> oh, we actually have two
<Riddell> pitti: I don't mind releasing oversized images but people who care about those images may well
<Cimi> Hi guys, I need an approval for this asaÃ¨ :)
<pitti> Riddell: dropped in the seeds
<Cimi> asap :)
<Daviey> Can we start keeping a journal of re-spin reasoning please?
<Cimi> seb128, added screenshot https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/940190
<ubot2`> Launchpad bug 940190 in light-themes "[UIFe] Unfocused theme" [Wishlist,Confirmed]
<Cimi> https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/940190
<pitti> Daviey: usually we keep track of them on http://pad.ubuntu.com/ubuntu-release
<pitti> Riddell: want me to respin? we have no test results yet, and alternates are quick
<Daviey> pitti: right
<Riddell> pitti: go ahead (I'm spinning kubuntu now)
<pitti> (noted so in pad)
<Riddell> Daviey: http://pad.ubuntu.com/ubuntu-release has notes
<Riddell> ...as has already been said
<Riddell> Cimi: for what?
<Riddell> Cimi: have you checked with the docs team?
<Daviey> Riddell: hmm, sorry - when you said new ubuntu images, i thought you mean't all flavours.
<Riddell> Daviey: I've not touched server
<Cimi> Riddell, doesn't affect docs
<Daviey> Riddell: great, thanks
<Cimi> Riddell, it's for unfocused windows, docs screenshots are taken on focused windows
<Riddell> Cimi: who has tested it?
<Cimi> Riddell, me
<Riddell> well yes but anyone who isn't the guy incharge :)
<jbicha> Cimi: well there's 1 screenshot we have that uses an unfocused window but it hasn't been updated for 12.04 anyway
<Cimi> Riddell, I don't think there are other guys apart from me who do theming :)
<Cimi> Riddell, visual designers approved
<Cimi> (I'm in london office)
<Cimi> which kind of "test" you need?
<Riddell> Cimi: get me a tester from the desktop team (like seb128 or didrocks) and I'll approve
<Riddell> just a sanity check
<Cimi> ok
<Cimi> seb128, ^ :)
<seb128> Cimi, ok
<Cimi> seb128, when you will be ok, I'll fix nautilus
<Riddell> new ubuntu desktop lives http://cdimage.ubuntu.com/daily-live/20120227/
<Riddell> amd64 702M i386 702M
<Riddell> amd64 702M i386 704M
<Riddell> stgraber: does the iso tracker get magically updated when new images appear?
<stgraber> Riddell: it should, yes
<Riddell> magic
<pitti> Riddell: new alternate built; do you know how to update the tracker for 27.1?
 * pitti needs to run out for a bit
<Riddell> pitti: it has magically updated
<seb128> Riddell, Cimi: the update seems fine to me
<seb128> theme update that is
<jibel> pitti, I reproduced bug 940908
<ubot2`> Launchpad bug 940908 in ubiquity "Cannot localize keyboard at startup in live session" [Undecided,Confirmed] https://launchpad.net/bugs/940908
<jibel> pitti, it only occurs on bare-metal booted from usb
<skaet> hiya Riddell,   is pad.ubuntu.com/ubuntu-release accurate?   I'm seeing a lot of rebuilds occuring I don't see marked on there and wondering why?
<skaet> (and triggers)
<pitti> I removed the alternate rebuild
<pitti> it's done
<pitti> but I can't figure out how to update the tracker
<pitti> jibel: ^ do you know how?
<pitti> I missed teh AUTO_POST thing
<pitti> oh, hang on
<pitti> it's already autoposted
<pitti> jibel: hm, weird
<pitti> jibel: thanks
<Daviey> skaet: I am wondering if a reasoning log is also of use, the pad doesn't seem clear nuff always.
<pitti> well, the pad _is_ our reasoning log
<skaet> Daviey,  would be good if folks could add the reasoning to the pad as well.
<skaet> or at least enough comments
 * skaet is not sure why Edubuntu is marked for rebuilding for instance...
<Daviey> pitti: Do you disagree, that at a glance you can see why a flavour of 20120226.1 was built?
<ogra_> for educational purpose indeed :)
<Daviey> can't*
<skaet> micahg,  I've not seen Ubuntu Studio rebuilt since 20120225 - are all the necessary pieces in place?
<pitti> Daviey: yes, we don't keep the reasons for past rebuilds (well, the pad does have history), just for pending rebuilds
<skaet> Daviey,  you can look at the past history via another link - so we do have a log.   Just need folks to put more detailed comments in so its useful... ;)
<Daviey> pitti: right.. so i need to look at the pad history to grok it?
<skaet> http://pad.ubuntu.com/ep/pad/view/ubuntu-release/latest
<skaet> Daviey, ^ link to pad history through time.
<Daviey> I'm not being daft.. i know the pad has history.
<pitti> it doesn't have the precise timestamps, thoug
<pitti> h
<Daviey> If i'm the only one that doesn't find the current process ideal, then 'ill drop the idea.
<Riddell> skaet: edubuntu is rebuilding for nux
<Riddell> same as ubuntu desktop
<skaet> Thanks Riddell.
<skaet> Riddell,  am confused only thing on precise-prob right now is linux-meta-armadaxp - why does Ubuntu Studio care about this?
<Riddell> ah, refresh fixed it
<Riddell> skaet: I'll rebuild Ubuntu Studio too
<skaet> Daviey,  would love more detailed logging, but not sure how it can be achieved in a light weight fashion in the near future.
<skaet> Daviey,  please bring it up for discussion at UDS feedback session.
<Daviey> skaet: k
<skaet> Riddell,  coolio,  thanks!
<pitti> skaet, stgraber: it seems the tracker still has some armel images; shouldn't these be armhf now?
<stgraber> pitti: probably, though if they're still being built they'll still be published ;)
<skaet> pitti,  I'd removed them but infinity added them back.   He's discussing it with kernel team.
<pitti> ogra_: should we drop the armel+omap images for ubuntu daily-preinstalled now?
<pitti> skaet: ah, so it's not just a leftover, but deliberate
<pitti> skaet: thanks
<ogra_> pitti, hmm, i thought infinity had done that last week already
<ogra_> pitti, oh, wait omap ... we're still waiting for binary drivers for armhf for that i think
<ogra_> lets probably keep them around for another milestone ... mx5 can definitely be dropped though
<ogra_> (armel that is)
 * Riddell is building arm images of ubuntu desktop now
<slangasek> the only armel left on the pad are omap and ac100; are those the ones that should be there?
<slangasek> infinity: ^^
<ogra_> slangasek, yes
<infinity> slangasek: Yes.
<slangasek> ok
<ogra_> ac100 doesnt have any armhf binary drivers at all ... omap is still waiting for a word from TI
<infinity> (And we should drop ac100 some day soon too, it's only there to appease Oli and his binary driver fetish)
 * slangasek chuckles
<ogra_> heh, drop it !
<ogra_> the binary driver doesnt get along with the latest Xorg ABI anyway
<infinity> Oh.
<infinity> Then yeah.  Screw it.
<ogra_> it works
<infinity> I'll drop ac100.
<infinity> Gladly.
<ogra_> but you get rainbow colors for fonts and fun like that
<ogra_> nothing we can fix on our side anyway
<pitti> so we'll keep armel+omap for now?
<ogra_> yep
<pitti> ok, thanks for the heads-up
<ogra_> until TI releases a binary driver we can pull in
<infinity> armel+omap is the one image we're keeping for smoketesting, though.  At least, until I talk to others and discover otherwise (but that was out plan, since it's the one kernel that's mainline)
<infinity> s/out/our/
<ogra_> that too
 * infinity goes to clean up armel+ac100.
<ogra_> binary driver situation is supposed to be solved by rsalveti/linaro
<infinity> Does someone want to clean armel+ac100 from the tracker while I purge them from cdimage?
<pitti> now, http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html doesn't look too bad
<pitti> one step away from beer
<stgraber> infinity: done
<infinity> Alright, purged.  Not bothering to re-generate indexes, it'll fix itself the next time someone rolls an image.
<skaet> Riddell, infinity - what about Ubuntu Core armel - does that makes sense anymore?
<infinity> Which is, I guess, right now.
<infinity> skaet: It does no harm to have it on all arches, IMO.
<infinity> (In fact, I wonder why I never enabled it for powerpc...)
<pitti> that would just unnecessarily heat up the universe even more? :-)
<slangasek> pitti: the upper bound is 703.125MiB: http://en.wikipedia.org/wiki/CD-ROM#Capacity (linked from https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate)
<pitti> slangasek: perfect, thanks
<Riddell> skaet: I've not ever worked out if ubuntu core makes sense, only NCommander seems to understand it
<pitti> slangasek: do you think "Further investigate feasibility of increasing CD limit to 703.125 MiB" still needs some actual work, or can we go ahead with this? I heard that several people burned 703 MiB images without a problem
<pitti> but that's of course not very scientific
<slangasek> pitti: the vast majority of people can burn them without problem
<slangasek> that work item was about trying to track down the cases where it hasn't worked, for one reason or another
<slangasek> I think we're probably ok to raise the limit, particularly for beta and see what happens; making myself a note to follow through on our CD pressing pipeline to make sure it handles the larger images
<pitti> thanks
<pitti> slangasek: so, I'll dive through cdimage and see where it has that check
<skaet> Daviey,  there are Ubuntu Server armel+omap and armhf+omap images on the tracker.   Are they actually wanted?
<pitti> infinity: hm, so do you know how cdimage bzr works? so /srv/cdimage.ubuntu.com is a local branch from /srv/cdimage.ubuntu.com/bzr/private/cdimage, which pulls from http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ -- i. e. cjwatson is the only one who can commit?
<slangasek> stgraber: I've marked all "armel" products in the iso tracker disabled unless they're omap flavor, since that's the only one we should have milestones of going forward
<infinity> pitti: Ignore the public one.
<slangasek> the public one isn't meant to be ignored
<infinity> From the POV of workflow on nusakan, it almost has to be.
<pitti> there's also a "submit branch" from /home/adconrad/cdimage
<slangasek> there is a copy of that branch on nusakan that cjwatson syncs from
<infinity> Colin does bi-directional merges between the public one and the private one.
<pitti> but this is mildly confusing
<stgraber> slangasek: sounds good, thanks
<slangasek> infinity: what's *meant* to happen is people commit their changes to the public one when appropriate and then merge them into the private branch
<infinity> pitti: The local workflow is "branch /srv/cdimage.ubuntu.com/bzr/private/cdimage to your home directory, do merges and such there, commit, then pull to /srv/cdimage.ubuntu.com"
<slangasek> /srv/cdimage.ubuntu.com/bzr/cdimage should be the copy of the public branch that you have write access to
<Daviey> pitti: be careful committing
<infinity> slangasek: Yeah, I like that theory.  I've never seen it work that way.
<pitti> so what is _the_ master branch for cdimage which we should commit changes to?
<infinity> pitti: The private and the public are both "master" branches.  Sort of.
<slangasek> infinity: that's how I make all my changes
<infinity> pitti: That's the confusion/annoyance.
<infinity> pitti: And, of course, neither of those is the production code.
<pitti> and the private/cdimage one is full of empty .orig files
<infinity> Is it?
<infinity> slangasek: If thats how you're making all your changes, then some things have changed lately, and I need to reexamine my workflow (ie: that used to be almost literally impossible for anyone but Colin)
<pitti> so AFAICS https://code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline is the official public branch, but I can't push back to this
<slangasek> pitti: you don't *need* to push to that one.  The branch containing the public code is /srv/cdimage.ubuntu.com/bzr/cdimage
<slangasek> cjwatson will sync
<pitti> slangasek: ah, so what's /srv/cdimage.ubuntu.com/bzr/private/cdimage then?
<slangasek> that's the master of the private code branch
<pitti> because that's what the actual deployment seems to pull from
<slangasek> but this is a change that should be made on both branches; commit to "public", merge to private
<slangasek> infinity: this is how cjwatson's had me making changes to these branches since I started :)
<pitti> slangasek: and then finally pull into /srv/cdimage.ubuntu.com, I guess?
<slangasek> yep
<infinity> slangasek: Heh.  Fair enough.  I'll add one more layer to my push/pull dance.
<infinity> slangasek: Colin's not once complained about it, so I guess he never much cared about the bi-directional merges. :P
<ogra_> depends what you marged from where to where :)
<ogra_> accidentially merging private into publich might cause some heatattacks somewhere :)
<ogra_> *heart
<pitti> slangasek, infinity: http://paste.ubuntu.com/859409/ ?
 * ogra_ thinks that looks sane
<pitti> infinity, slangasek: OK, I think I deployed it according to slangasek's recipe
<infinity> pitti: Aww, not keeping the historical mess of previous arguments/sizes? ;)
<pitti> bzr has it all, doesn't it? :-)
<infinity> I wonder what hardware/software hated our previous 736051200
<infinity> Cause it'll hate the new value even more. :P
 * skaet figures we'll hear about it from the beta images,  likely....
<infinity> Hopefully, it was some craptastic came-with-my-burner-in-2001 software on Win98 or something and no one cares anymore.
<pitti> so, the next image builds will hopefully complain less
<slangasek> right, the best we've been able to determine is that the complaints were from lousy burning software
<slangasek> and not a problem with actual media / hardware
<slangasek> stgraber: do you want to drop the imx51/omap4 flavors from d-i as well for netboot?
<pitti> good night everyone
<skaet> good night pitti
 * slangasek waves to pitti
<infinity> slangasek: Wait, do you mean from the tracker, or from d-i itself?
<slangasek> infinity: d-i itself
<slangasek> or do you need us to keep those?
<infinity> slangasek: There isn't an active imx51 flavour (hasn't been for years..)
<slangasek> ok, then I can remove that one from the tracker :)
<infinity> slangasek: But please don't drop any netboot flavours that are actually being built. :P
<slangasek> ok
<infinity> But you can drop all armel/netboot stuff from the tracker.
<Riddell> micahg: "Error: no livefs builds succeeded." for ubuntu studio
<Riddell> skaet: ^^
<Cimi> I need an approval for this https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/931088
<ubot2`> Launchpad bug 931088 in light-themes "[UIFe] Ambiance/Radiance Nautilus Sidebar Should be themed differently" [Undecided,Confirmed]
<Cimi> seb128, ^
<infinity>  libavcodec-extra-53 : Conflicts: libavcodec53 but 4:0.8-1ubuntu2 is to be installed
<infinity>  libavformat-extra-53 : Conflicts: libavformat53 but 4:0.8-1ubuntu2 is to be installed
<infinity>  libavutil-extra-51 : Conflicts: libavutil51 but 4:0.8-1ubuntu2 is to be installed
<slangasek> source?
<infinity> ubuntustudio builds.
<slangasek> funfun
<seb128> Cimi, I'm not in the r-t so I can't give approval, and I think such tweaks are defined as bug fixes no need of an uife
<Cimi> seb128, no they are quite bug
<Cimi> *big
<infinity> shlibs mess and/or packages that should be providing things they aren't.
<Cimi> documentation need to be aware
<infinity> I guess.
<infinity> (I assume those are ABI-compatible replacement libraries?  I hope?)
<Cimi> seb128, the search bar changes from yellow to light grey
<Cimi> *changed
<seb128> Cimi, well I think there was an agreement that it's ridiculous to ask for an uife for every single minor change
<seb128> like color tweaks
<Cimi> ok
<Cimi> I'll merge then
<Cimi> seb128, from yellow to grey
<Cimi> seb128, not to a brighter color
<Cimi> anyway ok
<seb128> if the documentation is still reflecting the ui and there is no layout or functional change I think it's just a bug fix
<Cimi> ok
<seb128> i.e you can still see it's the same interface and ui elements even if the color is different
<slangasek> infinity: TTBOMK they are ABI-compatible; I think ubuntustudio requires the 'extra' ones with more features, and it looks like something has already pulled in the non-extra ones to the build's detriment
<infinity> slangasek: Sure, but that should resolve (or be resolvable) sanely...
<infinity> Perhaps it just needs some seed abuse, like xubuntu and it's one annoying library.
<slangasek> infinity: only if -extras- is seen *first*
<skaet> Riddell,  ack.
<slangasek> if apt has already decided it needs libavcodec53, then something tells it that it also needs libavcodec-extra-53, fail
 * skaet heading out for lunch,  biab
<infinity> Remind me where the ubuntustudio seeds live?
<Riddell> infinity: http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ ?
<infinity> (Do we have an authoritative list of where all the non-core-dev seeds are?)
<Riddell> cdimage:bin/run-germinate ?
<infinity> Riddell: That would do it yeah.
<Riddell> also code.launchpad.net/ubuntu-seeds
<infinity> slangasek: Right, so, remember how xubuntu used to force LIST="... libgoffice-gtk-0-6 xubuntu-desktop^"?
<infinity> (Before that became obsolete, apparently)
<infinity> slangasek: Seem like a sane hack to force these -extra libs for ubuntustudio for now, or should we find a saner fix?
<slangasek> infinity: I don't remember that at all, no :)  But I think the sane fix is to reorder the seed so that -extras- is found before libavcodec53
<slangasek> (we've done this plenty of times for similar situations)
<infinity> Oh, wait.
<infinity> slangasek: Yeah, just needs moving ubuntustudio-video before ubuntustudio-desktop in auto/config
<infinity> slangasek: I suspect.
<infinity> slangasek: Since *-extra-53 is in the ubuntustudio-video seed, afaict.
 * infinity is curious what that might impact negatively...
<infinity> slangasek: Oh, the ffmpeg-common seed is tiny.  Maybe it just needs a STRUCTURE fiddling, then.
<infinity> (ie: make desktop depend on ffmpeg-common)
 * infinity tests this theory.
<Riddell> skaet: new amarok about to be in Unapproved, please approve
<Riddell> skaet: then please rebuild kubuntu when it appears, should solve our sizing problems for desktop images
<Riddell> skaet: kubuntu active has a mystery failure that I haven't worked out http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-active/precise/daily-live-20120227.log
<Riddell> I'm off for the evening
<gilir> next lubuntu-meta upload is to re-create the lubuntu-desktop binary, and update the seed with package name changes, please accept it :)
 * ScottK took care of accepting amarok.
<gilir> a respin of all Lubuntu ISOs will also be needed after
<stgraber> based on jibel's comment in #ubuntu-testing, Edubuntu most likely has a broken ltsp-live at the moment.... running a quick test and if it's what I think, I'll upload a new ltsp soonish
<stgraber> which will require a respin of Edubuntu. The alternates shouldn't be affected by this problem (they don't use ltsp-live)
<jibel> stgraber, you might be interested in bug 936939 too
<ubot2`> Launchpad bug 936939 in ltsp "ltsp-live crashed with IndexError in __getitem__(): row index is out of bounds: -1" [Medium,Triaged] https://launchpad.net/bugs/936939
<jibel> stgraber, start ltsp-live without network (which doesn't make sense I agree)
<stgraber> jibel: oh, interesting one ;)
<stgraber> jibel: by networkless, do you mean without any network interface or just no connected interface?
<jibel> stgraber, I tried without network interface, but from the bug original report, I guess it may occur in other configurations (unplugged interface, disconnected wifi, ...)
<micahg> skaet: re ubuntustudio, apparently not, will get solved
<micahg> Riddell: oops, I assume there's a log on the site I can look at?
<stgraber> jibel: ok, should be easy to fix but will introduce an extra string (as I need an error message for that case)...
<stgraber> jibel: or maybe not, apparently the window shows up just fine without any network interface, it just fails when starting, so I can simply disable the start button until we have an interface selected
<stgraber> jibel: ok, fixed that one in the branch, still need to fix the other one though
<micahg>  bzr-rewrite fixes a regression I accidentally introduced ~8 hrs ago, if someone could review/release it :)
 * doko mad roseapple an amd64 buildd for a while to clear the queue
<ScottK> micahg and gilir: accepted.
<micahg> ScottK: thanks
<ScottK> You're welcome.
<ScottK> Also accepted amarok and lubuntu-meta from binary New.
<infinity> Oh, bah.  core-dev can't commit to ubuntustudio seeds?
<infinity> micahg: Could you have that fixed at some poine?
<infinity> point, too...
<micahg> infinity: I asked about it, it was due to e-mail noise going to core-devs and was apparently an acceptable solution a while back
<micahg> infinity: did you fix the problem?
<micahg> s/fix/find/
<infinity> Mail shouldn't be an issue, unless people have automatic subscription on.
<infinity> (Which is insanity)
<micahg> infinity: IIRC, the dev team is subscribed to some bugs as well
<infinity> micahg: I'm not entirely sure without running the LP scripts, to be fair.
<micahg> infinity: ah, ok, I was going to dig into it after my next meeting
<infinity> micahg: I /think/ that making desktop depend on ffmpeg-common in STRUCTURE will solve the problem.
<infinity> micahg: The metapackages are coming out correctly either way (since libav* isn't actually in -desktop), but tasks contain all the dependencies as well, so the -desktop task gets the non-extra libav.
<micahg> hmm, I thought we fixed that
<infinity> (So, I'd need to run the LP generate-extra-override bits to be sure that STRUCTURE change fixes it, but logically, it should)
<infinity> micahg: Anyhow, if there's foot-dragging about core-dev being a member of ubuntustudio-dev, at least have me added?
<micahg> infinity: sure, I can ask for that, in the mean time, I can fix it
<micahg> infinity: is the error somewhere where I can see it?
<infinity> I poked Luke about it.
<infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntustudio-dvd/20120227/
<infinity> micahg: ^
<infinity> micahg: But the error is obvious from apt-cache.
<infinity> micahg: Namely that libavcodec53 is in Task: ubuntustudio-desktop, and it really shouldn't be.
<infinity> (And same for the other two)
<micahg> ah, yeah, ok
 * micahg is wondering what changed that broke that
<infinity> Moon phase, order of packages in lists, who knows?
<infinity> The way it's set up currently is fairly non-deterministic.
<infinity> So, it could work again tomorrow, and break on Friday.
<micahg> ok, fix pushed, I guess we wait a publisher cycle and respin?
<infinity> Wait a publisher cycle, check apt-cache, curse if it didn't change the Task header.
<infinity> At which point, I'll break down and actually start generating extra-overrides locally to see why I was wrong.
<infinity> But, if apt-cache shows you love, yeah, we'll respin.
<micahg> ok, thanks
<skaet> manpages -> approved.
<skaet> ScottK,  re: amarok, thanks.
<stgraber> ^ fixes two ltsp-live bugs, one of them is critical for Edubuntu, only affect ltsp-live on Edubuntu. Would appreciate a respin for this one.
<skaet> stgraber, bug numbers?
<micahg> infinity: it was the new audacious-plugins that broke ubuntustudio, still waiting for a new germinate run + publisher cycle
<stgraber> skaet: bug 936939 is the non-critical one. I don't have a bug number for the critical issue (no working ltsp in Edubuntu), was waiting to see if jibel filed one so I can close it manually
<ubot2`> Launchpad bug 936939 in ltsp "ltsp-live crashed with IndexError in __getitem__(): row index is out of bounds: -1" [Medium,Triaged] https://launchpad.net/bugs/936939
<skaet> thanks stgraber
<infinity> micahg: Oh?
<infinity> micahg: As in, it was broken somehow, or it got pulled into -desktop and broke the accidentally working setup?
<micahg> infinity: as in the dependencies changed :)
<micahg> it didn't used to need libavcodec
<infinity> Right.
<infinity> But that package itself isn't to blame in any way, it's just that nothing in -desktop used to use libav, so the broken seeds accidentally worked right, right? :)
<micahg> well, there was no need for the dependency since nothing depended on it
<infinity> I suppose.
<infinity> Hrm.
<infinity> So, now libavformat53 isn't in the ubuntustudio-desktop Task anymore (yay), but I kind expected that the -extra- one would be.
<infinity> Weird.
<infinity> And it's not.
<infinity> Probably fixed anyway, though.
<skaet> infinity,  why is ubuntu desktop arm images marked for rebuild on the iso tester?   am not seeing a reason on the pad (ie. not sure if they should/can be kicked off yet or not)
<infinity> skaet: Wasn't me...
<infinity> skaet: I know they were in the process of being rebuilt (as in, it's still happening right now), but not sure why, I wasn't around when that started.
<skaet> infinity,  thanks.    Anything else you know is being rebuilt as we speak?   I'm not seeing much on the ps -aux | grep cdimage side.
<infinity> That's all I see.
<skaet> okie.  ... working through the dependencies then to see what's ready for kicking off.
<skaet> ltsp accepted, but would like another set of more knowledgable eyes on libtimezonemap
<skaet> infinity, slangasek ^ either of you able to help out?
<infinity> I'll have a look.
<skaet> thanks infinity
<infinity> Looks straightforward enough to me.
<skaet> thanks infinity.
<infinity> Riddell: kubuntu-mobile is dead, right?  I can remove the cruft from cdimage/www/full/kubuntu-mobile/?
<ScottK> infinity: Just make sure the cruft is replaced by kubuntu-active as that's the new hotness.
<infinity> Riddell: Repeat for -kde4 and -netbook.
<ScottK> infinity: Yes.
<infinity> ScottK: -active is already there.
<ScottK> OK.
<infinity> ScottK: Alright, going to remove all the daily-* directories for now.  We can decide what we want to do about releases later.
<infinity> (My gut is probably "archive them off and then delete", but I dunno)
<GrueMaster> I'm not seeing netboot on the tracker.  Is that going to be added for beta 1 testing?
<slangasek> let me add it
<slangasek> done
<GrueMaster> Thanks.  Can you remove the armel+omap4?  Or should we leave it since it is being generated?  I've already got a test build running now and it is automated for the most part.
 * infinity is irked by the queue not showing him who sponsored an upload, and heads to cocoplum...
<slangasek> GrueMaster: it's still being generated, so keeping it on the tracker
<slangasek> and infinity says we shouldn't make it disappear
<GrueMaster> Ok.  I'm good either way, but I wanted to verify.
<infinity> I don't want the d-i target to disappear.  I don't really care if it gets tracked.
<infinity> (much like powerpc d-i targets)
<slangasek> infinity: well, I'm not sure why we want armel+omap4 d-i if we're not building images from it
<infinity> slangasek: How do the two relate at all?
<slangasek> because armel+omap4 is useful or it isn't? :)
<infinity> slangasek: For anyone wanting to do any sort of automated testing (glances at Tobin), or for people who want to install, despite not having "supported and tested CD/preinstalled/etc images", netinst is simple and easy for us to provide with minimal effort.
<slangasek> well, I'm not sure why we would even keep the kernel image around under the circumstances
<infinity> slangasek: I suppose we could drop the kernel image, but I'm not sure I see the point.  It's identical to the armhf kernel, so it's not a maintenance burden.
<slangasek> yep, just buildd load
<infinity> slangasek: It's a QA burden, but only if QA chooses to QA it. :P
<infinity> I'd take the buildd argument, except that ARM kernels all build faster than the x86 ones.
<GrueMaster> QA for netboot is mostly automated now (and the monkey presses the button), so little burden here.  Just a matter of tracking or not is all I care about.
<infinity> Anyhow, it's not something I feel wildly passionate about, I just think it's a nice service to actually provide d-i/netboot builds, since that takes so much less time and effort than full image builds.
<GrueMaster> And the install on USB is loads faster for app testing than SD.
<infinity> (And it becomes moot when and if we drop armel entirely, sure, but while the userspace is still shipping, having some way to install/test is nice)
<slangasek> well, I thought 'omap' was the "some way to install/test"?
<micahg> skaet: broder found a wiki page that's out of date: https://wiki.ubuntu.com/BetaFreeze, would you be up for updating it to be image based rather than component based or should I give it a whirl?
<skaet> micahg,  if you could take a pass on it,  would be much appreciated.
<micahg> ok, will give it a shot
<GrueMaster> slangasek: Actually, omap4 is the preferred test platform.  We can cover more testing faster and SMP inherently finds more bugs than UP (note Mono/Banshee from Maverick).
<slangasek> I understand that, but why then are we generating desktop images for armel+omap but not armel+omap4?
<skaet> infinity, re the other directories - if they're all EOL yes, but probably should do some checks to confirm.
<infinity> slangasek: The argument for keeping only armel+omap was because it's the only kernel in mainline.  I dunno.  Subconsciously, maybe I was doing it as a pat on the back for someone finally doing something right. :P
<infinity> slangasek: Switching that to omap4 wouldn't hurt my feelings.  I don't really care either way.
<infinity> slangasek: Heck, dropping them both wouldn't hurt my feelings, and just directing people who really want armel to use d-i/netinst...
<dobey> hi
 * slangasek waves to dobey 
<dobey> how much approval would a change that fixes a regression, but which technically breaks feature (and possibly ui) freeze, require?
<micahg> infinity: Ubuntu studio looks good, can we resping please?
<slangasek> infinity: right, I don't see strong arguments one way or the other.  I guess I think that, if armel+omap4 is the one it's useful to us to keep around as netboot for sanity checking, it makes more sense to me to also have this one as the desktop image
<slangasek> dobey: how "technically" is technically?: )
<infinity> slangasek: Well, we're keeping both as netboot.
<dobey> slangasek: http://git.gnome.org/browse/rhythmbox/commit/?id=bca344b8d70cf39ceb57b3654124f23cad69e4b1
<infinity> slangasek: My netboot/d-i argument is simple that "if the kernel is in main (ie: if the d-i build can see it), we should build d-i against it".
<infinity> s/simple/simply/
<infinity> micahg: Roger.
<dobey> slangasek: old rhythmbox (gtk2) had a way for plug-ins to specify they should be enabled by default, but with the gtk3 port and change to libpeas, that was broken. this commit fixes it and introduces a new value in the config schema (which i think breaks string freeze)
<infinity> slangasek: But, the "which images do we drop/keep" thing was hastily decided, to say the least, and the more I think about it, the more I think the right answer is "drop them ALL", and just leave d-i/netboot for people who really want/need to install/test armel".
<infinity> s/".$/./
<skaet> infinity, slangasek,  - am not spotting anything specifically to wait for right now on starting off rebuilds for ubuntu desktop/DVD - you aware of anything?
<infinity> skaet: libtimezonemap would have retriggered all desktop images.
<infinity> skaet: At least.
<skaet> infinity,  glad I asked.  just sounded like edubuntu from stgraber's earlier comments.
<infinity> skaet: ltsp was just edubuntu, but libtimezonemap is that cute little timezone clicky UI in ubiquity, IIRC.
<infinity> I could be wrong.
<infinity> It's in all the *-live tasks, though, so I'm probably not wrong. :P
<slangasek> dobey: I'm pretty sure string freeze doesn't care about the config schema
<infinity> If people are translating config schemas, we have some pretty big problems to sort out.
<dobey> slangasek: i think the short/long description are translated though
<skaet> infinity,  its in all the alternates as well... full rebuild time.
<slangasek> dobey: so I think you should file a pro forma FFe bug for this so that the release team has documentation, but I don't see any reason to reject this change
<slangasek> dobey: translated in rosetta?
<slangasek> I can't imagine why gsettings config schema entries would need to be translated
<GrueMaster> Can someone add netboot armhf+armadaxp to the tracker?  thx.
<dobey> slangasek: well, i would presume they'd show up in launchapd, if they are in defualt installed packages at least
<dobey> slangasek: well, different default values for different locales is useful. gconf schemas are translated also
<slangasek> infinity: so I don't think that we need to take a second hasty decision here; I'm also inclined to disabling the armel desktop images though
<slangasek> dobey: the very idea of changing the default based on locale is making my head hurt
<GrueMaster> slangasek: We have HW dependencies for the ones that are still active.  Need to wait for binary video drivers.
<GrueMaster> (omap & ac100).
<slangasek> stgraber: ^^ can you get armadaxp on the tracker please?
<dobey> slangasek: weather applet for example defaulting to C or F, mph or kph, depending on your locale.
<infinity> slangasek: Well, hasty is easily undone, it's just a few config files. ;)
<infinity> slangasek: I'm not silly enough to wipe armel code from anything, just disable it in default-arches and such.
<stgraber> slangasek: what product are we building, where are they showing up and what tests should they have? (I usually let jibel take care of that ;))
<slangasek> jibel: ^^ stgraber is passing the buck to you for armhf+armadaxp on the tracker :)
<stgraber> oh, netboot only, that's easy, I can do it without scripting :)
<stgraber> it gets a lot more annoying when you need to add desktop images with 4 download links each and a 10 testcases ;)
<infinity> Heh.
<infinity> If it's any comfort, armadaxp will never have a desktop image. ;)
<stgraber> jibel: I'm taking care of netboot armhf+armadaxp
<infinity> (maybe an alternate, if someone can sort out how to get it to boot from USB)
<infinity> s/boot/reliably boot/
<dobey> i guess the rhythmbox schemas might not be getting translated though
<infinity> slangasek: Yeah, so.  Hasty or not, I think I'm just going to end the entire debate by dropping armel+omap/desktop, and watch as no one other than Tobin even notices.
<dobey> seems that way
<stgraber> GrueMaster: done
<infinity> slangasek: And done.  Want to make it official and remove armel+omap/desktop from the tracker?
<infinity> stgraber: Or you?
<stgraber> infinity: that includes kubuntu desktop armel+omap?
<infinity> stgraber: kubuntu-desktop armel+* should be gone.
<infinity> stgraber: In fact, everything armel+* !netboot should be gone.
<stgraber> infinity: ok, dropped "kubuntu desktop armel+omap", "ubuntu desktop armel+omap" and "ubuntu server armel+omap"
<stgraber> infinity: leaving us with just netboot
<infinity> stgraber: Kay.  All other armel+* flavours were already gone, I take it?
<stgraber> does your change also affect Ubuntu Core?
<infinity> Nope.
<stgraber> yeah, the others were already gone
<infinity> Kay, cool.
<skaet> infinity,  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest can you confirm it matches
<infinity> skaet: Looking.
<stgraber> ok, so in the armel world, we're now left with "Ubuntu Core armel", "Netboot armel+omap" and "Netboot armel+omap4"
<GrueMaster> I thought we were keeping the omap images until we have the drivers rebuilt for armhf?
<infinity> stgraber: Sounds right.
<infinity> GrueMaster: Yeah, well.  We don't intend to support it, so why build it?
<infinity> GrueMaster: We have netinst for people who really want/need to play with it.
<GrueMaster> Ok.  I was just repeating what ogra_ had said this morning.
<infinity> GrueMaster: Yeah, I was there. :)
<infinity> (Or I discussed it with him last night?)
<infinity> Anyhow.  We don't intend to actually ship or support armel images at all for final.
<infinity> So...
<infinity> Why do it now and let people drag their feet?
<skaet> infinity,  refresh the page - just made a few more edits from the backscroll info.
<infinity> skaet: For netboot, you want s/cdimage/archive/
<infinity> skaet: But I might tidy up a bit more of the desktop-versus-preinstalled bits and such.
<skaet> infinity,  how so?  split out again?
<dobey> slangasek: i added it to bug #934235
 * skaet changing netboot right now.
<ubot2`> Launchpad bug 934235 in rhythmbox-ubuntuone "[FFe] ubuntu one plugin is not enabled by default" [High,Confirmed] https://launchpad.net/bugs/934235
<infinity> skaet: Some bits are just listed in the wrong spots, I think. ;)
<GrueMaster> infinity: arm* netboot images are only on ports.ubuntu.com, not archive.ubuntu.com.
<infinity> skaet: Also, is there any point in listing armhf+ac100's "tech preview", when the whole point of the document is listing supported images (ie: it doesn't list powerpc at all).
<infinity> GrueMaster: Fine, fine.  So archive/ports.  Either way, cdimage is wrong. :P
<infinity> GrueMaster: I meant "archive" as in "it's in the archive", not the host "archive.ubuntu.com".
<infinity> (ambiguity, yay)
<GrueMaster> Ah, my bad.
<infinity> I'd actually just write ftpmaster there, but only 7 people would know what that meant.
<stgraber> infinity: as long as the 7 people include everyone who needs the wiki page, that's fine
<skaet> infinity,  we had images released as tech previews and mentioned in the announce before if they were tested.   Want to check with ogra_ since he's community maintainer for it,  but from his comments earlier today wasn't sure if it should be in or out.
<infinity> skaet: Well, if ac100 should be included, so should mx5. ;)
<skaet> infinity, is there someone lined up to test it?
<infinity> skaet: There used to be...
 * infinity isn't sure right now.
 * skaet nods
<skaet> infinity - list is the ones we'll be publishing with precise,  support terms as listed under each product.  Images don't go on the list unless there's someone signed up to test it.
<infinity> skaet: Kay.  So, if I sign up to test (after I fix) ubuntu-desktop/powerpc and ubuntu-server/powerpc, they would also go on the list as "unsupported" or some such?
<infinity> skaet: I (perhaps wrongly) assumed the list was just a list of supported images, since it has the heading "supported architectures". ;)
<infinity> But we could be overloading the meaning of "supported" here.
<skaet> infinity,  yeah there might be some overloading going on. :P
<infinity> (And maybe just dropping "supported" from that column heading would fix my confusion)
<infinity> Since "maintenance commitment" covers that anyway, and can contain the value "unsupported".
 * skaet cleans up titles
<Daviey> .
<skaet> slangasek, is there any more ubiquity fixes in the queue before a full rebuild is kicked off?
 * skaet drums fingers...  waiting on amd64 builds...
<stgraber> skaet: there are two fixes currently in ubiquity trunk, working on another bug (though not a critical one) and we have a critical bug without a fix just yet (gtk bug)
<stgraber> skaet: bug 936115 and bug 898278 are the two currently fixed in trunk
<ubot2`> Launchpad bug 936115 in ubiquity "ubiquity crashed with TypeError in partman_popup(): popup() takes exactly 7 arguments (6 given)" [High,Fix committed] https://launchpad.net/bugs/936115
<ubot2`> Launchpad bug 898278 in ubiquity "Upgrade menu option should not appear for old releases" [High,Fix committed] https://launchpad.net/bugs/898278
<stgraber> skaet: I'm working on bug 645449 and the gtk one is bug 939450
<ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Confirmed] https://launchpad.net/bugs/645449
<ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
<stgraber> that last one prevents manual partitioning from working outside of a live session so really annoying
<skaet> stgraber,  thanks,  ok first two we can probably live with for beta 1 if, but it would be good to get fixes in place for those later two indeed.   I won't block today's respins waiting on 936115, 898278.
<skaet> stgraber,  however, if we get fixes for 645449 or 939450,  would be good to respin and pick them up.
<stgraber> skaet: I'm hoping to have a fix for 645449 today, I know what the problem is now, I'm just trying to figure out a way of fixing it ;)
<stgraber> skaet: 939450 depends on the desktop team at this point as it's a gtk bug
<stgraber> skaet: I could turn off accessibility completely for beta1 as a workaround but I don't think we want that...
<skaet> stgraber,  thanks.   no we would like to get some accessibility testing in at this point if at all possible.
 * doko mad roseapple an i386 buildd again
 * ScottK hands doko an 'e'.
<ScottK> It looks to me like amarok is done for i386/amd64, so those images can be respun.
<skaet> ScottK, yes was just waiting on on a couple of others that were building to add.
<ScottK> OK.
<GrueMaster> I see new desktop images for armhf+omap4 and armhf+omap.  Is the armhf+mx5 being rebuilt?  It seems to have dropped off the tracker.
<infinity> It may have been dropped from the tracker in a fit of confusion.
<GrueMaster> Ok, just checking.
<infinity> skaet: So, what's the current rebuild state?
<skaet> infinity,  have started the alternates,  making sure the first one from that goes through prior to kicking off the desktops.
<infinity> skaet: Kay.
<skaet> infinity, with all the churn today,  are runes to build the arm images ok?
<infinity> skaet: I assume we're doing the whole world, instead of piecemeal?
<skaet> infinity - yes, at this point seems best.
<infinity> skaet: Yeah, I've been updating the pad as I went, the preinstalled bits are correct.
<skaet> infinity,  coolio,  will open another window off and start them too then.
<Riddell> infinity: kubuntu-{mobile,kde4,netbook} are all obsolete
<infinity> Riddell: Check.
<Riddell> skaet: evening, what's the craic?
<infinity> Riddell: Once we're sure all the old releases are safely archived off, we'll just remove them entirely from cdimage, then (I already manually purged all their dailies).
<skaet> Riddell,   new images building now.   pad is up to date.  ;)
<micahg> infinity: did the Ubuntu Studio rebuilds not get kicked off or is there just a backlog of images being generated?
<infinity> micahg: The former.  Since we were waiting on a "rebuild the world" event, I decided not to bother.
<Riddell> infinity: any ideas on the kubuntu-active failure? (http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-active/precise/daily-live-20120227.log)
<infinity> No active CD for i386!
<micahg> infinity: ah, ok, I'll check back later tonight, thanks
<infinity> Looks like you told some script that it was an "active" type instead of "live", perhaps?
<infinity> (wild guess)
<skaet> miachg,  backlog - they've been kicked off now.
<skaet> infinity - arm images have started rebuild now too.
<skaet> Ubuntu and Kubuntu alternate have been posted.
 * skaet having a mother hubbard moment (need dog food) - heading to store, biab
 * GrueMaster thinks skaet may be taking "dog fooding" a little too litteral.
#ubuntu-release 2012-02-28
 * skaet back now... dog fed, images emerging. :)
<infinity> I hope those two statements are disconnected.
<infinity> Or it speaks volumes about beta quality...
<skaet> infinity, there was a comma there for a reason.  :)
<infinity> Not sure that helps. :P
<skaet> lol,  will split them up to separte topics next time.  ;)
 * GrueMaster grabs a scoop, starts validating.
<skaet> infinity,  in #ubuntu-testing wxl was griping about powerpc alternate for ubuntu still being oversized - possible tester?
 * infinity wanders off for a smoke before someone mentions the Poopy Pangolin.
<infinity> skaet: A tester would be nice!
<infinity> And yeah, it's pretty horribly oversized.
<infinity> Probably due to being the only image that still ships with multiple kernels.
<infinity> I might have to put a weekend worth of community love into PPC images.
<skaet> why multiple kernels?
<GrueMaster> I may have missed something earlier, was openjdk-6-jre rebuilt earlier?
<infinity> 32/64.
<skaet> sigh,  yeah.
<infinity> Maybe I could just make the install media 64-bit only, and let 32-bit users use netinst and other methods.
<infinity> I mean, honestly, half the ppc32 machines out there can't reliably (or at all) boot CD media anyway.
<infinity> I know mine can't. :P
<infinity> I think the only intersection of ppc32 and "can actually boot an installer without manual intervention" would be the G4 desktops and laptops.
<infinity> Which is, what, a 2 year window in the middle of a long line?
<infinity> Oh, and candy-coloured iMacs.  There were a ton of those sold, too.
<infinity> Nevermind.  I'll find another way to make space.
<GrueMaster> It would be interesting to know how many users of those are still around.  I think they were phased out in 2004 time frame.
<infinity> GrueMaster: The candy iMacs and clamshell iBooks?
<infinity> GrueMaster: Yeah, they're old, but Apple sold a stupid number of them.
<skaet> infinity,  wxl has 32 bit hardware - so maybe bias there?
<infinity> skaet: Oh, shiny.
<infinity> skaet: Between he an I (I have a POWER5 workstation and an ancient G3 desktop), we probably cover a fair number of potential hardware, then.
<skaet> infinity,  coolio,  ping him directly from ubuntu-testing when there's something in size.
<GrueMaster> (and users).   :P
<infinity> GrueMaster: There are definitely PPC users.
<infinity> GrueMaster: But it's a question of scale, right.  We have millions of x86 users, and finding more than a couple of testers who are willing to actually report QA results (not counting ones that we pay for) is still hard.
<infinity> GrueMaster: So, finding people willing to test a port for free among a smaller user base.  Fun.
<GrueMaster> Oh, I am well aware of that issue.  I've been trying to recruit testers for omap/omap4 for a year now.
<GrueMaster> I have a hard enough time getting someone to test a fix for a bug they reported when I don't have the same hw (which is why I ended up on a buying spree last year).
<GrueMaster> Well, one of the reasons.  I still like the toys.
<skaet> :)
<infinity> Yeah, I'm often tempted to go eBaying for more PPC hardware.
<infinity> But, honestly, I want other testers so I can, like, do other things and not have it rest on me.
<infinity> You're okay, since you're paid to QA ARM stuff.
<infinity> Sadly, PPC has to be in my "spare time".
<infinity> (Also, I'm not lugging my POWER5 workstation to London for the release sprint)
<stgraber> why not? ;)
<infinity> stgraber: I could discuss how heavy it is, but probably not without making a few "your mom" jokes.
<ScottK> infinity: Maybe barry fixed his.
<infinity> ScottK: His mom?
<ScottK> Heh.
<ScottK> No, his powerpc box.
<GrueMaster> infinity: You can always set it up for remote testing.
<stgraber> skaet: I pushed a (rather ugly) fix/workaround for bug 645449 to ubiquity's trunk. It seems to do the trick here. Should I upload a new ubiquity now?
<ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Confirmed] https://launchpad.net/bugs/645449
<skaet> stgraber,  would like the current set of images to finish off building before it goes into the archive,  but go ahead and push it up to unapproved queue.   Will ask pitti, Riddell to look at it when they come on shift - other image builds should be finished by then.
<stgraber> skaet: ok, I'm not planning any more ubiquity work tonight, so will upload what I have.
<stgraber> skaet: the remaining big issue is the accessibility one but this will most likely involve a gtk upload rather than ubiquity
<skaet> stgraber, gotcha.  thanks!
<stgraber> ok, uploaded. Time for some food now ;)
<skaet> stgraber,  thanks!  enjoy dinner.
<skaet> infinity,  could you check the core logs and see if something's gone south on it?   it seems to be taking quite a long time after all the builders have reported success...
<skaet> kapok.buildd finished at Mon Feb 27 23:08:10 UTC 2012 (success)
<skaet> cardamom.buildd finished at Mon Feb 27 23:09:25 UTC 2012 (success)
<skaet> celbalrai.buildd finished at Mon Feb 27 23:11:25 UTC 2012 (success)
<skaet> given its now: Tue Feb 28 01:31:05 UTC 2012 and it hasn't finished
<skaet> hmm... its waiting on annonaceae - but I'm not seeing annonaceae in the set of builders...   hrmmm
<skaet> slangasek, ^ you know what's going on with annonaceae?  which arch was it mapped to?
<GrueMaster> skaet: That was a beaglexm buildd.  Should have been replaced with a panda.
<skaet> Thanks GrueMaster.  I'll kill it now then, and see what else happens.
<GrueMaster> (all the *ceae machines were beaglexm omap boards).
<skaet> NCommander, infinity - could you look at the scripts and see if there are any other spots that might need fixing as well....
<skaet> (reference was in ubuntu-core set)
<NCommander> skaet: I'll poke it in the morning if infinity doesn't get to it; he wrote that code so he should know it better
<skaet> thanks NCommander.  :)
<infinity> GrueMaster: No it wasn't.
<infinity> GrueMaster: We didn't decommission the beagles.
<GrueMaster> Ok.  Thought we were working on them too.  It is a beaglexm, though.
<infinity> Yes, I know.
<infinity> skaet: annonaceae should be recovering from whatever insanity took it over.  I can respin core later when the world's settled down a bit, or something.
<infinity> (Not that it's wildly important to have it in sync for beta1, it's not like it has an installer or anything)
<skaet> infinity, coolio.  thanks.
<stgraber> skaet: 02:03 <TheMuso> So maybe just disable the at-spi/atk-bridge code in ubiquity-dm for now, and I'll bang on it and see what I can find out, and I'll need to talk to upstrea in any cased.
<stgraber> skaet: actually, a bit of context might help: 02:02 <TheMuso> The only update so far is that the latest code from upstrea for the accessibility stack, with the exception of GTK, doesn't help fix the problem.
<skaet> stgraber, release note time sounds like.... :-/
<stgraber> skaet: what do you prefer as a release note, manual partitioning not working unless you use the live session or accessibility disabled in the installer?
<skaet> stgraber,  edubuntu dvd's finished building - should be posting any minute now.
<stgraber> skaet: looks like it did, just got the e-mail notification. thanks
<skaet> stgraber,  think I'll wait for pitti to comment on this...  not sure about the size of the user pool for each of those features.
<skaet> suspect it will bias towards accessibility disable in the installer, but want his input.
 * skaet calling it an evening...
<skaet> Riddell,  pitti - pad is up to date - some weirdnesses/concerns from today's builds and redos looking likely.
<skaet> (specifically arm images)
<infinity> skaet: What else when goofy with ARM images?
<infinity> skaet: I thought it was just core.
<infinity> s/when/went/
 * slangasek scratches his head.  I think that packageset listing is wrong for nis maybe :)
<micahg> yeah, those look wrong
<stgraber> ^ that should fix the package set related mistakes
<pitti> Good morning
<pitti> "respin triggering bug"? (from the pad)
<pitti> stgraber: there is your ubiquity upload in the queue
<pitti> stgraber: that'll need respins for everything, right?
<pitti> well, no alternates/servers of course
<pitti> but I guess we need to rebuild servers as well when sorting out the python-babel stuff
<pitti> stgraber: do you know if bug 905754 needs to be included into ubiquity? the current upload doesn't seem to
<ubot2`> Launchpad bug 905754 in libtimezonemap "Israel is not on the installer map" [High,Fix released] https://launchpad.net/bugs/905754
<stgraber> pitti: 20:14 -queuebot:#ubuntu-release- Removed package: libtimezonemap
<stgraber> I believe that one was for the map
 * stgraber reads the question again :)
<stgraber> pitti: ubiquity seems to just depend on the gir package so I don't think any change in ubiquity is required
<stgraber> not sure why we still have an ubiquity task on that one ... I guess the easiest will be to test with a recent build and see if it works as expected...
<pitti> stgraber: ah, thanks
 * pitti removes ubiquity task then
<ScottK> kde-workspace should get in if we care about Lucid -> Precise for this milestone.
<pitti> was just looking at it
<pitti> ScottK: I'm inclined to accept it now; it doesn't make much difference on the images, but we'll respin anyway, and this looks rather safe
<pitti> we don't currently plan to respin alternates, but we could for this if you want
<ScottK> There's currently no tests done on the Kubuntu alternates so there's no retesting needed after a respin.
<ScottK> I'd be inclined to respin the alternates too.
<ScottK> Good night and thanks.
<pitti> ack
<pitti> ScottK: good night
<pitti> noted so in the pad
<slangasek> stgraber: libtimezonemap> do you have time to test that?
<slangasek> would like to make sure we get that tested asap so we know if another ubiquity change is needed
<slangasek> evan certainly seemed to think one would be
<micahg> it seems like I might need to upload a fix for icedtea-web (it doesn't affect the images, but no change packages would be picked up on ubuntu and kubuntu dvd respins)
<pitti> micahg: that sounds fine
<pitti> in fact, I could need a main package to get the publisher running for main and recompute Task: headers
<pitti> (for downsizing ubuntu desktops)
<micahg> ooh, sounds like fun :)
<pitti> I can also take that live-build upload, it's harmless enough (just fixing an example)
<micahg> there's no magical postinst syntax checker is there?
<pitti> sh -n ?
<pitti> I've seen that in some package's ruls file
 * micahg will have to build the package first, will try
<pitti> running all the scripts through sh -n and fail the build if that fails
<micahg> the issue is icedtea-7-plugin BTW
 * micahg wonders if doko_ is up yet
<pitti> not a very hacker-friendly time yet in Germany
<micahg> ok, I'll just test and upload a fix
<micahg> do I need an FFe to change which packages are seeded for Xubuntu?
<pitti> by the letter, I guess so; what do you want to change?
<micahg> well,we want to drop quadrapassel so we can get clutter off the images for the LTS, we were thinking of adding alacarte since it no longer depends on half of GNOME
<pitti> that seems fine
<micahg> I was goign to wait until after beta 1 to make these changes
<micahg> pitti: I think you need firefox-locale-en for it to function properly in the live enc
<micahg> *env
<pitti> micahg: oh, how so?
<micahg> well, you need one of the locales available I think
<pitti> it just ships en-GB and en-ZA stuff, the en-US is built int
<micahg> oh, really, nevermind them :)
<micahg> so it is, I remembered something breaking in my VMs without it, but maybe that was fixed
<micahg> looks fine though, so ignore me :)
<pitti> micahg: thanks for checking
<micahg> pitti: do we need to save that icedtea upload for something, I got 3 upgrade failure reports in the past 4 hours
<pitti> nope, accepting; thanks for fixing!
<micahg> I installed the bad package and then installed the fixed one, it finished upgrading, so I considered it a success :)
<micahg> pitti: thanks
<micahg> this is hilarious, we have arch skew where powerpc/armhf/armel is ahead of i386/amd64
<pitti> starting desktop builds for new ubiquity / kdebase-workspace on kubuntu
<micahg> pitti: should I replace hpijs with its equivalent in the seed?
<pitti> micahg: ah, please
<micahg> I'm doing a test rebuild on openjdk-6 on i386, if it's successful, I'll need some help getting it on a faster builder
<pitti> oh, didn't we just get a new build yesterday?
<micahg> yes, but it failed on i386
<micahg> I just wanted to make sure it's the builder and not the build
<micahg> but armhf/armel/powerpc finished just fine
<pitti> ah, presumably we don't run the tests there
<micahg> maybe we should just get it going on a faster build in any event since the build farm is free
<micahg> *builder
<pitti> java.util.NoSuchElementException doesn't sounds like it's related to out of memory or space?
<micahg> I have no idea
<jibel> good morning
<pitti> bonjour jibel
<pitti> micahg: so, I can hand it over to zirconium
<jibel> why upgrades are marked 'rebuilding' on the tracker ?
<micahg> maybe jamespage can help if he's around
<pitti> micahg: it's not like our i386 builders have terribly much to do ATM
<pitti> micahg: if you think it could work on i386; but amd64 is still building as well
<pitti> jibel: I don't know
<pitti> micahg: oh, https://launchpad.net/ubuntu/+source/openjdk-6/6b24-1.11.1-3ubuntu1/+build/3243935 just shows the exception as well
<pitti> (amd64 build)
<pitti> semop(2): encountered an error: Invalid argument
<pitti> it might actually be this, which might or might not be unrelated
<micahg> well, both of those buildds were slow (yellow and vernadsky), idk, maybe jamespage can take a look or we should wait for doko
<micahg> ah, still early for the UK as well
<pitti> micahg: congrats to your ubuntu seed commit, it was rev number 2000 :)
 * micahg wonders what type of prize comes with that
<nigelb> micahg: slavery ;)
<jibel> pitti, do you think I can re-enable them ? there's nothing mentioned on the pad
<pitti> jibel: fine for me
<jibel> pitti, k, thank
<pitti> jibel: I guess the Kubuntu one should be re-attempted as we got a kde-workspace bug fix this morning
<pitti> (one of the linked bugs)
<pitti> jibel: did you run into the "dpkg: already configured" issue in manual tests?
<pitti> that bug is still open and apparently breaking quite a lot
<jibel> pitti, I did once and bdmurray too
<jibel> I confirm bug 940196 with alternate 20120227.2. cannot upgrade from cd without network
<ubot2`> Launchpad bug 940196 in update-manager "cdromupgrade from Oneiric to Precise no network failed: The package 'unity-2d-places' is marked for removal but it's in the removal blacklist" [High,Triaged] https://launchpad.net/bugs/940196
<pitti> micahg: seems the amd64 jdk build hangs at the same position
<slangasek> jibel: yeah, I've diagnosed that one
<micahg> pitti: I'm 9GB into the test build
<slangasek> jibel: bug #940240> so there are no other term.logs lying around, that might have the output from installing?
<ubot2`> Launchpad bug 940240 in update-manager "lucid -> precise upgrade: dist-upgrade/apt-term.log only shows packages being removed" [High,New] https://launchpad.net/bugs/940240
<jibel> slangasek, no other term.logs. the only trace of packages installation is in dpkg.log
<slangasek> hmm :/
<slangasek> ok
<mvo> jibel: is /var/log/apt/history.log showing sensible data?
<mvo> its a bit mysterious as the log is opened with fopen(.., "a")
<mvo> in libapt
<mvo> jibel: this is only for the main-all build? or for all of them?
<jibel> mvo, looking
<mvo> jibel: the time stamps are pretty clearn, apt-term.log has 17:54 in the header but main.log starts at 16:19 :/
<jibel> mvo, only with main-all when debconf prompts are redirected to a file
<mvo> jibel: ohâ¦
<slangasek> mvo: hey, what's the package name for the backported apt used by the upgrader for lucid?
<jibel> mvo, i.e DEBIAN_FRONTEND is set to something else than noninteractive
<mvo> jibel: woah, that is interessting
<mvo> slangasek: its "Packages=libapt-pkg4.12,libapt-inst1.4,release-upgrader-python-apt
<mvo> "
<mvo> slangasek: it comes from the users ${mirror} with a fallback to archive.u.c
<slangasek> ah, the source is in universe instead of main, that's why I couldn't find it :)
<slangasek> mvo: thanks
<jibel> mvo, I think main-all is just a red-herring and the cause of the upgrade failure is due to puppetmaster failing to restart, which generate a failure in etckeeper
<mvo> yw
<mvo> jibel: right, I'm not concerned with the failure at this point, I'm just puzzled why the logs are not there :/
<jibel> agree
 * mvo scratches head
<jibel> mvo, history.log contains 3 lines
<jibel> mvo, start date, end date and a big remove in between
<mvo> jibel: so no trace of the  upgrade there as well? and no history.log.1.gz or anything like this?
<jibel> mvo, no, the dist-upgrade backup directory contains the installation of the upgrader itself
<Daviey> jibel: i thought the puppetmaster + etckeeper/bzr issue was resolved?
<pitti> hello Daviey
<Daviey> morning pitti
<pitti> nova is built now, so time to spin server images
<jibel> Daviey, which version resolved this issue ? I got it last Friday when I was looking why main failed.
<jibel> morning Daviey
<Daviey> pitti: yep, i was just looking over it right now :)
<Daviey> jibel: Hmm, perhaps it's a related issue.. I thought the LANG issue was to blame.
<Daviey> pitti: triggering now.
<Daviey> pitti: have you already triggered?
<pitti> server x86/armels building for nova
<pitti> Daviey: yes, something else missing?
<Daviey> Oh, no - it just explains why it crapped out on lockfile for me :)
<mvo> jibel: ok, here is my theory (and I think its correct) - there is no main log because the main upgrade was not run because dpkg-preconfigure failed with various "cups template parse error: Template parse error near `Description-sr@latin.UTF-8: elite li da CUPS ÃÂ¡tampa nepoznate radnje kao raw radnje?', in stanza #1 of /tmp/cups.template.192914" errors
<mvo> jibel: now of course that is a bug in the upgrader as it needs to record this as a failure :(
<mvo> jibel: hm, hm, maybe not, but its definitely something along these lines
<jibel> mvo, this error is still in the latest run but everything is logged correctly
<jibel> https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-main/37/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/bootstrap.log
<pitti> ubuntu desktop i386 is still a tad oversized; I made some seed changes to fix this, but I'll need a respin for this
<pitti> jibel, Riddell ^ would that sound ok?
<pitti> the previous respin is just from an hour ago or so, so not much lost there
<jibel> pitti, ok
<Riddell> pitti: good with me
<pitti> I think I freed a little less than a MB, which should suffice
<Riddell> ooh Kubuntu undersized :)
<pitti> also, ubuntu-meta was out of date relative to the images
<pitti> so that needs a rebuild
<jamespage> micahg, looking now
<pitti> Riddell: good morning
 * pitti updates pad again for up-to-the-minute status
<Riddell> "get israel on installer map" uh oh , that could get political
<ogra_> infinity, skaet, ac100 should be a "community supported" image ... not sure if it needs to be advertised in any official doc or not, it will be announced on the ac100 mailing list anyway ...
<didrocks> pitti: some news on the keybinding for switching ws, we will revert them for this cycle
<didrocks> pitti: I guess it will be a post beta1 thing?
<pitti> didrocks: unless you can upload it in the next hour or so
<pitti> didrocks: ubuntu desktop is scheduled for a rebuild, but need to wait for the DVD builds to finish
<didrocks> pitti: oh? that, I can :)
<pitti> didrocks: is that "unity"? because that takes a while to buid
<didrocks> pitti: it's compiz
<pitti> didrocks: and it would also invalidate the ARM images
<didrocks> takes a while as well, but a little bit quicker
<seb128> pitti, what images are planned for rebuild? I guess we want to avoid trivial changes like rhythmbox (fixing sound indicator integration) or nautilus (segfault fix)?
<pitti> seb128: so far I only plan to respin ubuntu desktop for the slight i386 oversizedness
<pitti> didn't plan alternates, ARMs, DVD, etc.
<pitti> didrocks: it's fine for you to upload, so that we can grab it in case we do want to rebuild the otherrs
<pitti> seb128: yes, I looked at those, and they didn't seem to be issues that couldn't be fixed with upgrades
<seb128> pitti, ok, I was pointing it in case, I'm always unsure what are the criteria for accepting updates or not when respins are done
<pitti> didrocks: I guess the hotkey is good enough for b1, given how this was firmly decided pre-b1? :-)
<seb128> pitti, but yeah, no deal breaker
<pitti> strictly speaking we'd need to rebuild alternates and DVDs as well for the new ubuntu-meta
<pitti> jibel: when do you think is the cutoff point for rebuilds when we still want to get good testing coverage?
<pitti> jibel: i. e. do we have room for another set of ubuntu alternates/DVDs?
<jamespage> micahg, getting nowhere fast ATM - I have to duck out for 1.5 hours - I can look again when I get back if its still not fixed...
<didrocks> pitti: hm, I staged the libjpeg-dev in c-p-m as well though :/
<micahg> jamespage: ok, do you think it's transient or a real failure though
<didrocks> pitti: as it's what I'm running now, I need to revert it if we want to sneak c-p-m in (for the keybinding revert)
<jamespage> micahg, probably real as it happened on i386 and amd64
<micahg> jamespage: I have a test build going right now that should hopefully be fnished in an hour
<pitti> didrocks: if you tested it, and it works with libjpeg8 (well, no reason to believe it doesn't), its' fine
<pitti> didrocks: compiz is 46 minutes on armhf, not too bad
<didrocks> pitti: sorry, it's compiz-plugins-main, not compiz
<pitti> didrocks: ah, that's 35 mins on armhf
<didrocks> pitti: also, that will trigger a "bug" (the shortcuts display is hardcoded in unity, but I guess its not such a big issue compared to the other issue ;))
<pitti> didrocks: please get it uploaded, and I'll see to it
<pitti> didrocks: yes, I noticed; it doesn't adapt to the actual keys
<pitti> didrocks: but no biggie for b1 indeed
 * didrocks rebuilds in a pbuilder to ensure everything is fine
<didrocks> pitti: will ping you once done and then upload
<pitti> didrocks: thanks; the queue-bot will pick it up, too
<didrocks> oh right :)
<pitti> queuebot: ping pitti on compiz-plugins-main
<pitti> (I wish this would work :) )
<pitti> queuebot: oh, and make me a cup of tea, please
<didrocks> :-)
<didrocks> pitti: almost ^ :p
<pitti> Riddell: any reservations against rebuilding the Ubuntu images for the compiz and ubuntu-meta updates later on? (I can handle this)
<pitti> seb128: nautilus looks easy, but is also on edubuntu and ubuntustudio, don't want to rebuild these
<seb128> pitti, ok, no worry, we don't really need it, I'm just trying to not get too much sitting in the queue because that leads to issues like uploads being rejected (cf my mail on the list)
<pitti> yeah
<Riddell> pitti: none from me
<jibel> pitti, yes I do have room. today all day is fine for rebuilds
<pitti> jibel: ok, great
<jibel> (european time I mean)
<pitti> ah, server daily-preinstalled done (x86, too)
<pitti> Daviey: ^ FYI
<pitti> should now have the new nova
<micahg> jamespage: pitti: I'm going to sleep soon, I'm sure doko will be around before I get up for openjdk-6, I can let everyone know how the test rebuild goes in ~7 or so hours, but I figure you'll have a solution for it by then
<doko> micahg, context?
<doko> ahh, I see
<micahg> doko: oh, hi :), the openjdk-6 builds failed on i386/amd64, but built on the rest
<micahg> this prevented icedtea-web (which I fixed) from building on the opposite archs of openjdk-6 due to arch skew
<doko> micahg, pitti: yes, seen. I re-enabled the testsuite. so the best "fix" for the beta is to disable it again (and magically bringing down build times)
<micahg> doko: so I can kill my local test rebuild then or is there some benefit to know if it succeeds?
<doko> micahg, won't succeed, I see the same here locally
<micahg> doko: ok, killing, thanks
<didrocks> pitti: uploaded, should be here soon
<pitti> didrocks: yay, thanks
<micahg> Riddell: is nm-applet hidden in xubuntu worth respinning for?
<pitti> micahg: your call, but it seems rather ugly to me
<micahg> pitti: ugly to not have it, I would agree with that :)
<pitti> micahg: if it was ubuntu, I'd respin, if I had a fix
<micahg> pitti: ok, I'll upload a fix in a few minutes (just a gconf setting)
<micahg> pitti: should I make my other changes as well (drop clutter/quadrapassel, add alacarte)?
<pitti> micahg: fine for me; better to have changes in beta than afterwards IMHO
<pitti> and today's still enough time
<Riddell> micahg: yeah just depends if xubuntu dudes can get it tested in time
<micahg> please refresh  my memory, do I have to wait a publisher cycle before regenerating a -meta package?
<micahg> Riddell: I see no tests done yet, so doesn't seem to matter
<pitti> micahg: not for -meta
<pitti> micahg: but you need to wait for two publishers to have seed changes propagated to Task: headers
<pitti> (and publish a package in the affected component, too)
<pitti> so that xubuntu-meta upload will provide that
<Riddell> -meta uses the bzr branch usually
<micahg> pitti: ok, thanks, should I add a note about the xubuntu rebuild to the pad?
<pitti> micahg: please do
<pitti> the only exception is if you seed a package that just got promoted
<pitti> that needs a publisher for the actual promotion to happen, as ./update verifies the component
<pitti> but that doesn't apply to xubuntu
<micahg> pitti: is the nm-applet issue important for the alternate also, I only marked it for the Desktop imge
 * micahg would think not
<pitti> micahg: yes, an alternate install would certainly have the same problem?
<micahg> oh, I would think that updates would run and pick up the new package
<micahg> ok, marked both
<micahg> pitti: nm-applet fix confirmed, can you release the xubuntu-default-settings package
<pitti> micahg: done
<pitti> updated pad with the build link
<micahg> pitti: thanks, I just uploaded the meta as well
<micahg> pitti: thanks for all your help tonight
<pitti> my pleasure :) thanks for having an eye on xubuntu
<pitti> Riddell: the pad says kubuntu arm was rebuilt for amarok, but http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/ only has an image for Feb 25?
<Riddell> pitti: I've not rebuilt kubuntu arm
<Riddell> so whoever wrote that is probably wrong
<pitti> Riddell: ah, I guess I was confused then
<Riddell> please do start off a rebuild if it's easy for you to do (I'm in the middle of testing)
<pitti> it said "package built" then
<pitti> Riddell: yep, doing
<pitti> running, pad updated
<pitti> ah, compiz-p-m built everywhere, excellent
<pitti> didrocks: ^
<pitti> waiting for publisher/mirror, then will rebuild
<didrocks> pitti: nice!
 * pitti makes use of the empty buildds and uploads some no-change rebuilds against fixed binarymangler
<pitti> (only packages which are not on any CD)
<pitti> for bug 875466, FTR
<ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
<pitti> hm, queuebot is blatantly lying about the seeds
<pitti> starting desktop/DVD ubuntu rebuilds for oversizedness and compiz
<pitti> starting ubuntun alternate for the same
<pitti> lunch, bbl
<barry> ScottK: my momma has a g5 power supply
<ScottK> ;-)
<pitti> http://cdimage.ubuntu.com/daily-live/20120228.1/
<pitti> yippie! non-oversized
 * ogra_ does an ac100 testinstall
<pitti> starting ubuntu arm image biulds
<ogra_> uh, why do you rebuild arm ?
<ogra_> just for consistency ?
<pitti> ubuntu-meta, the compiz bug fix, and seed changes
<ogra_> ah, well, compiz :P
 * ogra_ sighs ... still no keyboard selection offered in oem-config
 * ogra_ is searching his butt off to find the font size selection in the settings .... where did we hide it again ? the huge and clunky fonts are really to big for a netbook screen
<seb128> ogra_, in the a11y capplet you have a text size combo
<seb128> i.e small, normal, big etc
<ogra_> ah, thanks, you told me before ... sorry i forgot !
<seb128> no numerical value selector
<ogra_> its really really non intuitive
<seb128> but you can use ubuntu-tweaks or gnome-tweak-tools or gsettings or whatever
<seb128> indeed...
<ogra_> i can live with /small/normal/big ....
<ogra_> just finding them is really hard
<pitti> starting xubuntu alternate build
<seb128> ogra_, it's a known issue, upstream and our design team have been discussion way to improve that but that didn't get resolved yet
<ogra_> ah, cool, at least someone cares then
<NCommander> pitti: did someone lok at ubuntu-core last night?
<pitti> NCommander: I didn't do anything with core; what do you mean with "look"?
<pitti> does it need a rebuild?
<NCommander> 20:43:53 < skaet> NCommander, infinity - could you look at  the scripts and see if there are any other  spots that might need fixing as well....
<NCommander> 20:44:22 < skaet> (reference was in ubuntu-core set)
<jibel> pitti, another report "dpkg already installed" bug 942578
<ubot2`> Launchpad bug 942578 in update-manager "lucid -> precise server upgrade fail: dpkg: error processing dpkg (--configure): package dpkg is already installed and configured" [Undecided,New] https://launchpad.net/bugs/942578
<ogra_> hmm, what is akonadi and why is it installed on all my test installs ?
<ogra_> hmpf, looks like a kde app
<ScottK> It's only used by KDE, but it's not formally a KDE app.
<ScottK> No idea why it's in your test installs.
<ogra_> its also in the ac100 manifest, weird
<ogra_> not in any other arm manifest though ...
<ogra_> even though all images use the same seed
<ScottK> I don't see any non-KDE reverse depends/build-depends, so no idea.
<ogra_> ugh ... it also has kdepim installed
<ogra_> and kate
<ogra_> how the heck does that end up on the ac100 images
<ScottK> Well that would explain Akonadi anyway.
<ogra_> yeah, indeed
<ogra_> hmpf
<ogra_> bah, i assume it gets pulled in by ubiquity-frontend-kde somehow
<ogra_> not sure how that ended up on the ubuntu image though
<jdstrand> pitti: hi! fyi, I saw that libapache2-modsecurity briefly showed up on the server-ship seed. my team reviewed its inclusion for main in either oneiric or precise UDS and decided it was not suitable. is there a MIR for it?
<jdstrand> I don't see one...
<seb128> ^ dunno why the bot thinks pitivi is still in those seeds it's not
<jdstrand> fyi, I just upload a libxml2 security update. it is not required for beta1
<jdstrand> Riddell, skaet: ^
<jdstrand> (and hello)
<pitti> jdstrand: no, it was kind of an error
<pitti> jdstrand: I reviewed the seeds for packages which did not exist any more
<pitti> jdstrand: I removed most of them, but for some it looked rather straightforward to fix them
<pitti> jdstrand: like gcc-4.5-docs -> 4.6, etc.
<pitti> jdstrand: and libapache2-mod-security looked darn close to libapache2-modsecurity
<pitti> jdstrand: but I unseeded it again after I realized the universe deps
<jdstrand> pitti: I see, cool. thanks :)
<ScottK> pitti: Since the libxml2 upload is a security upload, what would you think about the idea of accepting it so it can be picked up opportunistically if there are respins and people will get it as an upgrade right away if not.
<ScottK> I hate the idea of leaving security fixes just sitting there.
<pitti> ScottK: no objection from me
 * ScottK looks around.
<pitti> Riddell: ^ ?
<ScottK> jdstrand: How does the copyright attribution in the upstream code change for a security update?
<ScottK> (was that part of an upstream patch)
<stgraber> slangasek: sorry, closed IRC before I could see your message... testing the timezone map now
<Riddell> what what?
<pitti> Riddell: asking about accepting the libxml2 security fix now, so that it's there for opportunistic pickup of new image builds (but we wouldn't respin just for that)
<Riddell> ScottK: weren't you muttering yesterday about keeping versions in sync :)
<pitti> Riddell: and I think it's a good idea
<Riddell> yeah go ahead
<stgraber> pitti: btw, did you see the discussion on bug 939450?
<ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
<NCommander> skaet: ping?
<pitti> stgraber: I saw the bug, yes; seems Luke will look into it?
<ScottK> Riddell: Generally, but I think leaving security stuff unfixed is an exception.
<stgraber> pitti: skaet and I were mostly wondering what'd be best to release note between "installer will explode if you choose manual partitioning outside of the live session" and "no accessibility in Ubiquity for beta 1"
<stgraber> pitti: he's working on it but isn't planning on having a fix for beta-1
<skaet> good morning
<pitti> no, certainly this is release note matter
<ScottK> OK, I see someone beat me too it.
<pitti> hey skaet
<skaet> good afternoon pitti,  any preference between which group of testers we warn away?
<pitti> stgraber: I think more like the former
<pitti> i. e. know that it crashes after which step
<pitti> skaet: the people who will run beta are still expected to be technical enough to know what manual partitioning is, I think
<skaet> thanks pitti.
<jdstrand> ScottK: the change to dict.c was part of the upstream patch
<ScottK> jdstrand: Thanks.
<skaet> Riddell,   looking back on last night's arm builds,  looks like kubuntu preinstalled failed.   Is root cause known?
<stgraber> skaet: are you adding that to the release note or want me to write it?
<skaet> stgraber,  please go ahead and add it.  :)
<Riddell> skaet: no sorry not got to arm at all yet
<Riddell> I'm planning on checking dvds then seeing if arm needs my attention
<ScottK> Although apparently we can test KDE on ogra_'s ac100 images just fine if we want.
<skaet> ScottK,  can you see if you can figure out why the Kubuntu preinstalled failed?  It was the only one of the preinstalleds from last nights run that has seemed to.
<ScottK> skaet: Can you point me to the log?
<ScottK> If I had to hazard a guess, I'd guess archive skew due to the kde-workspace upload last night.
<Riddell> ScottK: what do you mean by "ogra_'s ac100 images"?
<ScottK> Some KDE stuff crept onto them.
 * skaet trying to figure out path to kubuntu preinstalled log file...
<ogra_> Riddell, there seems to be some dependency weirdness on ac100, so akonadi, kdepim and kde-window-manager end up on the image ... pulled in by ubiquity-frontend-kde apparently
<Riddell> ogra_: on the ubuntu desktop image?
<ogra_> yep
<ogra_> only on ac100 though
<Riddell> no conspiracy theories please, not deliberate :)
<ogra_> hehe, no, likely my error ... but i havent found the root cause yet
<Riddell> something depending on ubiquity which needs a frontend so randomly brings in ubiquity-frontend-kde?
<ogra_> well, yes, but thats also the case on the other armel images
 * pitti waves good bye, need to run out a bit earlier today
<Riddell> good night pitti
<skaet> pitti, is there an external path to the log files or do I need to paste them into an email?
<ogra_> we have jasper depending on oem-config which in turn depends on ubiquity on the other armel images ...
<Riddell> ogra_: years ago I had to remove ubiquity from the seed and just add ubiquity-frontend-kde because ubiquity was brining in -gtk, so maybe it's that in reverse?
<ogra_> on ac100 jasper is replaced by ac100-tarball-installer ... which has exactly the same set of deps
<Riddell> mm, so depend on ubiquity-frontend-gtk before jasper?
<ogra_> other way round, but yes
<ogra_> (before ac100-tarball-installer)
<ogra_> the prob is that ac100-tarball-installer is a universe package and isnt seeded at all (due to the image being built from universe)
<ScottK> skaet: I found the copy from my email.
<ogra_> so i cant really play with seeds here ...
<scott-work_> i noticed that the ubuntu studio beta image is not available any longer in the tracker
<ogra_> but i guess i can cheat through a fixed dependency in the package or so
<scott-work_> anyone know the reason and when another image will be available?
<skaet> ScottK - goodness.   Was just about to email you the log I'd found in the system.  :)
<ScottK>  oem-config-kde : Depends: oem-config (= 2.9.22) but it is not going to be installed
<ScottK>  ubiquity-frontend-kde : Depends: ubiquity (= 2.9.22) but it is not going to be installed
<ScottK> skaet: At a quess, some kind of archive skew issue.  Can you try it again?
<skaet> ScottK,  as long as I'm not colliding with someing in progress - sure.   Let me check.
<skaet> Riddell,  are you driving the ubuntu ARM preinstalled rebuilds?  how close to done?
<ogra_> skaet, i think pitti triggered them
<Riddell> skaet: not today I haven't been
<ogra_> 3h ago
<skaet> Riddell, ogra_ - hmm... not seeing them run on nusakan,  maybe the pad is stale?
<Riddell> mm not sure, how do we find that out if he's away?
<Riddell> ogra_: do you have shiney new images?
<ogra_> well, he said he would do them for: "<pitti> ubuntu-meta, the compiz bug fix, and seed changes"
<ogra_> Riddell, i dont think so
 * ogra_ checks nusakans processlist
<Riddell> I can text pitti
<ogra_> nah, gimme a sec
<skaet> ScottK - bit of a mystery - there are some arm images on the tracker - anyone know if they work?   or just go ahead and retrigger?
<ogra_> yep, seems they are all done
<skaet> thanks ogra_
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20120228.3/
<ScottK> No idea.
<skaet> ScottK,  ok,  I'll just go retrigger since the builders aren't in use right now.
<Riddell> skaet: if ogra_ says they're all done what's to trigger?
<skaet> Riddell,  rebuilding kubuntu arm preinstalled images
<Riddell> oh cool, can't forget kubuntu :)
 * skaet didn't want to run into existing arm rebuild in progress...
<Riddell> ogra_: can't I really use a mobile phone charger to power this pandaboard?
<ogra_> you need a 5V 3A supply (better 4A)
<ogra_> any universal one will do (as long as the plug fits)
<Riddell> ogra_: so I can't just plug in a mobile phone USB connection?
<Riddell> my local shop doesn't have universal ones that fit
<ogra_> not if you want to use any graphical output, or any USB device
<Riddell> right
<Riddell> that would be handy for test installs, meh
<Daviey> ogra_: with a powered hub, you can still use serial console?
<ogra_> probably, i really wouldnt though
<ogra_> you *can* power the panda through the mini USB ... but thats not recommended and it isnt clear which parts of the board will work and which will fail
<ogra_> its good enough to test a u-boot serial console, but as soon as the kernel fires up devices things will fall apart
<Riddell> ogra_: which team did you end up on and which did Grue end up on?
<debfx> pitti: what do you think about rebuilding all the packages with the md5sums error (not just the ones in main)? I count 174 source packages
<skaet> scott-work,  I'm seeing the ubuntu studio image up there.   There was a full rebuild last night and the image refreshed - could that be the source of the ?
<Riddell> debfx: pitti is away, me and skaet are driving
<Riddell> debfx: what's the issue?
<debfx> Riddell: bug #875466
<ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
<skaet> 20120228.1 is the date tag
<debfx> it's not really relevant to the beta, we could just use the builders while they are idling
<ogra_> Riddell, GrueMaster is in QA, i'm in foundations
<ScottK> debfx: As long as they aren't on any images, it seems reasonable.
<skaet> debfx, would rather wait until we know we have good images.    There will be rebuilds likely today.
<ScottK> skaet: We can dribble them in so we don't flood the builders.
<skaet> ScottK,  its the picking them up and archive issues I'm concerned about.
<ScottK> ?
<ScottK> As long as he avoids seeded packages, I'm not sure what you mean.
<Riddell> debfx: looks like pitti already started, you can throw up the rest if you want to but maybe tomorrow when we are more certain not to need builders
<skaet> ScottK,  libxt is in main
<debfx> Riddell: ok
<ogra_> infinity, skaet, what about armhf+mx5 images ? arent they also "tech-preview" ?
<ogra_> (they should either go on the manifest as well, or ac100 should be removed)
<skaet> ogra_ if there is testers lined up for them. and we're spinning them as part of the release,  they should be on the manifest.   Please edit to get it correct.
 * skaet will stop trying to figure out what's in the manifest based on IRC traffic yesterday :P
<ogra_> skaet, k, i need to ask GrueMaster if he planned to assign testing time for them,
<ogra_> (he usually did, but i'm not sure he still does after all the changes)
<skaet> ScottL, scott-work  - could you also review and sign off (by putting the date) for Ubuntu Studio in https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<skaet> stgraber, highvoltage,  please review https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for Edubuntu to make sure its accurate
<skaet> Daviey - could you review https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for server and netboot
<skaet> Riddell,  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for Kubuntu
<stgraber> skaet: looks good
<Daviey> skaet: right
<skaet> superm1, https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest,  please review and sign off for mythbuntu
<Riddell> skaet: there's no powerpc on the manifest, does that mean we can stop making powerpc images?
<Riddell> because they do take ages to build
<ogra_> they arent supported in any way ... i guess thats why they arent on the list
<ogra_> i doubt we'll stop building
<Riddell> ogra_: neither is stuff like kubuntu-active but that's on the manifest page
<skaet> Riddell,  want to wait for cjwatson to come back before having that discussion - but it is being contemplated.
<Riddell> if they're just plain not being used we should stop making them, they take up our time
<ogra_> ++
<skaet> Riddell,  it comes down to testers being willing to test.   If there are no testers, then they won't go on the manifest.
<ogra_> but i was under the impression there was a userbase
<Riddell> a userbase is no good if there are no testers, and they're taking up our precious resources currently so I'm all for screapping them
<ogra_> tunr them off and see who shouts at you ? :)
<ogra_> *turn
<Riddell> ogra_: yes excactly :)
<skaet> Riddell,  agree that the builds would go much faster without them in.
 * Riddell notes that testing dvd images is so much faster with a usb stick than with dvds
<scott-work_> skaet: http://iso.qa.ubuntu.com/qatracker/milestones/208/builds/12720/testcases shows an image but clicking on the link tells me an image isn't available
 * ogra_ wishes he had even DVDs on arm ...
<skaet> scott-work,  looking...
<scott-work_> skaet: i navigated there from the web-sties's front page, not a direct link
<skaet> scott-work,  yeah,  I'm seeing it too.
<jibel> scott-work_, download link is not setup for studio dvd. I'll fix it
<scott-work_> jibel: thank you :)  (and you too skaet )
<skaet> http://cdimage.ubuntu.com/ubuntustudio/dvd/20120228.1/
 * ogra_ is out for 1-2h
<skaet> yes,  images is there.  just a link issue.
<skaet> thanks jibel
<GrueMaster> Morning.  There was a question directed at me?
<ogra_> GrueMaster, do you test mx5 ?
<GrueMaster> I test all arm images during milestone release.
<GrueMaster> If it is there, I will test it.
<ogra_> ok, then i'll add them to the manifest once i return, thanks !
 * ogra_ is out
<GrueMaster> After this cycle, we will reevaluate what I test and what I don't test.
 * skaet nods
<GrueMaster> Riddell: Ping me in #ubuntu-arm and I can help you bring up your panda.
<ScottK> skaet: I meant doing the ones that aren't in Main.
<skaet> ScottK,  it wasn't clear from the bug or post which was being refered to - so rather err on side of not letting things through that could cause problems - that's all.
 * skaet is fine with unseeded universe going through,  no probs.
<skaet> Riddell,  can you confirm that pad.ubuntu.com/ubuntu-release now matches your understanding of the state of things too?
<Riddell> skaet: yes I'd say so
<Riddell> skaet: are you doing the kubuntu arm rebuilds?
<skaet> Riddell,  yup there running,  should be done soon.
<skaet> Riddell,  can you confirm debian-cd/CONF.sh set to OFFICIAL  (I think it was done, but just double checking)
<Riddell> skaet: I did that yes
<skaet> Riddell,  :)   goodness,  was hoping to hear that.
<skaet> Riddell,  were all the team notifications on the checklist done as well?  or are some of them still pending?
<jibel> scott-work_, dl links added.
<scott-work_> jibel: thank you
<jibel> yw
<Riddell> skaet: mostly, which ones are you looking at?
<skaet> Riddell,  OEM and commercial engineering
<Riddell> skaet: no I don't think I did those
<skaet> Riddell,  ok,  will take care of
 * skaet didn't want to pester folks twice if you had
<Daviey> skaet: object to another server retwirl + automated testing?
<skaet> Daviey,  nope
<skaet> Daviey,  want me to kick it off?
<Daviey> skaet: no, i'm primed. :)
<Riddell> how come Ubuntu DVDs only have ubiquity tests?  do we not care about testing d-i on those images?
<skaet> Daviey,  please update the pad as you do it and when they're done, so we can avoid conflicts then.  :)
<skaet> Riddell, not sure.  slangasek ^  any thoughts?
<skaet> Daviey,  adding the reason for the server retwirl would be appreciated too.
<Daviey> skaet: i removed the reasoning.. which was an 'Oppertunity'
<jibel> Riddell, there's no d-i on Ubuntu DVDs, it's like a desktop image on steroids
<SpamapS> is 20120227 still valid? About to start some iso testing
<Riddell> jibel: hmm, interesting, that change didn't happen in kubuntu then
<Riddell> jibel: but that explains the smaller dvd size then
<Riddell> SpamapS: see http://iso.qa.ubuntu.com/
<Riddell> SpamapS: #ubuntu-testing is the best place for testing chatter
<Daviey> SpamapS: It's valid 'enough'.. I'm doing a respin to add acpid to the install, but i think the delta is small enough not to invalidate your testing.
<Daviey> err, but we are on *28
<jibel> Riddell, https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
<jibel> SpamapS, 20120228 is valid until Daviey rebuilds
<Riddell> jibel: do you know what this means? "Switch DVD images over to USB seeds: DONE"
<ScottK> Riddell: Now you can feel apachelogger's pain about work items. ;-)
 * ScottK revels in the irony.
<Riddell> hey I never wanted to do the WI system, we kept a full todo list in kubuntu until recently.  it's all rickspencer3's fault :)
<skaet> Daviey,  arm server or ubuntu server?
<Riddell> skaet: surely that teminology is obsolete, we're all arm now?
<skaet> Riddell,  yeah, you're right.  :)  Daivey are you doing the rebuild on arm or on i386/amd64
<skaet> if on arm - please hold off, so you don't stomp on the kubuntu preinstalled arm build inprogress
 * Riddell doesn't like being stomped on
<skaet> Daviey,  looks like it just finished,  if its arm you are ok,  but PLEASE indicate which builds are in progress once you launch them on the pad.
<slangasek> Riddell, skaet: we don't have d-i on the Ubuntu DVDs anymore, that was part of the downsizing
<skaet> thanks slangasek.
<slangasek> mvo: 940240> how do you reach the conclusion that the main upgrade was prevented from running?  the dpkg log shows all the packages being upgraded
<ScottK> skaet: So it succeeded?
 * ScottK sees no bad news in the inbox.
<mvo> slangasek: I logged into the test  vm  and a whole bunch of stuff was not upgraded, but you are right, the dpkg.log shows clearly that another bunch was upgraded successfully
<infinity> Riddell: PowerPC images are used, but certainly not in all flavours.  We can/should discuss cutting the set down.
<infinity> (That said, we were supposed to have another PPC buildd months ago...)
<slangasek> mvo: ok - and those upgraded packages don't show up in the term.log at all :/
<Riddell> ScottK: know of any kubuntu ppc users or can that be a quick one to kill?
<ScottK> Riddell: Tm_T was the only one I knew of and AFAIK his hardware is dead.
<Riddell> my mac died just after canonical stopped supporting it, so that was good timing :)
<Riddell> ok I'll look at killing the powerpc kubuntu builds
<mvo> slangasek: yeah, its really confusing, I poked around in the system and in the source and have no clue currently why this happens. oddly enough jibel told me that the next run has valid logs
<ScottK> Riddell: As long as there's a basic image people can use to install with, the can always apt-get install kubuntu-desktop anyway.
<slangasek> heh
<ScottK> I don't think we need to worry about extremely non-technical users on powerpc.
<slangasek> mvo: but isn't the next run done without the debconf redirection?
<skaet> ScottK,  yup 20120228.1 posted now.
<Daviey> SpamapS: 28.1 posted
<mvo> slangasek: I don't think so, its just a environment that should be valid for the entire life of the test-upgrade and I also don't get how it prevents apt from logging the output unless something in the dpkg-preconfigure for debconf does something crazy
<skaet> Daviey,  did you do the arcm builds or not?? - I see 28.1 listed for them but clicking on them doesn't give me an image.   (and arm server images usually take about 50 minutes :P )
<Riddell> skaet: in our upgrade tests on the iso tracker should we not have two for each flavour?  upgrade from oneiric and upgrade from lucid?
<slangasek> hmm.  where is the hook that's doing the debconf redirect?
<skaet> Riddell,  yup good point.   Can you add?
<mvo> slangasek: AutoUpgradeTester/UpgradeTestBackendQemu.py - but its just:
<mvo> cmd_prefix=['export DEBIAN_FRONTEND=editor EDITOR="cat>>%s";' % debconf_log]
<jibel> mvo, slangasek is right. with the redirection is fails and nothing logged excepted packages being removed and without is passes
<skaet> stgraber, jibel, ^ see Riddell's point about upgrade testing.
<Daviey> skaet: as yet, i've only built i386,amd64
<Riddell> I'll fiddle with the tracker :)
<jibel> mvo, the current main test passes and I only disabled the capture of debconf prompts. its the same base image
<mvo> jibel: right but the same thing works for e.g. server, correct?
<stgraber> Riddell: it's taking 8 hours to run all of these tests with only upgrades from Oneiric, upgrading from Lucid too would likely require me to find another machine to run the tests
<jibel> mvo, right, other images pass with the redirection enabled
<stgraber> Riddell: though I can add the tests cases on the tracker, they just won't get automated results
<skaet> Daviey, ack.  marking the arm ones as rebuilding then.   its misleading right now.
<slangasek> ScottK, Riddell: were there any changes to kubuntu dependencies around the 24th that could account for the changed LTS upgrade behavior in bug #940396?
<ubot2`> Launchpad bug 940396 in update-manager "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [High,New] https://launchpad.net/bugs/940396
 * mvo needs to get dinner now
<ScottK> slangasek: Not that I can immediately recall.
<slangasek> ok
 * ScottK looks
<slangasek> jibel: why is this job marked as "failed" when the upgrade seems to have completed? https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/
<ScottK> Actually the seeds got a serious rework on the 23rd.
<slangasek> ScottK: ah, I'll bet that's it; let me have a peek at those
<jibel> slangasek,  "package dpkg is already installed and configured" in apt-term.log
<jibel> slangasek, jenkins' UI is confusing, the artefacts  displayed on the summary page are from the last successful run
<stgraber> anyone knows what to change to have ".disk/info" in Edubuntu DVD say "12.04 LTS" instead of just "12.04". I believe that's the cause for both the desktop icon and ubiquity not showing the LTS for Edubuntu
<slangasek> jibel: oh sorry, I was looking at the latest successful one yes
<infinity> stgraber: debian-cd/CONF.sh, perhaps.
<infinity>     case $PROJECT in
<infinity>       ubuntu|ubuntu-server|kubuntu)
<infinity>         DEBVERSION="$DEBVERSION LTS"
<infinity>         ;;
<infinity>     esac
<infinity> stgraber: ^^
<slangasek> infinity: security builds are done in a chroot that doesn't use -proposed, right?
<infinity> slangasek: Right.
<stgraber> infinity: looks like it
<slangasek> infinity: heh; then bug #871083 in libpam-modules went away on its own
<ubot2`> Launchpad bug 871083 in gzip "gzip -9n sometimes generates a different output file on different architectures" [Medium,Fix committed] https://launchpad.net/bugs/871083
<stgraber> infinity: can you add edubuntu to that list?
<jdstrand> we don't use -updates either
<infinity> jdstrand: I assumed that was what he meant. ;)
<slangasek> (we have a fixed gzip, but it wouldn't have been used and it's hard to SRU verify :P)
<stgraber> infinity: I'm guessing xubuntu will want to be added too (as they have been approved for a 3 years LTS)
<infinity> Oh, that SRU hasn't actually been moved yet?
<slangasek> no
<infinity> slangasek: Maybe you just fixed it from a distance with a healthy combination of grumbling and angry eyebrows?
<slangasek> would it matter to move it, really?
<slangasek> infinity: no, the security build was picked up by yellow
<slangasek> which didn't give us this problem :)
<infinity> stgraber: Can do both, sure.  Are they the only two new LTSen?
<stgraber> infinity: yeah, so far, only Edubuntu, Kubuntu and Xubuntu have been approved for community LTS. Ubuntu Studio asked for it last week and it'll be discussed at the next TB meeting
<infinity> slangasek: And no, copying the SRU will do us no good in light of the fact that security builds still wouldn't use it.  But perhaps you could talk to the security team about making an exception for a silent security release of gzip too.
<slangasek> jdstrand: ^^ do you want gzip in oneiric-security, so security updates to pam don't risk regressing multiarch installability?
<ScottK> There has been stuff copied into -security before when it was needed.
<infinity> (It's certainly been done in the past when something non-security was needed for security sanity)
<infinity> ScottK: Jinx.
<jdstrand> yes, we pull back things from -updates as necessary
<skaet> stgraber, when did xubuntu get approved for the 3 year LTS?
 * skaet is a bit surprised, and notes that it isn't in the manifest. :P
<stgraber> skaet: at the TB meeting during the budapest sprint
<stgraber> skaet: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000922.html
<skaet> thanks stgraber
<infinity> stgraber: There isn't an "edubuntu" PROJECT anymore, right?  It's edubuntu-dvd, or something?
 * infinity just uses a * instead of hunting.
<Riddell> skaet: lucid upgrades added, I missed out wubi, I assume that doesn't do it?
<jdstrand> slangasek: yes I would, but I'm not sure when would be the right time-- normally we would just push it out with the update that needed it, but in this case it seems less clear
<skaet> Riddell,  not sure,  time to confirm with ev
<slangasek> jdstrand: well, next time you're building anything that has a multiarch library in oneiric I guess? :)
<jdstrand> slangasek: however, if you give us a package, I'd be happy to build it in our -security only PPAs and copy it to -proposed for you
<skaet> ev,  ^  does it make sense to test wubi upgrades from lucid to precise?
<slangasek> Riddell, skaet: ev is at a conference today
<infinity> jdstrand: It's already in -proposed.
<jdstrand> slangasek: when the SRU is approved, we can copy to -updates and -security
<skaet> slangasek,  ack.
<infinity> jdstrand: And has been for a while. ;)
<jdstrand> infinity: meh-- does it pull in anything from -updates? (I missed backscroll)
<infinity> jdstrand: Seems pretty unlikely, it's gzip.
<jdstrand> I'm thinking about a pocket copy to security
<infinity> jdstrand: But we can double-check that it doesn't contaminate.
<stgraber> infinity: edubuntu* sounds good, I'm never sure what it's called in the different places ...
<jdstrand> I think that would be good (and also unlikely, though a libc update could do it)
<slangasek> skaet, Riddell: I didn't think that wubi itself had an upgrade mode, this is just about testing that upgrades work within a wubi install; so if this worked from lucid->maverick, and works from oneiric->precise, I'm not sure an additional wubi lucid->precise upgrade test gets us anything
<infinity> jdstrand: Haven't had any libc6 updates in oneiric.
<slangasek> Package: gzip
<slangasek> Depends: dpkg (>= 1.15.4) | install-info
<slangasek> Pre-Depends: libc6 (>= 2.14)
<slangasek> that's on precise
<slangasek> on oneiric, the deps are similarly small, but with the right libc6 version ;)
 * infinity wonders who committed directly to /srv/cdimage.ubuntu.com/debian-cd/
<slangasek>  Pre-Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.4.0)
<slangasek> 2.4 looks safe
<ogra_> re
<infinity> stgraber: Alright, CONF.sh updated, as well as make-web-indices.
<jdstrand> slangasek, infinity: gzip seems ok to go to -security to me
<jdstrand> when is this happening?
<slangasek> when do you want it?  at the same time as -updates?
<jdstrand> I think that is best. We'll issue a USN for it, but be clear it is not for a vulnerability
<jdstrand> slangasek: so I guess can just use '-s' with sru-release and ping me
<stgraber> slangasek: I commented in bug 905754 after a quick test of the current image, current behaviour seems reasonable to me considering the number of cities in that area
<ubot2`> Launchpad bug 905754 in libtimezonemap "Israel is not on the installer map" [High,Fix released] https://launchpad.net/bugs/905754
<slangasek> stgraber: great, thanks for confirming
<Riddell> hmm this is getting political "I can confirm one can now select Jerusalem"  Jerusalem is not the capital of Israel
<ScottK> According to them it is.  Hard one to avoid.
<slangasek> the list of timezones has nothing to do with capitals
<Riddell> yes, it's only the rest of he world that doesn't recognise it
<ScottK> At a glance it's the only city listed for IST â Israel Standard Time
<ScottK> So that's how you'd have to select it.
 * Riddell out for the evening
<infinity> Seems politically dangerous for the IST key city to be anything but Tel Aviv, but what do I know?
<ScottK> It is what it is.  Not up to us.  For us it'd be dangerous to change it from whatever's normal.
<jbicha> the EST city is New York, not DC; Jerusalem is a larger city in Israel than Tel Aviv
<infinity> Fair enough.
<infinity> I get grumpy every time I have to select my timezone as Edmonton. :P
<stgraber> hehe, since I switched ISP, geoip thinks I'm in Rainy River, ON so not even the right timezone ;) (it's on CST and I'm on EST)
<ogra_> infinity, do you want to be the signoff contact for mx5 or should i ?
<ogra_> (you were it in the past)
<infinity> I'm fine with it.
<infinity> Although, I won't be taking my QuickStart with me to the release sprint.
<infinity> So, if the signoff should also be able to test, maybe you. :P
<ogra_> heh, i dont even have the HW
<infinity> Oh.
<infinity> Then me, or Jani.
<ogra_> GrueMaster said he would do the tests anyway
 * infinity nods.
<ogra_> k, adding you as signoff then
<infinity> Nothing more than a quick smoketest is needed anyway, it's unsupported.
<ogra_> right, like ac100
<infinity> I'll happily signoff on both mx5 and ac100, no need to make Kate run around and chase too many people.
<ogra_> even though i find the more intresting oem-config bugs in ac100
<GrueMaster> I'm the QA guy and I have both rev's of the HW.
<infinity> That was very AA.
<ogra_> GrueMaster, want to be the signoff contact for both ?
<infinity> "My name is Tobin, and I'm a toyaholic."
<ogra_> LOL
<GrueMaster> I actually figured I would be on the hook for most of Arm testing anyways.
<GrueMaster> Sure.
<ogra_> k
<GrueMaster> Both?
<infinity> ogra_: Just make me the signoff.  I'll be in Kate's TZ. :P
<infinity> I can bug Tobin for test results if I don't see any, but he's a very responsible isotracker user.
<ogra_> ok
 * infinity had some other changes to make to the manifest page anyway today.
 * GrueMaster considers enrolling in a 12 step program for PC Hoarders.
<ogra_> like NCommander ?
<ogra_> (well, apparently he at least tries to get rid of some 30yo HW)
<skaet> slangasek, thanks.
<GrueMaster> I still have my AT&T 3B1 (but Ubuntu doesn't run on it sadly).
<ScottK> ogra_: I think NCommander gets rid of it by giving it to GrueMaster.
<ogra_> heh
<ogra_> i think GrueMaster has enough already
<GrueMaster> Well, he is threatening to bring me his IA64 system.
<ogra_> be happy he has no s390 in a cabinet
<GrueMaster> heh.
<SpamapS> If I upload to precise right now, it will just be queued right? Don't want to break beta..
<skaet> SpamapS - yes it goes into queue.
<skaet> let us know what not to approve.  ;)
<skaet> unless its fixing a release critical bug... of course.
<Daviey> SpamapS: Why not just hold it until thaw?
<SpamapS> Daviey: yeah I think I will.
<Daviey> SpamapS: Yeah, it's been the case before that people have uploaded to stage, and some keen reviewer accepted it :/
<Daviey> LP doesn't offer a comment facility on the queue. :(
<SpamapS> yeah, I'll hold it.
<slangasek> from my perspective, it's better for folks to just upload to the queue
<slangasek> instead of holding things locally
<infinity> Ditto.
<infinity> If we choose to accept it, it's because we're respinning anyway.
<slangasek> "some keen reviewer accepted it" - then we should teach them not to do that if the packages aren't milestone-critical or safe :)
<Daviey> slangasek: you think that will change?
<slangasek> what will?
<Daviey> slangasek: People will know not to accept something that looks safe?
<infinity> The set of people with access to accept from unapproved isn't huge.  You'd think we could socialise this issue a bit better. :P
<Daviey> If it's not wanted in beta, why the heck upload during the freeze?
<Daviey> O_o
<slangasek> it's kinda definitional to the role of release team that you know what the hell you're doing wrt queue accepts
<infinity> Daviey: Why have a queue freeze, if we expect people to stop uploading? :)
<Daviey> slangasek: So i didn't get bitten twice last cycle?
<slangasek> Daviey: don't remember what you're referring to
<slangasek> I'm saying that release team members not knowing what they're doing wrt the queue is not a bug to be worked around by not using the queue
<Daviey> slangasek: Are you saying that uploads haven't been rejected when they were uploaded during a freeze, but really wanted to be accepted once the thaw happens?
<slangasek> no?
<slangasek> I'm saying that's not how it's supposed to work
<slangasek> and if that has happened, then we need to get people on the same page
<Daviey> slangasek: right.. there are two things happening here..
<Daviey> 1) People uploading things that *should* wait for post-milestone
<Daviey>  - these are either rejected, or just left ignored in the queue.
<slangasek> what is this "either"?
<slangasek> NOBODY should be rejecting such uploads
<slangasek> and if you're seeing them rejected, I want to know why
<slangasek> that's inconsistent with how the queue has always been defined
<slangasek> the only time a package should ever be rejected from unapproved during development is if it's been reviewed and found to be fundamentally broken and not appropriate to be accepted even after the freeze expires
<infinity> I don't start rejecting until final freeze (when I'm rejecting and saying "please upload to proposed")
<infinity> Well, yes, and the "broken" case.
<infinity> Daviey: During non-final freezes, the unapproved queue should look more like a delay than anything else.
<infinity> With the possibility of inclusion in the current milestone, if deemed appropriate.
<Daviey> slangasek: I know last cycle there were rejections happening incase a fellow release team member accepted them, as they looked sane.
<slangasek> Daviey: that seems unnecessary to me given that only milestone-critical fixes should be accepted during the freeze window
<slangasek> and it imposes a greater burden on the developers during the freeze, which is not what we want
<slangasek> so I'd really like us to fix that
<slangasek> do you recall specifics of who rejected what?
<Daviey> slangasek: Okay, well there seems to be inconsistencies, regardless.
<Daviey> slangasek: give me a minute
<ScottK> The bigger problem I've seen with the queue is developers uploading to the queue pending FFe approval and then when the queue thawed it got auto accepted because no one rejected it.
<slangasek> yes, that's certainly a problem
<slangasek> and falls under "not appropriate to be accepted even after the freeze expires"
<ScottK> Yes
<slangasek> so we could do with some clarification there as well for developers, I think
<ScottK> I also think there's room for "Low risk and we're respinning anyway" accepts.
<slangasek> well, I wouldn't expect any member of the release team to accept such a thing without having talked to the uploader to confirm it's considered safe for inclusion
<slangasek> precisely so that we *don't* get caught out by an uploader thinking they've staged something for after the milestone only to have it included
<ScottK> In that case I may be slightly guilty (last cycle, not this one)
<skaet> Daviey, infinity - armel+omap armel+omap4 armhf+omap - don't think these should be considered supported for 5 years.   separate line?
<Daviey> skaet: I raised that.. honestly, i don't know.
<infinity> skaet: Oh, in netinst?  The armel ones shouldn't be.  I'll move them.
<skaet> thanks infinity.
<infinity> (they will be anyway, mind you, so the point is more academic than anything)
<skaet> infinity,  its what we're doing 2 years from now with them I'm concerned about.  (point releases,etc.)
<infinity> skaet: Yes, and they'll be just as supported as armhf+same.
<infinity> skaet: Because the kernels are identical, as are the d-i bits.
<infinity> skaet: So, anything we fix on one fixes the other by accident. :P
<infinity> skaet: Hence my point that the distinction is academic.
<infinity> (But worth noting anyway)
<skaet> slangasek, ScottK - and put it on the pad that that's being done,  so surprises being minimized please.
<ScottK> OK.
 * ScottK didn't do anything recently.
<skaet> :)
<Daviey> infinity: I think it's more about setting expectations for SRU's IMO..
<infinity> Daviey: Yes, I know.  But in this very specific case, it's purely academic.
<infinity> Daviey: We're not going to magically release an SRU that breaks armel+omap4 (for instance) while preserving armhf+omap4, because the code is literally identical (at the kernel and d-i/netboot level).
<Daviey> ahh, right
<infinity> Daviey: At the userspace level, armel support may well flag over time, if something fails to build and no one cares why (though that still seems unlikely)
<infinity> Daviey: But at the netboot level, they're symlinks into each other.  They are precisely identical. :)
<Daviey> hah
<infinity> Anyhow, I still think there's plenty of value in communicating the "armel isn't supported" bit, so I've updated the manifest to communicate that.
<Daviey> rocking
<infinity> I wonder if maybe I should change "unsupported" to "best-effort" or something less harsh (thinking of the ac100 and mx5 "community kernels" here).
<infinity> But, meh.
<infinity> unsupported is accurate for a technical/release document.
<infinity> For the release notes, we might want to soften it (if we mention those subarches at all).
<infinity> s/notes/announcement/
<Daviey> infinity: lets create a working group to define the difference between 'unsupported', 'best-effort', 'community supported' and 'technical preview'
<skaet> infinity,  same wording as we use for unseeded packages in universe is probably appropriate.
<skaet> for the announce
<skaet> for the manifest - lets standardize on community supported and technical preview as appropriate.
<infinity> skaet: If you want to change my "unsupported" to "community supported", be my guest.  Though I think the former is slightly more accurate for the ones I marked. :P
<infinity> (Again, academically accurate anyway, in practice, nearly everything gets "supported" on some level or other... Until it doesn't)
<skaet> infinity - hadn't seen your latest...  not fussed by it at this point.
<infinity> skaet: :)
<skaet> Daviey - arm server rebuild done?
<skaet> (or even started yet?)
 * skaet not seeing anything in the processes
<skaet> stgraber,  jibel - any must fix bugs we're looking like we need to respin for,  from your perspective, or are we opportunity only now?
<skaet> slangasek, ^ ?
<Daviey> skaet: no, i didn't do that.. should i?
<infinity> If it's just for acpid, don't bother.
<Daviey> infinity: Does arm even have acpi?
<infinity> Daviey: The userspace tools?  Sure.  Actual ACPI implementations on any SoCs?  Not yet. :P
<skaet> Daviey,  you'd marked it on the pad - if mistake.  that's fine,  just want to get clean viewpoint.
<Daviey> skaet: did i?
<infinity> That [19] is someone's.
<Daviey> skaet: On the pad, i marked Ubuntu Server and Ubuntu Cloud Images. :/
<infinity> I've lost colour history. :/
<infinity> Anyhow, let me end the debate with 4 ctrl-Hs.
<skaet> he had it as [1] initially - I just changed it to [19]
 * skaet trying to keep numerical track of issues - reusing numbers in a release foils my attempts
<infinity> There.  No need to respin. ;)
<infinity> Problem solved!
<skaet> infinity,  :)
<Daviey> skaet: Ah, ok - i thought it was safe to recycle numbers.  But i didn't add the number to Ubuntu ARM*.. not looked at the history to see who did
<ScottK> infinity: What archs is kubuntu-active built for according to cdimage?
 * infinity checks.
<stgraber> skaet: there are a few ubiquity bugs I'm looking at but none should be critical
<infinity> ScottK: Just i386, according to default-arches.
<ScottK> Hmmm.
<infinity> ScottK: Not sure why Riddell set it up that way.  Maybe just for testing purposes (since he still doesn't have it working)
<ScottK> OK then.  Any idea about http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-active/precise/daily-live-20120228.log then?
<ScottK> You just shot my theory down.
<infinity> ScottK: Yeah, I imagine somewhere the image type is listed as "active" when it should have been "live" or "desktop" or some such.
<ScottK> Sigh.
<ScottK> where's the public cdimage branch again?
 * ScottK pulls out grep.
<infinity> bin/publish-daily:			kubuntu-active)
<infinity> bin/publish-daily:				TYPE=preinstalled-active
<infinity> bin/publish-daily:			kubuntu-active)
<infinity> bin/publish-daily:				TYPE=active
<infinity> I'm betting it's there.
<ScottK> Should be type preinstalled?
<ScottK> Well, not for i386
<ScottK> That should be live I guess
<infinity> The second one should be "desktop"
<ScottK> Ah.
<infinity> The first should be preinstalled-desktop, probably.
<ScottK> Wanna give it a shot?
<infinity> Actually, just removing the kubuntu-active stuff entirely and letting the cases fall through to *) should fix it.
 * infinity does.
<ScottK> Thanks.
<skaet> ScottK,  infinity - Riddell set it up that way out of respect for the arm server resources at my request...
<infinity> skaet: That doesn't explain why it doesn't build on amd64. ;)
<ScottK> skaet: Not building any images does conserve resources.
<infinity> But either way, one arch is fine for testing.
<skaet> infinity,  true.  :)
 * skaet fixated on the long time it takes to rebuild all our arm images.   :P
<infinity> ScottK: Retrying cron.daily-live for kubuntu-active.  Let's see if it works any gooder.
<ScottK> Thanks.
<skaet> ScottK,  image hasn't built yet - wanted it cleaned up and working well on fast rebuild architecture before we considered any other spins. :P   It was added after feature freeze....
<infinity> (Maybe I'll check back after I have some lunch, I just realised how late it is)
<ScottK> skaet: Right, I'm just trying to get it working on i386 (per the note on the pad)
<slangasek> curious, who needs acpid for what?
<skaet> ScottK,  :)
<skaet> slangasek,  Daviey, server respin.   cleaning up cruft now
<slangasek> I thought acpid was on its last leg, I'm surprised to see server pulling it in
<skaet> slangasek,  anything that should be added from your perspective?
<skaet> ie.  any blockers we're expecting fixes for shortly.
<slangasek> skaet: no - are you and jibel happy with the set of outstanding ubiquity bugs?
<skaet> slangasek, bit concerned about autotesting of updates from lucid failing.
 * skaet not thrilled at some of the bugs - but doesn't think fixes will emerge out of thin air either
<slangasek> well, upgrade bugs generally don't/shouldn't require a CD respin
<Daviey> slangasek: kvm cannot be rebooted without acpid.
 * slangasek blinks
<Daviey> slangasek: suprised?  This has been known since at least Hardy :/
<Daviey> slangasek: I mean via libvirt.
<slangasek> oh, because libvirt is generating an acpi powerbutton event?
<Daviey> right!
<slangasek> yeah, that makes sense
<slangasek> so acpid had fallen out of the seed?
<infinity> ScottK: So, that produced some sort of ISO.  No idea if it works, but there it is. ;)
<infinity> ScottK: http://cdimage.ubuntu.com/kubuntu-active/daily-live/20120228.1/
<infinity> ScottK: Obviously the pretty headers need some work to make them more informative (and prettier), but whatever.  That's cosmetic.
<ScottK> \o/
<ScottK> Riddell: ^^^
<ScottK> infinity: Thanks again.
<infinity> ScottK: NP.
 * infinity should have actually eaten lunch instead of making tax-related phone calls. :/
<skaet> infinity,  https://bugs.launchpad.net/launchpad/+bug/885739 - code branch on hold for merging :D
<ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
<stgraber> skaet: looks like that's just the DB part so far, there isn't any actual code change that I can see in there
<skaet> stgraber,  its progress though... but thanks for letting me know I shouldn't get too excited.  :)
<stgraber> skaet: it'd be great to have it for final freeze but otherwise we can probably survive till 12.10 :)
 * skaet not so sure about that.... ;)
<Riddell> ooh infinity, how did you fix it?
<infinity> Riddell: Removed the kubuntu-active special-casing from publish-daily.
<infinity> Riddell: You were claiming they were type "active" and "preinstalled-active" which was patently untrue, they're *desktop images.
<Riddell> that would be because they were type mobile for kubuntu-mobile
<infinity> Yeah, probably.  The world has moved on since then. ;)
<infinity> Riddell: There may be other places where those assumptions could use a tidying.  I'll re-review your commits later with that in mind.
<Riddell> lovely, thanks infinity
<infinity> Riddell: But at least x86ish desktop stuff should build and publish well enough to test.
<GrueMaster> Any ETA on the arm server images?
<skaet> stgraber, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/942836 - you aware of this one?
<ubot2`> Launchpad bug 942836 in xorg "unity does not appear" [Undecided,Confirmed]
<skaet> GrueMaster, all arm server images should be up on the tester.
<GrueMaster> "Download	Ubuntu Server armhf+omap4 (rebuilding)" is what I see.
<skaet> hmm... except for server - it appears.   looks like something needs to be cleanded up there.
<skaet> in the backscroll,  I think I saw that Daviey and infinity agreed it didn't need respin for acpid - so the prior version should be good.   I'll reset the iso tracker to that now.
<GrueMaster> ok, thanks.
<skaet> GrueMaster - looks like we have link problems there to that entry too... :P
 * skaet checking on details...
<slangasek> acpid's not relevant on armhf images, no
<skaet> hmmph...  there are 20120228.1 images.
<skaet> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120228.1/
 * infinity notices that he forgot to clean up armel+ac100 from cdimage.
<infinity> La la la.
<GrueMaster> infinity: ogra wanted to keep that image as we don't have armhf video drivers.
<infinity> GrueMaster: Oli and I discussed it.
<infinity> (As did others)
<infinity> GrueMaster: I already disabled it, just didn't remove the cruft.
<GrueMaster> Ok.  I wasn't in that conversation I guess.
<GrueMaster> slangasek: acpid is not used on arm, but it shouldn't warrant a respin either.
<slangasek> yes, the respins were about getting acpid *into* images
<skaet> GrueMaster,  links should work now
<skaet> jibel, stgraber - don't quite think I set the links up correctly (used current, am thinking there should be a substitution variable), can you review/fix for ubuntu server armhf images when you get a chance.
<GrueMaster> Can someone release openjdk-6-jre-libs?  My netboot images require it for testing (jenkins).
<infinity> GrueMaster: Release it from where?
<skaet> yeah,  not seeing it in unapproved.... ?
<infinity> Nor new.
<GrueMaster> I'm seeing package skew.  Just a sec.
<infinity> Is it arch:all?
<infinity> openjdk-6 was FTBFS on i386.
<GrueMaster> (might be my local mirror, but doubtful).
<slangasek> it is :all
<infinity> Then that's the issue.
<slangasek> and it's *not* FTBFS on i386, but it is on arm*
<infinity> slangasek: Err, LP tells me a different story.
<infinity> https://launchpad.net/ubuntu/+source/openjdk-6/6b24-1.11.1-3ubuntu1
<GrueMaster> Same here when I checked yesterday.
<slangasek> oh heh
<slangasek> no, it's only FTBFS on x86 and builds on arm* and powerpc
<infinity> Right.
<skaet> infinity, slangasek, NCommander - will be afk for a good part of my evening.  Will check on things tonight.   Pad is up to date - please log any changes to the pad.
<slangasek> sorry, this was such an unlikely outcome that I didn't compare the version numbers
<infinity> Which means no new arch:all bits. ;)
<slangasek> skaet: ok
<skaet> thanks!  :)
 * skaet --> afk
<infinity> slangasek: On behalf of every ports maintainer and user everywhere: THPT!!
<infinity> Or something.
<GrueMaster> +1
 * infinity so rarely gets these opportunities.
<GrueMaster> heh
<GrueMaster> Although to be fair, I think it builds on arm (and other ports) is we disable something like 90% of the post-build tests.
<infinity> Shh.
<GrueMaster> :-|
<GrueMaster> Links (or at least versions) for ubuntu-core need to be updated on the iso tracker.  Most are 20120228, one is 20120228.1.
#ubuntu-release 2012-02-29
<infinity> GrueMaster: That's cause only one was rebuilt.
<infinity> GrueMaster: So, the others are identical in 28 and 28.1
<GrueMaster> Ok, well it screws up automated testing, but I can live with it.
<GrueMaster> Any guestimated eta on the openjdk issue?  Or should I temporarily remove it from my netboot image automation?
<doko> slangasek, infinity: I can upload openjdk without running the tests if required
<slangasek> I don't think that's worthwhile; I think GrueMaster should just drop it from the automation for now
<GrueMaster> slangasek: The problem with dropping it is I can't run any tests w/o it, so I have to manually install it from LP (there is an arm package there).
<slangasek> can't run any tests without it?
<GrueMaster> we don't have libvirt to work with like the QA team does.
<slangasek> sorry, I thought you were saying it could be easily removed from the pipeline
<GrueMaster> I can install without it, but not run tests.
<slangasek> well, even if it gets uploaded, it'll take several hours to build on arm again
<slangasek> doko: what's the eta for a proper fix?
<GrueMaster> It's already built on arm.
<GrueMaster> Just the arch-all bits are coming from x86 to the mirror.
<slangasek> yes; I was assuming the packages had to be in sync to be installable
<slangasek> but it looks like they don't
<slangasek> the i386 build took 12 hours to fail last time; I wonder how long it takes to succeed
<GrueMaster> They do.  openjdk-6-jre-headless : Depends: openjdk-6-jre-lib (>= 6b24-1.11.1-3ubuntu1) but it is not going to be installed
<slangasek> no, it requires openjdk-6-jre-headless to be *newer* than the arm build
<slangasek> not in sync
<slangasek> so a build on i386 would be sufficient to make it installable
<slangasek> GrueMaster: why does openjdk get installed in-line as part of the tests?  The tests themselves are written in java?
<GrueMaster> Jenkins is written in java.  The tests are automated through jenkins.
<slangasek> I don't see why that involves running java on the host system
<GrueMaster> And as more tests come online, the longer they take to run.  Doing it manually is very time consuming as I have to babysit each test otherwise.
<GrueMaster> Host system?  Each platform is independent.  I don't have the luxury of tapping into a kvm session to launch jobs.
<GrueMaster> (which is how QA is currently running most of their tests).
<GrueMaster> Java is pulled in during netboot imaging along with jenkins-slave to start running on reboot.  Tests are queued up waiting for the system to finish reimaging.
<GrueMaster> If I had an entire team working on arm QA, I might have come up with a better solution.  Unfortunately, I only have a team of me.  And this is how it is currently set up.
<slangasek> ah, so the slave has to run on the host system to receive the jobs. ok.
<slangasek> well, I'm not sure getting openjdk-6 rebuilt on i386 is going to be any faster than hand-installing the packages from launchpad
<slangasek> all the same
<slangasek> doko: could you go ahead and upload openjdk-6 with the tests disabled?
<GrueMaster> the easiest solution would be to backrev the pool to the previous version.
<infinity> That's an odd definition of "easy".
<infinity> (As in, it's really, really not easy at all)
<GrueMaster> Neither is re-engineering automation around package skew, but it looks like I'm stuck with it.
<doko> slangasek, spend most of the time on it today on that. it's something which comes and goes, until now only seen with cacao and zero, now for the first time with hotspot :/
<slangasek> doko: ok
<ScottK> infinity: It's a question of easy for who.
<smoser> hi. i have 2 uploads in waiting-for-approval that i'd like someone to consider.
<smoser> cloud-init, and cloud-utils.
<smoser> cloud-utils is more straight forward, the issue and fix were diagnosed fairly thoroughly.
<doko> slangasek, in the queue
<smoser> cloud-init, i'd like to have these changes in for beta, but i will not be too upset if someone says "you're too late".
 * GrueMaster reverts to un-automated "smoke" testing.
<smoser> so, there is my plea. i have to run. if there is a question, i'm fine with either being held off, but personally think both are small in scope.
<slangasek> smoser: which images are impacted by these changes?
<slangasek> is it only the server EC2 images?
<slangasek> smoser: AFAICS we don't even have any candidates for server EC2 posted yet, so provided that those are the only images affected, it should be straightforward to accept both of these
<slangasek> ah, cloud-utils is on the main server images
<slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
<infinity> 18:35 < slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
<slangasek> smoser: both cloud-utils and cloud-init accepted
<slangasek> doko_: see above in case infinity's repost didn't highlight you - I'm unsure of these GC[CJ]_SUFFIX changes included in the openjdk upload
<slangasek> marking !arm server for respin on the tracker
<GrueMaster> erm, why?
<slangasek> !arm
<ubot2`> ARM is a specific (RISC) processor architecture used in a variety of applications such as handhelds and networkdevices. For more information see https://wiki.ubuntu.com/ARM . For ARM specific support, stop by the #ubuntu-arm channel.
<slangasek> no thanks, bot
<slangasek> SpamapS: perhaps you want to delay your RAID test in light of this respin
<GrueMaster> Oh, not arm.  ok.
<doko_> slangasek, infinity: rejected and re-uploaded
<doko_> now off to bed
<slangasek> openjdk-6 accepted
<SpamapS> slangasek: thanks for teh heads up. I have been debugging a problem in the RAID tests actually :p
<slangasek> looks like openjdk-6 is nearly done building on powerpc; I suppose we might as well wait for it to finish before respinning the server CDs
<skaet> slangasek, makes sense.   Daveiy should be coming on line soon, and it take <15 minutes to build it,  so suggest letting him trigger it.
<SpamapS> Would we be at all interested in adding a PowerMac G5 1.6Ghz to the powerbc buildd farm I wonder? I have one sitting here gathering dust under my desk. :-P
<ScottK> infinity: ^^^
<ScottK> You could do ISO testing ...
<SpamapS> ScottK: I've considered it, but I've always felt that if no other users than me, with my unused G5, step up to do that testing.. then why go through the trouble?
<ScottK> There are still a few powerpc users.
<ScottK> We just recently lost our last known Kubuntu user to hardware failure, but there are server and Xubuntu users)
<micahg> xubuntu stopped building powerpc images due to lack of testers, if we have testers, we can start again
<micahg> I think lubuntu was going to try to do powerpc images
<slangasek> openjdk-6/powerpc accepted
<slangasek> GrueMaster: that does mean openjdk-6 should be fixed again for your purposes
<GrueMaster> slangasek: Cool thanks.  I'll probably have to wait anotehr 25 minutes for my mirror to refresh though, but great.
<GrueMaster> (netboot installing from ports.ubuntu.com is extremely slow).
<GrueMaster> And I seem to be fighting an issue with oem-config-gtk on beaglexm.  It seems to be hanging at the keyboard layout screen.  Passed on mx5, checking panda now.
<GrueMaster> This doesn't bode well.  I'm seeing issues with oem-config-gtk hanging at the keyboard layout screen on both omap & omap4 images.
<pitti> skaet: external path to log files> which log files? we do have public URLs for live fs and CD build logs indeed
<pitti> debfx: yes, I'll do that; but wanted to do in steps
<pitti> debfx: let me start the big universe package check, will take a few hours anyway
<GrueMaster> sigh.  I think the latest ubiquity patches have hosed arm desktop images.
<GrueMaster> And this would explain why mx5 works:
<GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+omap4.manifest:oem-config-gtk     2.9.22
<GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+mx5.manifest:oem-config-gtk       2.9.21
<GrueMaster> grrr.  mirror is failing checksums.  refreshing with cdimage.
 * GrueMaster needs sleep soonish.  Getting loopy.
<GrueMaster> Can someone verify the MD5SUMS for http://cdimage.ubuntu.com/daily-preinstalled/20120228.3/ images?  After refreshing my mirror, I am still failing 4 out of 7 files.  Also, manifests indicate that ac100 and mx5 images were not respun with omap & omap4.
<GrueMaster> And Ubuntu Desktop armhf+mx5 is missing from the tracker.  I have a bug filed for an issue specific to it.  Bug 943058.
<ubot2`> Launchpad bug 943058 in linux-linaro-lt-mx5 "Kernel doesn't support usb on newer rev quickstart boards." [High,New] https://launchpad.net/bugs/943058
<infinity> SpamapS: We have a fair few powerpc users.  The assertion that testers=users is provably false.
<infinity> SpamapS: (Of the potentially millions of x86 users we have, how many "step up" to do image testing? :P)
<GrueMaster> Someone should add it to the automation testing.  :P
<infinity> GrueMaster: Erm, hrm.  None of those images match the md5.  Something may have gone wrong there...
 * infinity is tempted to just respin them overnight...
<GrueMaster> That kind of makes me feel better.  I thought I was losing it.
<infinity> GrueMaster: Our conclusions aren't mutually exclusive. ;)
<GrueMaster> Hold that thought for a minute.  I appear to be having issues with oem-config 2.9.22 (which appears to be only on the omap & omap4 images).
<infinity> What sort of issues?
<GrueMaster> yep.  2.9.22 is not working for me.  I just started 20120228.2 omap4 image and it went right through the keyboard layout with no problems.  It hangs there on 20120228.3 images.
<infinity> Keyboard layout, eh?  Drat.  That was definitely code that was mangled in that upload.
<GrueMaster> Yes, I know (I read the bzr log).
<infinity> stgraber: Your keyboard dialog locking/timeout tricks may be breaking oem-config (or breaking ARM, but arch-specific seems unlikely?)
<GrueMaster> I'm not sure x86 really tests oem-config.  QA's current test (that I know of) checks to see that it gets installed, not much else.
<GrueMaster> I could try it in a VM here, but it will have to wait til morning.
 * GrueMaster is feeling a bit punchy and sleep is higher on the priority list.
<infinity> Sleep is probably a saner idea.
<GrueMaster> My thought exactly.  Wouldn't want to flood lp with "keyboard repeats when tester's face implants on it after passing out" bugs.
<infinity> Seems like a valid bug.
<infinity> I still think we need to ship cat detection software by default.
<GrueMaster> If only they had keyboards that provided electric shock "education" for those instances.
 * GrueMaster EOD.  Back in 8h.
<pitti> I'll use the empty builders for some more no-change rebuilds for bug 875466
<ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
<pitti> (unseeded universe packages)
<pitti> debfx: ^ FYI
<pitti> I'm done with the first batch; I let the buildds catch up now
<jibel> skaet, dl links fixed for arm server
<jibel> GrueMaster, what's issue with keyboard and oem-config on arm ? do you have a bug number ?
<jibel> GrueMaster, I filed bug 942560 yesterday, is it the same ?
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<jibel> GrueMaster, and I test everything single desktop install manually if that can make you sleep better.
<Riddell> Daviey: server images still to be rebuilt?
<Riddell> or am I reading the pad wrongly?
<pitti> the builders (except ppc) are empty again; would you mind if I uploaded the next batch of rebuilds for the md5sum fixes?
<pitti> Riddell: ^
<Riddell> pitti: go for it
<pitti> ack, brace for impact, queuebot
<pitti> batch of 24, some 50 to go after this
<Daviey> Riddell: no, they were all built.. done
<Daviey> Riddell: oh, wait.. smoser cloud fixtures?
<Daviey> Riddell: We don't need to rebuild for them.
<jibel_> Daviey, server are marked for rebuilt on the tracker and last build is 20120228.1
<Daviey> jibel_: who marked that?
<Daviey> jibel_: ah, seems slangasek did.
<Daviey> I spoke to smoser last night, and it seemed we only really cared about these fixes landing in the cloud images.
<Riddell> Daviey: shall I mark that you don't want a rebuild and current images are good?
<Daviey> Riddell: Well, it's not too expensive to respin tbh.. I plan to human smoke test shortly anyway, and the other test cases are automagic.
<Riddell> Daviey: ok so you do want a rebuild?
<Daviey> Riddell: on it now... for non-arm
<Riddell> Daviey: "on it" meaning you are doing the rebuild?
<Daviey> Riddell: yes
<Riddell> groovy
<jibel_> Daviey, ok, you were faster than me reading scroll back
 * micahg wonders why vlc was accepted since it's on the mythbuntu images
<pitti> eek, sorry about that, that was my fault ^
<Daviey> micahg: Mythbuntu needed that fix for the kfreebsd and powerpc port. :)
<pitti> so, if we need to respin and vlc is broken, I can upload a reversion (but hopefully we won't)
<micahg> Daviey: vlc was already fixed on powerpc
<Daviey> pitti: it 'looks safe', i wouldn't panic!
<pitti> Daviey: yes, I'm not :)
<micahg> it does reenable a feature that was disabled with the 2.0 upload (v4l2
<jdstrand> that ^ does not need to go into beta1
<scott-work> skaet: techincal overview for ubuntu studio done
<scott-work> skaet: sorry i haven't been as invovled lately, work has gotten incredibly busy lately
<utlemming> stgraber: can I have you add http://cloud-images.ubuntu.com/precise/20120229.1/ to the ISO Tracker?
<smoser> Daviey, Riddell i dont tihnk that cloud-utils or cloud-init is in the server iso, is it?
<smoser> (ie, there would not be need for respin of those due to those changes)
<infinity> smoser: Doesn't look like, no.
<Daviey> smoser: waaat
 * Daviey screams.. 
<Daviey> smoser: it's in the pool
<Daviey> well, -utils is
<infinity> It is?
<infinity> cloud-image ends up in ship?
<Daviey> no, cloud-utils pkg.
 * infinity sees nothing in the tasks that indicates that.
<infinity> Unless it's a dependency of something.
<Daviey> infinity: http://cdimage.ubuntu.com/ubuntu-server/daily/20120229.1/precise-server-i386.list
<infinity> Ah-ha.
<infinity> euca2ools pulls it in.
<infinity> Which is, in turn, in server-ship.
<infinity> Anyhow, respinning for things in the pool but not installed by default isn't necessarily worth the effort for non-final images anyway.
<smoser> and the change that is included would not affect install
<Daviey> right.. which was why i said we didn't need a rebuild for them..
<Riddell> Daviey: but it is respun?
<Daviey> but conversation between smoser and slangasek seemed to supersede that
<Daviey> Riddell: it was.
<smoser> i'm confused. cloud-images need it included.
<smoser> and it is in the 20120229.1
<infinity> Daviey: Is there a reason, BYW, why nova-compute-xen doesn't get to be in main with the rest of openstack thingees?
<Riddell> Daviey: best get your guys testing :)
<infinity> Daviey: Or do we just flat our refuse to support xen, despite using it internally? :P
<infinity> s/our/out/
<Daviey> infinity: I believe that was legacy from when xen was still universe.
<Daviey> Riddell: Thankfully, my guys are mostly virtual machines.
<greyback> Hi guys, question about freeze exceptions. One feature we've nearly ready now would be easiest merged (and reviewed) in several MRs.
<greyback> For a FFe request, is it ok to list these MRs, and build package of code with all the MRs merged in?
<Riddell> greyback: yes that's fine
<Riddell> greyback: file a bug, list all the useful information, subscrube ubuntu-release and ping here
<stgraber> utlemming: looking in a sec if nobody beats me to it
<utlemming> straber: :)
<stgraber> infinity: is it reliably broken for you? I can reproduce the UI locking up on x86 too but it depends on how quickly you click on stuff and if you select keyboard variants
<stgraber> infinity: I started looking into the right way of fixing the bug yesterday, will continue today. If it's always broken for you, I guess I'll just revert my commit and re-introduce the bug where using your keyboard to select layout freezes the dialog
<stgraber> utlemming: does that look good?
<infinity> stgraber: I haven't tested it, I was relaying GrueMaster's claims.  But I think he was seeing it lock up with reproducibility.
<infinity> stgraber: I believe he opted for sleep instead of filing a bug, but he'll be online in an hour or three for you to ask him about it, I'm sure. :)
<stgraber> ok
 * stgraber really doesn't like the ubi-console-setup debconf/console-setup black amgic...
<stgraber> it's clearly racy but there isn't a good way of preventing the race, at least not that I could easily figure out in ubiquity. Last night I started digging into the debconf/console-setup part to try and fix the problem there instead of the UI
<utlemming> stgraber: yes, sir, thank you kindly3
<jibel> stgraber, there's a problem with ltsp. the client starts compiz even if it detects that 3d is not supported and the desktop is unusable.
<stgraber> jibel: sounds like a problem with unity/nux/compiz more than with ltsp...
<stgraber> jibel: I'm guessing they thought that as the check is now done by lightdm there's no reason to run it in unity too, and they'd be wrong as not everybody uses lightdm
<stgraber> didrocks: ^
<didrocks> stgraber: as told to jibel, I don't really have the time to look closely at that, but I need more info from the LTSP side as how it works
<stgraber> jibel: we could hardcode to use ubuntu-2d in LTSP but that'd be wrong as there are thin clients perfectly capable of running unity-3d
<stgraber> didrocks: LTSP basically opens a session on the server, sets DIPLAY= to point back to the client, then calls /etc/X11/Xsession <session> directly
<Riddell> is there actually any advantage in using unity-3d over unity-2d?
<didrocks> stgraber: so, you don't use lightdm, right?
<stgraber> didrocks: so my guess is that doing so bypasses the nux-whatever check
<stgraber> didrocks: correct
<didrocks> stgraber: so, you get the second check
<didrocks> stgraber: which is done by gnome-session
<didrocks> stgraber: I would need you to run gnome-session --debug on a LTSP config
<didrocks> while starting the session
<stgraber> didrocks: ok, hold on a sec, doing that now
<jibel> stgraber, didrocks , I'm filing a bug. I think it can be release noted for B1 as selecting 2d loads the 2d session.
<stgraber> jibel: yeah, release note is fine, I just want to make sure we know exactly what the bug is and can have it fixed first thing after beta-1
<dobey> does https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/934270/comments/15 make sense to release team?
<ubot2`> Launchpad bug 934270 in ubuntuone-control-panel "We need to drop the current GTK+ UI in favor of the Qt UI" [Undecided,New]
<stgraber> didrocks: it's an LTSP bug
<stgraber> our dmrc parsing is wrong
<didrocks> stgraber: ah see!
<didrocks> :)
<stgraber> it's using TryExec for some reason instead of Exec, so it's calling "/etc/X11/Xsession unity" directly
<didrocks> stgraber: ah, that explains then
<stgraber> didrocks: apparently we fixed that bug a few days ago in LTSP upstream ;)
<stgraber> didrocks: just need to sync the new bugfix version from Debian
<didrocks> stgraber: excellent! :)
<stgraber> jibel: bug 820417 is the upstream bug
<ubot2`> Launchpad bug 820417 in ltsp "LDM doesn't set ~/.dmrc correctly" [Low,Fix released] https://launchpad.net/bugs/820417
<stgraber> I'll send a sync request for ldm now but unless we need to rebuild Edubuntu and the alternates anyway, I don't think it's worth fixing for beta1 (release note should be fine)
<stgraber> sent the sync request. The only feature change I see in the upstream code is the change of background image, though that doesn't affect Ubuntu as we ship our own theme anyway
<jibel> stgraber, thanks
<pitti> Riddell: do you need the buildds for anything? if not, I'd like to upload the next 25 packages for md5sums (then 23 left to go)
 * pitti assumes not; these are all small builds anyway, and will readily yield for any main package
<GrueMaster> stgraber: Morning.  The oem-config issue was very consistent with v2.9.22, but not with v2.9.21.
<Riddell> ruby?  I hear that's big in Japan.
<ogra_> "big in japan" ... thats alphaville, no ?
<pitti> Ruby galore done
<Riddell> morning skaet
<skaet> Good afternoon Riddell - all looks nice and quiet on the pad
<skaet> any worries that haven't made it there yet?
<Riddell> yes I think it is, Daviey did a rebuild of -server today but he has his team of virtual machines testing it now
 * skaet working through backscrolls still...
<stgraber> GrueMaster: ok, I'm currently in a meeting but I have a VM setup to debug that one and try to find the right fix for it...
<Riddell> kubuntu is good from my tests
<skaet> :)
<stgraber> GrueMaster: are you selecting your keyboard layout using the mouse or keyboard? also are you using a specific variant of the layout?
<skaet> Riddell,  release notes updated for Kubuntu?
<infinity> stgraber: I think he was saying that it locks up when entering the keyboard config dialog (as in, he never even gets a chance to select)
<GrueMaster> Actually, I have been letting it go with default, just hitting enter to continue.
<ogra_> at least he gets that dialog
 * ogra_ has issues on ac100 with that 
<pitti> back in 20 mins
<GrueMaster> But with 2.9.22, it just sits with the mouse indicating it is busy.  It will not budge from there.
<Riddell> mvo: does do-release-upgrade need a sudo or not?
<ogra_> it surely did in the past
<mvo> Riddell: it will ask you for sudo when it needs it
<Riddell> mvo: what does it use to ask?
<mvo> Riddell: do-release-upgrade will use plain sudo
<mvo> Riddell: the other frontends should use there native tool, gksu/kdesu
<Riddell> right, so for beta I do want to advise using kdesudo since that's just a command line
<mvo> Riddell: I don't know much about the kde part of this, but for ubuntu we run it without and it will ask when it needs it
<Riddell> yeah but nicer not to make people have to do more command line stuff if possible, I'm not that elitest on my users :)
<stgraber> GrueMaster: hmm, well, the known issue with my change is that the dialog can be "insensitive" while waiting for debconf/console-setup and sometimes never unlock at all but I don't see anything in my change that'd prevent the dialog from showing up at all
<stgraber> GrueMaster: can you check /var/log/syslog and /var/log/installer/debug for traceback?
<GrueMaster> I have never been able to get decent debug info from oem-config (and the only thing in /var/log/installer/ is version).
<GrueMaster> And the dialog shows up, just never goes away.
<ogra_> isnt there another file where ubiquity-dm logs to ?
<stgraber> GrueMaster: hmm, ok...
<GrueMaster> It has been one of my greatest frustrations for several cycles.
<stgraber> skaet: do you think we should revert that workaround then? it's going to re-introduce bug 645449 but should fix GrueMaster's bug and bug 942560
<ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<stgraber> I'm working on a different and hopefully "proper" fix but I have no clue when I'll have something ready for upload
 * skaet reading
<GrueMaster> stgraber: Was bug 645499 even reproducible in recent releases?  Seems a bit old, especially for a fix mid-release week.
<ubot2`> Launchpad bug 645499 in nautilus "nautilus crashes when unmounting microSD card (dup-of: 630884)" [Medium,Invalid] https://launchpad.net/bugs/645499
<ubot2`> Launchpad bug 630884 in nautilus "nautilus crashed with SIGSEGV in g_closure_invoke()" [Critical,Fix released] https://launchpad.net/bugs/630884
<stgraber> I could probably keep the delays and drop the "locking the UI" part of the workaround, this should somewhat limit the number of occurences of bug 645449 and hopefully fix the regression
<ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
<stgraber> GrueMaster: yes, it's very easy to reproduce
<GrueMaster> oops. wrong bug.
<stgraber> GrueMaster: just keep the down arrow key pressed and see the dialog freeze
<GrueMaster> ok.
<skaet> stgraber,  is this only showing up on arm?
<stgraber> skaet: I didn't see GrueMaster's specific issue on anything else but I haven't tested oem-config myself, I can reproduce bug 942560 and its duplicates on x86 though
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<GrueMaster> stgraber: On a side note, I was able to get through IF I unplugged the network cable before booting.  Just tried that.  Seems odd.
<stgraber> GrueMaster: indeed seems really odd and should be unrelated ;) are you sure you're not getting stuck on the timezone dialog (that's just before the keyboard dialog)?
<stgraber> GrueMaster: the timezone dialog uses the network so that could explain it
<GrueMaster> No, it takes a little longer, then defaults to NYC.  I click on Los Angeles and can move on.
<skaet> stgraber,  am worrying a bit about whether jibel has bandwidth for retesting images if we respin at this point.   Is there a workaround for 942560?
<stgraber> skaet: the workaround is to use the mouse to first click the keyboard layout and then the keyboard variant, waiting for the UI to refresh between each action
<stgraber> trying to do things too quickly or clicking to many different entries in a row can cause the bug
<stgraber> *too many
<skaet> stgraber,  got cha.  :)  thanks.   if we have a workaround for it am leaning towards leaving things as is.
<GrueMaster> I think reverting might be the safer option at this point.  The bug that it fixed has been around for quite a while.
<skaet> GrueMaster,  if you feel that way - its good to know.  *sigh*
<stgraber> skaet: I'm doing an x86 OEM test install now
 * skaet waiting to see if she can get a response from jibel about the testing load,  since this is more than arm
<GrueMaster> The other option for me is releasing 20120228.2 images (prior to the fix).  They will be slightly out of sync, but that can be addressed between now and Beta 2.
<GrueMaster> And would require less retesting overall.
<GrueMaster> Besides, not all of the arm desktop images were respun for this fix.
<skaet> GrueMaster - if that works for you,  am fine with that option.
<skaet> do you want me to go into the tracker and change them to point to those images now?
 * skaet would prefer not to revert if we can avoid it at this point.
<GrueMaster> Sure.  I have already partially tested those images to figure out this issue.
<skaet> GrueMaster - going and changing now.
<GrueMaster> Please delete 20120228.3 from cdimage too if possible.  That directory isn't right anyways (4 out of 7 md5sums failed).
<GrueMaster> Oh, and Ubuntu Desktop armhf+mx5 needs to be added to the tracker.
<stgraber> skaet: OEM works here, though you have to select your keyboard variant on the first go as the dialog gets locked when you do...
<stgraber> now back to figuring out a real fix for that stuff...
<skaet> stgraber,  k,  release note time then.   thanks!
<stgraber> skaet: writting something now, will also add the LTSP issue jibel found earlier
<stgraber> highvoltage: can I let you do the Edubuntu section?
<skaet> Thanks stgraber.  :)
<stgraber> skaet: just thought of a workaround for the case where the dialog is locked, I added that too
<infinity> The livecd-rootfs that queuebot's about to warn about has a fix for ac100 images (and nothing else) that would be kinda nice, but obviously not critical, since it's a community image.
<skaet> infinity,  prefer not at this point.   in a couple of hours if no other respin triggers occur,  we can probably let it in and do a rebuild of it for tonight.
<ogra_> yeah, its not urgent
 * skaet wants to hear from jibel about the images and if there's any other criticals on the horizon.
<ogra_> and has an easy workaround
<skaet> thanks ogra_ ,  yeah then lets hold off on it until after beta 1.   Please document the workaround in the release notes.
<ogra_> will do
<ogra_> (not actually a workaround, there are kde bits ending up in the install ... you can just apt-get remove them
<ogra_> )
<infinity> skaet: Well, livecd-rootfs doesn't ship on any images, so there's no real harm in letting it in, pending a later respin.
<infinity> (But if there are no respins, no big deal either way)
<skaet> infinity,  thanks.
 * pitti uploads the remaining 17 rebuilds for broken md5sums, buildds are still bored
<jibel> skaet, it's too short to retest desktop images properly. But i'm trying to reproduce on x86 what GrueMaster's seeing so it can be documented
<jibel> skaet, major issues remaining with the live session and the installer are
<jibel> bug 940908
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<jibel> bug 939450
<ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
<jibel> and bug 942560
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<skaet> thanks jibel
<GrueMaster> skaet: I have tested the armhf+mx5 desktop image, but have no place to put results.  Can it get added to the tracker?
<ogra_> yes, please
<infinity> (pretty please)
<infinity> skaet: I've taken sign-off duties for mx5/ac100, you can yell at me if they don't get test results. :P
<pitti> skaet: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview -> the "section missing" is from your new parser? what is it looking out for?
<skaet> GrueMaster,  have cleaned up other images to .2 (please verify)
<skaet> pitti,  meant that the section wasn't in the weekly report
<GrueMaster> Yes, they are on .2 now, thanks.
<pitti> skaet: I guess I mis-named it then
<skaet> Release Notes section.  :)
<GrueMaster> Still need the mx5 image added.
<skaet> pitti, https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate
<skaet> GrueMaster,  yup.  Will add it after I get off my call.   its on the list. sorry to be slow.
 * skaet is fine if someone else on the release team adds it before I get to it.  ;)  hint, hint ^ infinity ;)
<infinity> Don't make me learn how to use the tracker!
<infinity> GrueMaster / skaet: That should do it.
<GrueMaster> I can live with it, but the download link is mia.
<infinity> It's MIA for omap4 too, which is what I copied. :P
<infinity> I can fix, though.
<GrueMaster> As I said, I can live with it (I know where the images are).
<infinity> GrueMaster: Download link fixed too.
<GrueMaster> k, thanks.
<pitti> skaet: I added the desktop bits to https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, but some bits (like the HUD description) will still be improved
<SpamapS> no more respins?
<Daviey> SpamapS: nein.
<Daviey> (correct)
<SpamapS> Cool.. just wrapping up RAID1 test again
<skaet> pitti,  thanks
<skaet> thanks infinity.  :)
<skaet> GrueMaster, 20120228.3 removed
<GrueMaster> skaet: Thanks.
<Riddell> skaet: I'm about done for the day, what's the plan for tomorrow?
<skaet> Riddell,  will see what emerges from rest of testing today.
<Riddell> skaet: ok but if it's all good when are we hoping to release and who cranks which handles?
<skaet> Riddell, will leave you summary of the bits from the checklist - marking the ones good to start.
<skaet> while I'm sleeping.  :)
<Riddell> skaet: and if all goes well aim for release my late afternoon your morning?
<skaet> Riddell,  yup.
<GrueMaster> Riddell: Did you ever get your panda running?  Also, have you asked anyone to step up and test kubuntu armhf?
<scott-work> i should be testing the remaining ubuntu studio test cases this afternoon (i.e. 64 bit) for beta1
<skaet> scott-work, yes please.
<skaet> scott-work - no respins planned at this point ( but waiting for all the test results to come in though)
<GrueMaster> Well, having seen no response to my question on Kubuntu armhf testing, I guess I can fire them off.  Fortunately, they only take a few minutes to smoke test.
<iulian> GHC has just landed in the unapproved queue. Does anyone fancy hitting the 'accept' button?
 * iulian giggles.
<skaet> looks like we're going to need a respin for lubuntu this evening to get the artwork usable for them.
<skaet> https://launchpad.net/bugs/938472
<ubot2`> Launchpad bug 938472 in lubuntu-artwork "dialogs are barely readable-- grey on black????" [Undecided,Confirmed]
<skaet> NCommander, Riddell, slangasek, ScottK, iulian ^ please let fix through the queue as soon as you see it if I'm not around.
<slangasek> ack
<GrueMaster> sigh.  Kubuntu Daily-preinstalled 20120228.1 MD5SUMS is wrong.
<GrueMaster> As are the daily-preinstalled/201228.2/MD5SUMS for Ubuntu Desktop.
<GrueMaster> As far as I can tell, NONE of the arm images match the md5sums from the same directory.
<GrueMaster> Kubuntu, Ubuntu Desktop, and Ubuntu server are all wrong.
<slangasek> infinity: ^^ can you have a look at what's going on with md5sums?
 * skaet curious why suddenly this might have changed.... werid. 
<slangasek> I'm not sure it's ever been working, GrueMaster brought it up last milestone as well
<slangasek> a fix was applied but perhaps it was incomplete
<GrueMaster> I should probably add this to my daily tests.  I don't check daily images normally.
<skaet> thanks slangasek.
<skaet> GrueMaster, yeah would have been good to know about this much earlier.  Was there a bug number?
<GrueMaster> No.  I only file bugs when I know what to file bugs for.  In this case, I wouldn't know what to file against.
<GrueMaster> Besides, I just picked it up.
<slangasek> the ubuntu-cdimage project
<GrueMaster> It's one of the last things I check before release.
<GrueMaster> slangasek: ok.
<skaet> thanks for checking it GrueMaster.   hopefully we'll sort it now.
 * skaet has updated pad with latest status she's aware of
 * skaet --> lunch (finally!)
<skaet> :)
<jibel> skaet, bug 940908 is more serious that it seems finally
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<jibel> not only keyboard but all boot parameters like oem-config are ignored with persistence enabled
<GrueMaster> Please do not respin arm images due to md5sums being broken.  That will pull in oem-config 2.9.22, which is broken.
<gilir> skaet, lubuntu-artwork uploded, sorry for the late request
<micahg> stgraber: queuebot was flooded out about 7 hours ago
 * micahg wonders if it should stay away so no one accepts the new ghc :)
<ajmitch> micahg: is ghc a bit of a 'rebuild-the-world' situation? :)
<micahg> yes, which I personally think is insane while the archive is frozen
<iulian> ajmitch: No, not really. :)
<ajmitch> iulian: I thought it was going to be quite a few rebuilds & possibly a few syncs as well
<Laney> the rebuilds won't be happening when the archive is frozen
<iulian> ajmitch: I wouldn't say "a few". :)
<slangasek> not the world, just the universe
<Laney> we did think of this.
<iulian> slangasek: Heh.
<ajmitch> Laney: oh I expected you'd think about it :)
<micahg> iulian: you make a whole bunch of things uninstallable with the first upload and the manual processing makes the whole thing tedious
<micahg> the archive should be unfrozen in ~24 hours at which point it's a lot easier to do this
<stgraber> micahg: apparently irclib doesn't respect the flood restrictions ;) I guess I'll have to implement it myself then (or use a more complete irc library)
<slangasek> lubuntu-artwork accepted
<micahg> stgraber: well, pitti flooded teh archive with ~25 uploads at once
<micahg> it was a very unusual case for a freeze I would think (but I haven't been keeping score)
<iulian> micahg: We won't do anything when the archive is frozen, like Laney said above. It'd be a mess!
<GrueMaster> There have been other updates that slipped in during image builds.  For example, libxml2.  I have different versions for omap & omap4 images.
<micahg> iulian: than why were you asking for ghc to be accepted?
<micahg> s/than/then/
<iulian> micahg: Having said that, it doesn't really matter whether ghc is accepted now or after.
<slangasek> GrueMaster: libxml2 was an opportunistic security upload, discussed on here yesterday
<micahg> iulian: sure it does, anything that depends on the virtual provides will be uninstallable
<iulian> Yes, we'd end up with loads of uninstallable packages but that's going to be fixed soon anyway.
<micahg> unless they got the domination scripts to factor that in as well
<micahg> iulian: but why do that when you can minimize the impact
<GrueMaster> Ah, well kubuntu omap4 got it, but not omap.  Not that I care, it was the only update for omap and largely doesn't affect many users for beta 1 (seeing as how I'm the only one testing them).  :)
<Laney> it takes hours to build on arm
<Laney> so should be accepted ~12 hours before the freeze ends
<micahg> Laney: with the pandas?
<GrueMaster> Which is why I panic at the mention of respins.  :P
<Laney> 12 hours is down from 2 days
<GrueMaster> Image builds on arm are serial.  None are posted to cdimage until all for that build are done.
<Riddell> GrueMaster: no I'm waiting on jason to tell me I can expense the necessary equipment to get the panda running
<GrueMaster> arm builds will see greater improvement once we start seeing real arm server hardware.
<GrueMaster> Riddell: Images have been tested, results posted.
<GrueMaster> And I emailed you on how I think we need to test going forward.
<Riddell> GrueMaster: yes, it's up to jason for now
<slangasek> GrueMaster: no, image builds on arm are parallel across two builders, and as of alpha-2 we're spitting out the images in sub-batches precisely so the testing isn't held up waiting for them all to finish
<GrueMaster> Ah, well that is an improvement then.  Didn't know that had been fixed, thanks.
<slangasek> that's why you were getting .1 on the tracker while still testing .0
<slangasek> an artifact of how the publishing happens when we split the batch
 * skaet catches up on backscroll...   
<skaet> jibel, slangasek - is there a known fix likely to land for 940908?
<skaet> gilir,  will start off the respins as soon as bits get published.
<skaet> GrueMaster - no arm respins... (if we do any)  "noted"  :)
<GrueMaster> Ok.  I just saw the note on the pad.
<slangasek> skaet: 940908> do you want a respin for that one if you can get it?  it seems it'd be fairly intrusive?
<slangasek> stgraber: ^^ 940908 is the one you're working on right now?
<skaet> slangasek, yeah don't want to unless it can't be release noted.   I think it can, but figured better check with the experts.  ;)
<skaet> s/can/can be release noted/
<slangasek> looks release-notable to me
<stgraber> bug 940908
<skaet> slangasek - ok,  that's what we'll do.
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<stgraber> slangasek: no, that's the next one on my list
<skaet> I'll start off the lubuntu rebuilds as soon as the artwork publishes, and get that up there.
<stgraber> slangasek: I'm on bug 942560
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<slangasek> stgraber: ack
<skaet> infinity,  will you be able to patch the ARM images MD5SUMs in the directory?
<jibel> skaet, I think it is release notable, the workaround for oem installation is to install from a media without persistence enabled
<jibel> for keyboard with persistence, setting the right layout in /etc/default/keyboard should work
<skaet> thanks jibel.
<jibel> that's the most visible side of this bug probably
<skaet> jibel,  given that lucid -> precise updates don't seem to be working in the smoke tests - I think we'd better be making that prominent in the release notes to avoid doing.   Am I being overly pessimistic?
#ubuntu-release 2012-03-01
<jibel> well, many early adopters upgrade and report minor failures, it's not that bad and the automated tests give a pessimistic view of the upgrade.
<jibel> I did a couple of manual upgrades too and they passed
<jibel> we know there are problems with libreoffice, iodbc, skype and some others but nothing major.
<jibel> I mean an upgrade that'd leave the system in an unusable state
<stgraber> jibel, skaet, slangasek: I have another fix for bug 942560 that seems to do the trick here, basically a small change in gtk_ui to try and force our code to better deal with the main loop and a few changes to ubi-console-setup to reduce the risk of races
<ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
<stgraber> jibel: I can give you a diff of the two files if you want to torture it some more
<skaet> jibel,  I'll put some caution words in then to that effect.   feel free to tweak it when you see it in the morning.
<stgraber> jibel: http://paste.ubuntu.com/862727/
<stgraber> ok, looks pretty solid here (tried a few layouts, switching by either clicking or scrolling through the list with keyboard)
<skaet> stgraber,  ok if it does the trick,  we may make this an "explicitly request respin for" rather than forcing a mass respin.
<stgraber> skaet: should I try and spend an hour on bug 940908 then before uploading a new ubiquity?
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<stgraber> skaet: so if we're lucky 940908 is easy to figure out and fix and we get both fixed at once
<stgraber> (won't commit to more than an hour though, it's already 7pm here ;))
<skaet> jibel - if we have the Ubuntu desktop images ready for you when you wake up - do we have time to get them tested.   Rest of prior results should be good.
<skaet> stgraber go ahead please.
<skaet> I'l stay up late and do the spins for Ubuntu - worst case we'll fall back to the current images.
<skaet> (except no arm respins - per GrueMaster's request.  ;) )
<GrueMaster> skaet: If there is a possibility of this fixing my oem-config issue, we can also respin arm, keeping the current images as a fall back.  Only problem is testing in a timely manner.  I was more concerned about respinning to fix the md5sums.
<skaet> gilir, Riddell, ScottL, superm1 ^ let me know if you want respins to pick up this late bug fix or not please.
<skaet> GrueMaster, ok.  will add that to the pad then.
<stgraber> infinity, slangasek: any of you two has a minute to look at ldm in unapproved?
<skaet> lubuntu alternate posted.
<skaet> GrueMaster, just desktop,  or server as well?
<GrueMaster> Are you reimaging x86 server as well?  If so, yes.
<GrueMaster> We should try to keep the images in sync.
<skaet> GrueMaster, not sure if will do x86 server or not yet - trying to get an opinion.   In either case,  will keep them in sync then.
<GrueMaster> Ok by me.  I'm all for keeping the images in sync and respinning when there are fixes.
<GrueMaster> Testing time is nominal.  It is mainly the download time that kills me (and waiting for images to respin).  :)
<skaet> GrueMaster, coolio.  :)  update the pad with the intentions after I hear back from someone on the server team.
<stgraber> ok, I think I found the source of bug 940908
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<GrueMaster> btw:  There should be an alsa-lib update waiting in the wings with a fix for pandaES support (doesn't affect any other platforms).  If that were to slip through, I'd be inclined to buy someone a beer at UDS.
<stgraber> the overlay is broken in the initrd, it's using an empty dir as the lowerdir instead of /cow
<skaet> stgraber,  :)
<skaet> NCommander, could you review ldm from the unapproved queue, and check out the alsa-lib fix?
<NCommander> skaet: I'm not an archive admin
<NCommander> I can review the fix, but can't approve
<skaet> NCommander, if you can review - I'll escort them through
<NCommander> skaet: will do
 * NCommander however notes teh LP webUI is degraded more than itwas which is $#@# irritating
<skaet> Thanks NCommander!  :)
<NCommander> I'm not seeing alsa-libs in unapproved
<NCommander> ^- skaet
<skaet> GrueMaster, ^ alsa-libs - where in the wings is it residing?
<GrueMaster> I'm checking the bzr tree to see if it was uploaded.
 * GrueMaster could have sworn ogra had posted it last week.
<GrueMaster> It's in the lp:ubuntu/alsa-lib tree.  1.0.25-1ubuntu6
<GrueMaster> Doh!  He updated the changelog, but forgot the actual config files.
<NCommander> awesome!
 * GrueMaster swears loud obscenities to no one in particular.
<GrueMaster> I'll post an update and a merge request for post-beta.
<infinity> Gets weirder than that.  The source in the archive is supposedly 1.0.25-1ubuntu6, but the changelog stops at 1.0.25-1ubuntu4
<NCommander> skaet: ldm looks saneon the whole though there's a large changefor X50-dmrc-processing I'mstill reviewing
 * infinity wonders how that's even possible.
<skaet> stgraber, ^
<infinity> NCommander: The dmrc bits are the bits they need.
<NCommander> infinity: did someone actually upload ubuntu5? (branch importer might have exploded silently)
<infinity> NCommander: I'm not looking at the udd branch, I'm looking at the archive itself.
<GrueMaster> Somewhere in the distant area of Oregon, a head banging on a desk can be heard.
<NCommander> infinity: yeah, I'm just getting a grasp of what the old code did and how the new code changed
<infinity> NCommander: And confused as heck that source labeled ubuntu6 has a changelog that says ubuntu4.
<infinity> Oh, nevermind.
<infinity> I'm just asleep.
<GrueMaster> Whoa.  The bzr tree has my patch, but it isn't in the source I just branched.  WTF???
<infinity> GrueMaster: I see the patch here.
<NCommander> Launchpad has lost its mine
<NCommander> *mind
<infinity> GrueMaster: But, why was it a patch at all?
 * skaet wonders if infinity can clean up the MD5SUMs before she kicks off the arm rebuilds for the ubiquity fix.
<infinity> GrueMaster: ie: You added it to the base alsa sources, not to the debian/ucm directory.
<GrueMaster> Oh.  I see what happened.  The patch dumped it in alsa-lib/ucm instead of alsa-lib/debian/ucm.
<infinity> skaet: If you're doing ARM rebuilds, that'll fix the md5s.
<infinity> GrueMaster: It shouldn't have been a patch at all.
<GrueMaster> No, I made it properly.  Note the "fixed the patch" note in the commit.
<GrueMaster> I sent a bzr diff to ogra.
<GrueMaster> That's why the patch.
<infinity> Which didn't have anything in debian/patches?  Kay.
<infinity> Well, easy enough to clean this up.
<skaet> infinity,  what turned out to be the problem with them?
 * skaet curious
<infinity> skaet: No idea.  Haven't had a chance to look (it's been a weird afternoon).
<infinity> skaet: But spinning new images will generate new sums.
<infinity> skaet: In theory.  Unless something's really really broken.
<skaet> yeah, but will they hit same problem as before.
<NCommander> skaet: ldm looks sane. Can't test it locally however
<infinity> skaet: I doubt it.  I suspect whatever happened before was a product of some manual fiddling and oopsery.
 * skaet figures there's something weird going on (maybe not taking the md5sum on the binary? - missing option)
<skaet> ok
<NCommander> (new code is quite a bit cleaner than what it replaced)
<NCommander> seems everything is falling aparttoday
<skaet> thanks NCommander
<infinity> GrueMaster: Is there a bug number for the PandaES oops?
<infinity> GrueMaster: If not, I'll upload right now. :)
<GrueMaster> I'd have to look.  It was marked "Fix Released".  I have bug 925069 in my notes, but that may have been the kernel side.
<ubot2`> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Confirmed] https://launchpad.net/bugs/925069
<infinity> Yeah, no bug is fine with me.
<infinity> Uploaded.
<infinity> Did we want that fixed alsa-lib before people start respinning ARM images?
<infinity> skaet: We can spin the mx5 and ac100 set first, while we wait on the new alsa-lib for omap4. ;)
<GrueMaster> I would like it, but it only affects one platform (I have had a lot of people ask about it).
<GrueMaster> That plan works for me.
 * infinity notes that would require someone other than me accepting it.
<skaet> NCommander, ^ if you've finished with ldm,  want to have a look?
 * NCommander gets back on the gerbil wheel
<skaet> NCommander,  ok to pass through ldm?
<infinity> Was my livecd-rootfs ever approved?
<infinity> My mailbox says no.
 * infinity looks at the queue.
<NCommander> skaet: yeah, it looks fine
 * skaet wasn't sure if you'd finished reviewing
<skaet> thanks NCommander
<skaet> infinity, nope
<infinity> skaet: Dang.  This is why I wanted to accept it earlier, so it'd be ready if there was an ARM respin. :P
<infinity> If we accept both, I can wait and crank the ARM handle in an hour or two.
<infinity> No need to hold others up.
<NCommander> skaet: testbuilding alsa-libs to make sure the configs actually get installed
<skaet> NCommander,  thanks.   :)
<NCommander> GrueMaster: is the armada up, or should I punt onto the porter box?
<infinity> NCommander: The .install file just install debian/ucm wholesale.
<infinity> NCommander: So, if it doesn't work, you'll need to fix debhelper. ;)
<stgraber> skaet: should I upload ubiquity? the fix for the other bug will most likely be in casper rather than ubiquity (still fighting with that one :))
<skaet> stgraber,  yes, go ahead and upload
 * skaet would like to get those rebuilds started
<skaet> thanks.
<infinity> Oh, if there's a ubiquity upload anyway, then we're waiting a bit.
 * skaet nods
<infinity> So, someone approve livecd-rootfs for me? ;)
<infinity> (Only affects ac100)
<skaet> infinity - promise.... only ac100
<skaet> ?
 * skaet goes to look at it.
<infinity> Cross my heart.
 * NCommander wonders when infinity got a heart ...
<NCommander> :-)
<infinity> It's there, it's just black as the night, and shrivelled as a prune.
<skaet> infinity,  can you please review the ubiquity when stgraber gets it uploaded.
<infinity> skaet: Yup.
<skaet> coolio.  :)  thanks!
<NCommander> skaet: alsa-libs ACK (thoughits a bit weird that those files also getinstalled on x86 ..)
<skaet> NCommander,  hmm...  a bit reluctant to pick it up then if it could be hitting x86 as well.
<infinity> NCommander: Quite.  Actually, I suppose I could fix that next time around (but that's how it's been done since I first poked it)
<infinity> skaet: No, it doesn't "affect" x86, it's just files that lay dormant.
<infinity> skaet: (They've been there for 3 releases now)
<skaet> infinity,  ok,  you buy beer if we regress.
<infinity> I'll take that bet. :P
 * infinity notes that he could, in later uploads, just mv libasound2.install libasound2.install.armhf && ln -s libasound2.install.armhf libasound2.install.armel
<infinity> But that's actually a much bigger change (from a "I could mess it up" perspective) than the current one.
<infinity> Err, obviously, since I already did it wrong in pseudocode. ;)
<infinity> But yeah.
<infinity> We can copy the ucm bits out later.
<infinity> Not now.
<skaet> infinity,  +1
<GrueMaster> Personally, I vote for moving the ucm bits to a separate file.  Upstream already has a separate git repo for alsa-ucm-configs (currently empty).
<infinity> GrueMaster: You mean a separate package?
<GrueMaster> Yes.
<infinity> Extra overhead for no real gain right now.
<GrueMaster> Since it requires alsa-utils to actually use the ucm configs.
<infinity> But if there were lots of them, yeah, it might make sense to split them out.
<GrueMaster> Yes, not today.
<infinity> Have we at all investigated why OMAP4 is the only platform that *needs* a ucm config to work out of the box?
<infinity> Is there something the kernel could be doing (and does for other drivers) that it's not doing for omap?
<GrueMaster> Actually, ucm is designed to make it easier for different platforms to have one driver and different configs for each system.
<GrueMaster> Think HDA.
<infinity> Sure, but that's not what we're doing with it.
<GrueMaster> Device tree may eventually replace UCM.
<GrueMaster> Yes, we are.  The current omap4 kernel will boot both Panda and Blaze, which are different at the audio port level, but use the same codec.
<GrueMaster> (hence the SP4430 ucm configs).
<GrueMaster> At any rate, different discussion for a different channel.
<skaet> ScottK,  apachelogger - around?
<infinity> Man, that FTBFS freaks me out every time.
 * infinity kidnaps roseapple.
<skaet> thanks stgraber
<skaet> stgraber, could you check http://pad.ubuntu.com/ubuntu-release and make sure I've got it right.   Don't want to respin the distros unless they "ack" they want a new image and are able to test in time.
 * skaet wondering about wubi....
 * infinity will review that ubiquity after a quick drink run.
<stgraber> skaet: looks good based on what I remember of the backlog
<skaet> thanks stgraber,  have a good evening.
<stgraber> skaet: still poking at casper, I have a pretty good idea of where something is going wrong (the bit that copies the debconf database from the temporary location to /var/cache/debconf)
<skaet> :)
<stgraber> I managed to get my netbook to do the right thing a few minutes ago by manually poking the initrd
<stgraber> will now add some more debug in there and hopefully find a fix :)
<skaet> stgraber,  ;0
<skaet> :) even
<highvoltage> stgraber: the notes in the technical overview, do they just apply to the beta or the whole 12.04 cycle so far?
<infinity> skaet: stgraber's upload looks like it'll do what it says in the changelog, anyway.  Short of testing it, I can't say for sure if it works better, but he claims it does. ;)
<skaet> thanks infinity, wave it through then.
 * infinity accepts with the "It can't possibly be more broken" theory.
<skaet> infinity, can you please check I've got the respins marked correctly on the pad when you've finished.
<stgraber> it does here and ubiquity still passes the tests, though I probably should find myself a test system that doesn't involve an i7, 8GB of RAM and an SSD
<infinity> stgraber: A Panda?
<stgraber> highvoltage: it always looked to me like we were only describing the current milestone except for the final release (obviously) but can still hilight big changes that were done earlier
 * skaet nods
<stgraber> infinity: still waiting on the 3D drivers before reinstalling mine on 12.04
<stgraber> infinity: I'm using it as a media center, so having driver is kind of important :)
<infinity> skaet: ubuntu alternate shouldn't care about ubiquity.
<infinity> stgraber: Picky, picky. ;)
<skaet> infinity,  yup.  thanks!  :)
<stgraber> infinity: doesn't alternate include oem-config?
<highvoltage> ok, just wanted to double-check (I knw I asked the last two times too :) )
<infinity> stgraber: It ships, but doesn't use it by default.  I suppose there may be people testing that path, though, sure.
 * infinity takes back the objection.
<infinity> It's not like spinning alternates takes long.
<stgraber> infinity: yeah, I guess you'd need to do an OEM install from alternate, then you'll get the keyboard dialog at first "end user" boot
 * infinity nods.
 * skaet notices pool/main/u/ubiquity/oem-config-gtk_2.9.21_all.deb in the alternate.
<infinity> skaet: Yeah, like I said, it ships it, but it's not used during install.
<infinity> skaet: But it can be used optionally for OEM installs, if people test/use that with Betas...
<skaet> infinity,  gotcha.  thanks.
 * infinity suspects that 99% of the oem-config testing we get on Beta releases is on ARM images.
 * GrueMaster can attest to that.
<stgraber> hmm, why does adding some debugging always fixes the bugs ... that's getting annoying ;)
<infinity> stgraber: Sounds like the definition of a timing/race issue.
<GrueMaster> stgraber: Starting to enjoy what I experience every time I have an issue with oem-config?
 * infinity has seen code with random delay loops and printfs left in specifically to mask such bugs...
<GrueMaster> I've spent a week just trying to figure out why the colors change in oem-config-debconf.  Bug 747229.
<ubot2`> Launchpad bug 747229 in ubiquity "weird color change during oem-config debconf package removal step in serial installs" [Medium,Confirmed] https://launchpad.net/bugs/747229
<stgraber> infinity: yeah, it could be that for some reason debconf doesn't want to die quickly enough, I'll try again without the debugging to make sure it breaks, then add an explicit kill + wait and see if that works
<stgraber> infinity: the bug apparently is that debconf-copydb fails and so never actually copies the debconf changes made by casper. My guess as to why it only fails with persistent storage is timing, tmpfs is obviously much faster than ext3 over usb.
<infinity> stgraber: Is it failing to get a lock because another debconf is still running, then?
<infinity> stgraber: Shouldn't need an explicit kill in that case, you should just be able to wait on the lock?
<stgraber> infinity: csaper closes all the debconf fds so debconf should die by itself so the kill shouldn't be necessary indeed
<infinity> stgraber: Right, so just waiting on the actual lock to free up would be enough.
<stgraber> skaet: ok, casper looks fixed here!
<stgraber> skaet: (bug 940908 that's)
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
<skaet> stgraber,  :)  excellent.
<stgraber> infinity: http://paste.ubuntu.com/862851/ that looks good to you?
<stgraber> infinity: we don't seem to have flock in the initrd, so waiting for debconf-communicate to exit is the easiest way to make sure it's ready
 * stgraber likes bug that only take a few hours to fix ;)
<infinity> stgraber: Sure, I was going to emulate flock/lockfile by just looping on a [ -f /path ], but waiting on the PID works too.  Assuming it does. ;)
<stgraber> infinity: debconf seems to use flock() on its database files and not create separate lock files (or I'm blind and couldn't find it in lsof)
<stgraber> ok, uploading casper now
<infinity> Oh, perhaps, yeah.
 * infinity thought there was a lockfile, but maybe I'm confusing debconf and dpkg.
<stgraber> dpkg uses a separate lock file
<skaet> infinity, can you do the honors on the unapproved queue for this one when it lands.
<skaet> ?
<infinity> skaet: *nod*
<skaet> thanks
 * micahg can sync openscenegraph if you want to give the buildds something to do
<infinity> Was anyone complaining about them being bored? :P
<micahg> they feel empty :D
 * infinity taps his foot, waiting for casper.
<skaet> micahg, waiting for casper to build so can kick off a set of iso rebuilds... no contention please. ;)
<micahg> skaet: heh, it's not a rush thing, there's a reason I didn't upload it in the first place ;)
<skaet> :)
<ScottK> skaet: Around (probably just briefly)
<skaet> ScottK,  there are two fixes for ubiquity/casper,  we'll be respining the ubuntu images for.   Do you want a set of kubuntu ones spun up,  or ok to go with what you have for this release?
<skaet> see pad
 * ScottK will look
<stgraber> ubiquity shouldn't affect kubuntu, casper should though
<infinity> kubuntu users don't have keyboards?
<infinity> Or was that only in the gtk frontend?
 * infinity admits to not having paid attention to filenames.
<ScottK> skaet: Based on that, I don't think Kubuntu should be respun.
<ScottK> Riddell: ^^^^
<ScottK> We've got a fair amount of ISO testing done and I don't think we ought to invalidate it for those.
<skaet> ScottK,  thanks!   will leave it alone then.
<ScottK> (and like infinity, I think at least one of them won't affect Kubuntu_
<ScottK> _/)
<stgraber> infinity: first change was for gtk_ui.py and second change was for PageGTK in ubi-console-setup
<infinity> stgraber: Check.
<ScottK> OK, definitely no respin for those.
<micahg> so any GTK based installer would be affected then?
<stgraber> yes
<infinity> Yeah.
 * micahg is thinking about xubuntu, but we're already lacking testers this cycle as charlie-tca is unavaiable
<micahg> s/cycle/milestone
<stgraber> skaet: Edubuntu's technical overview is ready, thanks to highvoltage for the update
<skaet> Thanks highvoltage!  :)   (and thanks stgraber :) )
<stgraber> skaet: I'll test Edubuntu first thing tomorrow morning, so should have test results by 11am my time (10am yours), does that work for you?
<skaet> stgraber,  that works.
 * skaet suspects she'll still be chasing updates from teams then :P
<skaet> Thanks for all your help tonight stgraber,  sleep well.
<stgraber> oh, I think I'll still be around for a few hours, I need to move all the weblive VMs to a new server as the old one (old hardware) expires tomorrow (was hoping to have 12.04 working in weblive by then but that didn't happen)...
 * skaet drumming fingers waiting on the publisher for ubiquity and casper to show up...
<ScottL> are we having trouble with ubiquity on 64 bit?  i can't get the ubuntu studio 64 bit image to copy the files and finish the install
<ScottL> micahg, i can't help test xubuntu if you will tell me which images you need help with
<ScottL> errr
<ScottL> i CAN help test....
<stgraber> ScottL: nope, haven't seen anything like that, can you check dmesg for potential input/output/squashfs/overlayfs errors?
<skaet> NCommander or infinity,  could one of you review/adjust the pre-publishing scripts to make sure they're picking up the right armhf images and the images are going to the places indicated by the manifest?
<NCommander> I'dprefer if infinity did it; as a rule I don't usually publish images
<NCommander> if he's already EOD'ed, I'll look
<skaet> infinity, ^ still around?
<ScottL> stgraber, how do i check dmesg?  (sorry for noob question)
<stgraber> ScottL: just call "dmesg" in a shell
<infinity> skaet: Vaguely.
<scott-upstairs> stgraber, i ran 'dmesg' and got a bunch of text but at the bottom had 'zlib-inflate error; data probably corrupt'
<skaet> infinity, can you take a pass at pre-publish image to check that the right armhf/armel ones are listed...
<skaet> s/listed/going to the right spots/
<infinity> Sure.  Remind me which command you're running? :P
<scott-upstairs> stgraber, squashfs_read_data failed to read block
<skaet> ./publish-image-set.py --prepublish
<infinity> It grew a dependency on a config file since last time I used it.  Fun.
<scott-upstairs> stgraber, nevermind, the md5sum was off for that image, reruning zsync
<stgraber> scott-upstairs: how much ram did you give to that VM (or physical system)?
<infinity> stgraber: What goes in ~/.isotracker.conf ?
<stgraber> scott-upstairs: oh right, corrupted image would do that too ;)
<scott-upstairs> stgraber, it's a physical system, i tend to prefer testing on iron even though i know i'll need to replace hard drive eventually
<infinity> stgraber: Ahh, found the documentation in comments.
<stgraber> infinity: it's an ini file with a single "general" section and url/username/password/default_milestone values
<stgraber> infinity: if you want to use the ubuntu-cdimage account, the easiest is to get the file from nusakan
<infinity> stgraber: Isn't default milestone tracked on the tracker already?
<stgraber> nope, since the upgrade to the new tracker, we can have as many active milestone as we want so we can for example test a point release at the same time as a development release milestone
<infinity> stgraber: Fair enough.  Just means that potential config skew between two people could mean that skaet's request for me to "check for sane output" doesn't mean anything, cause our output could differ. :P
 * infinity grabs the config from nusakan for now.
<infinity> skaet: Looks like it needs to learn about kubuntu-active.  Will fix.
<skaet> thanks infinity
<ScottK> Thanks.
<infinity> Actually, why are we publishing active at all?
<infinity> It's brand new and, I assume, not really well-tested...?
<skaet> infinity,  will let that be Riddell's decision in the morning.
<skaet> ok,  looks like ubiquity and casper have both published, kicking the builds off now.
<pitti> good morning
<skaet> good morning pitti
<skaet> we've got some respins in progress right now
<pitti> urgh
<pitti> skaet: I was about to check for pre-publishing
<skaet> stgraber fixed some of the bugs that jibel was worried about.
<pitti> skaet: so that smells like a delay?
<skaet> pitti,  if you could that would be good.  infinity's been looking at the pre-publishing scripts and adjusting for the manifest changes.
<pitti> skaet: no point if we are going to respin
<pitti> skaet: a new ubiquity will affect desktops, DVDs, and all flavours
<skaet> pitti,  kubuntu explicitly doesn't want it.
<pitti> skaet: I could start pre-publishing kubuntu
<skaet> Edubuntu's getting it.
<skaet> others probably don't have the bandwidth
<skaet> to take it at this point.
<pitti> skaet: bug 940908 isn't marked as fixed, and not mentioned in the changelog?
<ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
 * GrueMaster is still here, waiting the good wait....
<pitti> but I don't consider it a release critical bug anyway
<skaet> GrueMaster,  the've started....
<GrueMaster> :)
<pitti> ok, seems desktops and DVDs are building
<pitti> oh, was wrong package, fixing
<pitti> great work, stgraber
<skaet> pitti,  I'll take a pass at updating the pad shortly,  but it shows the bits in progress right now.
<pitti> skaet: do you start new ARM images, too?
<skaet> yes,  started them off as well.
<pitti> ah, I see them
<skaet> date && echo ubuntu preinstalled armhf && ARCHES="armhf+omap4 armhf+omap" buildlive ubuntu daily-preinstalled && (ARCHES="armhf+omap4 armhf+omap" for-project ubuntu cron.daily-preinstalled &) && date && echo ubuntu preinstalled mx5/ac100 && ARCHES="armhf+ac100 armhf+mx5" buildlive ubuntu daily-preinstalled && (ARCHES="armhf+ac100 armhf+mx5" for-project ubuntu cron.daily-preinstalled &) && date
<skaet> Thu Mar  1 04:24:35 UTC 2012
<skaet> ubuntu preinstalled armhf
<skaet> celbalrai.buildd starting at Thu Mar  1 04:24:35 UTC 2012
<skaet> celbalrai.buildd starting at Thu Mar  1 04:24:35 UTC 2012
<skaet> I'm grabbing some measurements with them, but that's the order/sequence they should emerge in.
<pitti> $ ./publish-image-set.py --prepublish
<pitti> KeyError: 'No default milestone selected'
<pitti> stgraber: ^ you don't happen to be online still, are you?
<skaet> stgraber, highvoltage - edubuntu dvd rebuild has started off..
<pitti> stgraber: ah, nevermind, got it
<GrueMaster> one of these days, I'm going to want to test image building here on my arm server platform.  It would be a good benchmark for future planning.
<pitti> skaet: so right now publish-image-set will put kubuntu on releases.u.c. -- so this should be switched to cdimage?
<skaet> pitti,  yes, thats what was said in https://wiki.ubuntu.com/RecognizedDerivatives
 * NCommander goes and EODs
<stgraber> pitti: hehe, yeah, need to keep ~/isotracker.conf up to date :)
<stgraber> With these rebuilds we can probably drop quite a few existing release notes, I'll have a look tomorrow morning if nobody cleans them up before.
<pitti> stgraber: thanks for the fixes!
<pitti> Riddell: hm, do you know the right incantation for publish-release for active? I tried a few dry-runs, but perhaps cdimage needs to be taught about the new "active" type?
<pitti> skaet: updated publish-image-set for kubuntu -> cdimage
<pitti> skaet: pre-publishing server now
<skaet> thanks pitti
<pitti> skaet: server wasn't tested that well yet, but we can still reupload a new version if necessary (rsync will be fast)
<pitti> skaet: I'll pre-publish desktop/alternate after jenkins gets the auto-test results and we did one manual smoke test, ok?
<skaet> pitti,  sounds good.  thanks.
 * skaet would like to know smokes are reasonable.
<pitti> hm, manifest and manifest.beta look really strange
<pitti> I'll set up .manifest as per https://wiki.ubuntu.com/BetaProcess now
<GrueMaster> Too bad we couldn't get the respins in earlier.  How often do we get to release and image created on 0229?
<pitti> ah, can only do this after prepublishing everything, nevermind
<pitti> GrueMaster: we don't usually respin on release day
<GrueMaster> Maybe not LTS, but I have seen plenty of last minute respins since Jaunty.
<skaet> GrueMaster, ubuntu server will have a 0229 image unless they flag issues.  ;)
<GrueMaster> YEA!
<pitti> skaet: jenkins has the auto-tests now, looking good
<skaet> :)
<skaet> GrueMaster,  I'm estimating that first pair of arm images should pop out of builder in about 45-50 minutes,  FYI.
<GrueMaster> Cool.
 * GrueMaster waits patiently.
 * skaet starting to fade... time for zzz
<skaet> catch you on the flip side pitti,  have a good day
<pitti> skaet: sleep well!
<skaet> thanks
 * GrueMaster sees images, starts downloads.
<GrueMaster> Something is still not right.  omap & omap4 images are new, but ac100 and mx5 are old.  Also, still seeing an armel+ac100 image from 20120225.
<GrueMaster> pitti: Can you check these?  I would assume the ac100 & mx5 images are still building?
<pitti> yes, still building
<GrueMaster> omap4 image is good to go, just finishing install of omap image.
 * GrueMaster has left the building.  Back in 7h.
<GrueMaster> omap testing is done.
<pitti> GrueMaster: awesome, thanks; good night!
<pitti> I'm currently doing i386 and amd64 smoketests, looking good so far
<jibel> good
<jibel> morning
<infinity> pitti: Just got in from a late night.  I understand you were working on publishing bits?  If kubuntu-active still doesn't work right in the morning, I'll have a look at why.
<infinity> (I'd do it now, but I suspect I shouldn't drink and commit)
<pitti> infinity: yes, publish-release is updated for kubuntu->cdimage and parsing kubuntu active (but  not generating publish-release for that yet, as I haven't found out how)
<infinity> pitti: Kay, I suspect I know how, so if you don't find the time to poke it while I'm asleep, I'll get on it first thing in the morning.
 * jibel finished syncing and starts testing
<pitti> bonjour jibel
<pitti> jibel: I already did some i386/amd64, updating iso tracker now
<jibel> morgen pitti
<pitti> testing OEM/amd64 ATM
<jibel> pitti, on bare-metal with persistence on the boot media ?
<pitti> my i386 tests are bare-metal, but without persistence
<pitti> my amd64 tests are KVM right now
<pitti> I'm going to reinstall my workstation
<pitti> but my netbook is i386 only
<pitti> and I need my worstation still
<pitti> (and I wanted the first round with my main desktop still working)
<jibel> k, i'm doing amd46 on hw
<Riddell> morning
<Riddell> late night was it?
<pitti> hey Riddell
<pitti> GrueMaster: ac100/mx5 on tracker now, FYI
<pitti> jibel: added my test results
<Riddell> so new ubuntu everything to be tested?
<Riddell> kubuntu not being respun?
<pitti> jibel, Riddell: jenkins autotests were okay, and my i386/amd64 tests convince me enough that these are not completely broken
<pitti> Riddell: skaet said that she discussed that and Kubuntu didn't want a respin for the casper fix
<pitti> presumably the keyboard bug didn't apply to the KDE variant
<pitti> so I'd pre-publish them now (or let Riddell do it if he wants to), so that they have time to mirror
<pitti> I haven't tested alternates yet
<Riddell> pitti: do you know if the other flavours need respinning/testing?
<pitti> presumably they were respun for the keyboard fix in OEM
<pitti> Riddell: they don't
<Riddell> I see edubuntu is marked for it in the pad?
<pitti> Riddell: hang on, Edubuntu does
<pitti> it's rebuilt and on the tracker
<pitti> I updated the pad
<pitti> all rebuilds are done
<Riddell> lubuntu also rebuilt I see
<pitti> Riddell: do you want to pre-publish ubuntu desktops, or want me to?
<Riddell> mythbuntu, ubuntu studio and xubuntu not needing it
<Riddell> pitti: I think I'd be interested to relearn how
<pitti> Riddell: so first, please bzr update your ubuntu-archive-tools checkout
<jibel> Riddell, lubuntu rebuilt for a graphical issue but doesn't include casper and ubiquity fixes AFAIK
<pitti> Riddell: it's "release minus 1 day" step 2 on https://wiki.ubuntu.com/BetaProcess
<pitti> Riddell: note that I already prepublished server, so only pick out the desktop for now
<pitti> Riddell: (alternates should get a manual smoketest first)
<Riddell> Missing configuration file at: /home/jr/.isotracker.conf
<Riddell> ah needs created manually that file
<Riddell> pitti: I'll grab a quick breakfast and come back to this
<jibel> pitti, Riddell I think lubuntu must be respun too. there was a message about broken keyboard layout screen on their ML + bug 943837
<ubot2`> Launchpad bug 943837 in ubiquity "Precise Lubuntu live installer freezes at Keyboard layout" [Undecided,New] https://launchpad.net/bugs/943837
<Riddell> jibel: it is respun, go and nudge the lubuntu testers
<jibel> Riddell, 20120301 includes Package: ubiquity 2.9.22 and the fix is in .23
<pitti> respinning then
<pitti> we can still release lubuntu 20120301 if the respin doesn't get tested or is broken
<pitti> as the current image is 4/4 passed
<pitti> lubuntu running
<pitti> pad updated
<Riddell> pitti, stgraber: ok what's the secret to this isotracker.py module in ubuntu-archive-tools ?
<Riddell> I have ~/.isotracker_cookie and it doesn't seem to do anything
<Riddell> and it wants ~/.isotracker.conf with a url, user and password and I've no idea what those would be
<pitti> Riddell: sorry, DSL reconnect
<pitti> Riddell: I have ~/.isotracker.conf, copied from nusakan
<pitti> Riddell: in cdimage's home dir
<Riddell> pitti: that's better, thanks
<Riddell> pitti: do I have to do this stage?  ## make backup:
<pitti> Riddell: no, I already ran this
<pitti> Riddell: i. e. www.prev is right before I pre-published server
<pitti> Riddell: you just need the publish-release line for desktop
<Riddell> pitti: ok so I'll publish the amd64 i386 daily and daily-live into for ubuntu into poolonly
<pitti> Riddell: about daily: we might still wait before we get at least one or two manual test results, but I think they are okay
<pitti> jenkins autotests are happy with them, and the only thing that changed there is OEM mode which is the same as on live
<pitti> still need manual testing, of course, but the chances are high that they are ok
<pitti> Riddell: so yes, please pre-publish them, and backup/trim .manifest
<pitti> Riddell: if we need to respin alternate, rsyncing a new image will be much faster for mirrors anyway
<Riddell> yeah I know, I've got my whip ready for use on the ubuntu desktop team :)
<Riddell> pitti: hmm I should end up with stuff in ~cdimage/www/simple/precise right?
<pitti> Riddell: no html files, that's just pre-publishing
 * micahg wonders why both the archive admin page and queuebot don't show gdebi as in lubuntu
<micahg> ah, not in a packageset, but is seeded :)
<micahg> stgraber: enhancement idea ^^
<micahg> although this use case should be fixed right after beta 1
<Daviey> Riddell: if you need to re-pre-publish, make sure the checksums match, as they do not get re-generated for a replaced file, only a new filename.
<jibel> I tested destkop, dvd and alternate with english and non-english layout in oem and non-oem mode and they look good
<pitti> jibel: \o/
<pitti> ^ will accept, it drops the libreoffice-reportbuilder dependency which is NBS
<pitti> (and not seeded anywhere)
<Riddell> pitti: more md5sum rebuilds ^^ ?
<pitti> wasn't me this time
<pitti> the remaining ~20 ones are seeded
<pitti> I have them prepared, but won't upload until after freeze
<debfx> pitti: thanks for uploading those rebuilds :)
<Riddell> spooky
<debfx> just out of curiosity, do we have a script to prepare package rebuilds (like backportpackage)?
 * Riddell would just do it with bash for loops
<debfx> right, but putting the stuff that happens inside the loop into ubuntu-dev-tools would be a good idea
<stgraber> micahg: yeah, it's out of sync because cjwatson's magic screen doesn't seem to have run in a while, usually the seed => packageset relationship is pretty reliable
<stgraber> micahg: though tumbleweed already suggested using seeded-in-ubuntu instead which would avoid the problem entirely
<ScottK> pitti: Those weren't md5sum rebuilds, just a bunch of universe packages that were sponsored for sync.
<ScottK> Riddell: ^^^
<Riddell> okay dokay
<skaet> good morning pitti, Riddell, jibel
<Riddell> morning
<Riddell> up early skaet ?
<stgraber> good morning skaet
<skaet> Riddell,  yup,  lots to do this morning.  :)    coffee mug in hand.
<skaet> good morning stgraber,  how look those edubuntu respins?
 * skaet looks at TechnicalOverview *sighs*  still pieces missing. :P
<tumbleweed> stgraber: not that seeded-in-ubuntu dosen't have its own bugs :) (e.g. it can't do source->binary lookups when the last build failed)
 * Riddell fears he might be one of those missing pieces
<stgraber> skaet: based on the testing it got overnight, it looks good, I'll be running tests here in a few minutes to confirm
<skaet> stgraber,  :)
 * skaet thinks Riddell is right to fear.... *nudge*
<stgraber> skaet: if you're reviwing the release notes, the installer keyboard layout dialog freezing, the persistent USB not working for oem/language and the LTSP bug should all have been fixed now and can be dropped from the list
<skaet> Daviey,  can you please get the server updates into https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<jibel> stgraber, I didn't test a physical install of edubuntu but live ltsp is ok
<Riddell> Mythbuntu a bit low on the testing, who do I ping for that?
<skaet> stgraber, :)  and happy I am to see them going
<stgraber> jibel: I rarely test a physical install during milestone testing as it simply takes too long :) but I did a test run of the previous image on physical hardware (to test wubi) and it worked fine so that'll be good enough for beta1
<skaet> Riddell,  superm1
<jibel> skaet, for ubuntu, from our testing, everything's ok excepted chinese input
<jibel> skaet, untested, migration assistant and screen saver install
<jibel> *screen reader
<jibel> and iscsi on server
<jibel> Daviey, ^ anyone for iscsi
<superm1> Riddell: i'll try to drum up some more testing for mythbuntu
<stgraber> jibel: what's wrong with Chinese? don't you get ibus?
<stgraber> jibel: in my tests I saw the ibus icon appearing but you had to explicitly go through its preference screen to add pinyin as an input method, then it worked fine
<pitti> hey skaet
<stgraber> jibel: my guess was that some piece was broken on the desktop causing the empty ibus config by default
<doko> Riddell, when do you expect the thaw?
<skaet> pitti,  https://bugs.launchpad.net/ubuntu/+bug/468778 - can you see if this is something obvious to you in the publishing?
<ubot2`> Launchpad bug 468778 in Ubuntu Precise "MD5 checksum mismatch for the DVD image metalink files" [High,Confirmed]
<Riddell> doko: when skaet says so, a few hours maybe
<jibel> stgraber, same here, but I'm like blind with this language and pinyin should be listed by default
<pitti> well, as soon as we are sure that we won't respin, we could just as well thaw
<Riddell> skaet: TechnicalOverview updated for Kubuntu
<pitti> Riddell: ^
<pitti> skaet: ^ I mean
<stgraber> jibel: indeed, IIRC in my tests I assumed it was a desktop bug as ibus was behaving the exact same way with a regular desktop install
<stgraber> jibel: I mean, going through a live session in Chinese
<skaet> pitti,  doko, Riddell,  want to let some more of the test results come in and make sure no big surprises there please.
<jibel> stgraber, I'll file a bug
<stgraber> jibel: thanks
<jibel> and it should be release noted
<Riddell> Lubuntu really needing more testing too, no gilir on channel to poke
<doko> skaet, it was just an informal question
<stgraber> pitti: who should we poke for ibus related weirdness in your team?
<jibel> stgraber, after adding the method in the preferences, i confirm it works fine
<pitti> stgraber: you hit a sore spot there -- we actually do not have anyone who knows about it ATM; I keep whining about this, too :/
<pitti> stgraber: for now, subscribe canonical-desktop-team
<Daviey> skaet: wilco
<pitti> stgraber: some of the OEM engineers might be able to help out, we'll ask around
<Daviey> jibel: Is that test not automated?
<Riddell> pitti: tell freeflying he needs to rotate onto the desktop team, he sorted out kubuntu years ago for that but it all needs done again
<jibel> Daviey, iscsi is not automated
<skaet> slangasek or ogra_ ,  could you take a pass at the Ubuntu Core section please in the https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<Daviey> jibel: suck, i thought it now was. dammit.
<jibel> jamespage is the bot for this case
<Daviey> jibel: i know, i just pinged him :)
<stgraber> pitti: ok. I have a very basic understanding of ibus for having worked for a year and a half with a Chinese customer deploying Ubuntu desktops but I'd prefer not to extend that knowledge ;)
<Riddell> skaet: nobody has tested amd64+mac or powerpc for any flavour, shall we accept they're not going to be published?
<skaet> Riddell,  let me look.   there was some testing in the historical ones,  and I know lubuntu's been on the powerpc last night and seemed happier.
<skaet> jibel,  do we have any testing results for the amd64+mac images?  I thought they were scheduled to be run this milestone.
<jamespage> Daviey: running iscsi tests now
<jibel> skaet, no results
<Daviey> jamespage: you diamond geezer
<skaet> jibel,  ack.  if no results, then they don't go out.
<Daviey> Riddell: Surely it makes sense to publish them on the page, but *not* declare them part of the release.
 * skaet goes to mark on the iso tracker.
<skaet> Daviey,  they can pick them up from the dailies
<Daviey> right.
 * skaet wants folk who use those images to participate in the testing... :P
<brendand> skaet, for some of these more obscure architectures, wouldn't it be good to 'ensure' the were tested. if you know what i mean
<skaet> brendand,  yes.   Attempts this time around appear to have failed. :P
<ogra_> skaet, checking
<jibel> stgraber, bug 944035 could you confirm please
<ubot2`> Launchpad bug 944035 in ibus "pinyin not listed by default on a fresh installation" [Medium,New] https://launchpad.net/bugs/944035
<Riddell> skaet: have we given up on using https://help.ubuntu.com/community/PreciseUpgrades ?
<brendand> skaet, well - i meant along the line of having someone whose job it is to do it
<Riddell> brendand: canonical doesn't support those arches
<stgraber> jibel: done
<jibel> ta
<Riddell> skaet: on https://wiki.ubuntu.com/RecognizedDerivatives does "Services that Canonical does not provide (but community members may) publishing on releases.ubuntu.com " mean "publishing on a widely mirrored server"?
<Riddell> it doesn't mean community may hack into releases.u.c and publish these anyway?
<Riddell> and shouldn't that page be renamed to RecognizedFlavours ?
<Riddell> although I suppose that would mix the US and British spellings :)
<Daviey> I am starting a new Flavour called RaspberryRipple edition, if anyone wants to help out.
<skaet> Riddell,  yeah the page needs renaming and a redirect link put in place for the historical.
<Riddell> Daviey: oh apachelogger would love that, he's not been a good maintainer of his fluffy flavour
<dobey> is the ui freeze only for apps in the default install?
<stgraber> dobey: no
<dobey> stgraber: the wiki page is wrong then :)
<nessita> stgraber: dobey meant the string freeze
<dobey> https://wiki.ubuntu.com/UserInterfaceFreeze says "applications which are installed by default"
<stgraber> hmm, maybe I'm wrong but I've always considered UI Freeze to affect anything that's part of any official documentation/screenshot
<pitti> interesting, I wasn't aware of this
<pitti> I had considered it to apply to the whole archive
<dobey> stgraber: as did i, but we are discussing it now in a team meeting, and there is some confusion :)
<stgraber> which can extend to pretty much anything in the archive and so usually meaning you always want a freeze exception
<stgraber> even if it's pretty easy to get if it's not in any screenshot/documentation
<dobey> pitti: i guess it should be discussed in release meeting tomorrow perhaps, to clarify and fix the wiki page if it's wrong?
<skaet> Riddell,  clarification is probably appropriate as well.
<pitti> dobey: *nod*
<pitti> we won't have a meeting tomorrow
<dobey> oh
<dobey> hrmm
<nessita> pitti: since we're in the freeze exception talks... may I ask how can I make this ffe move forward? https://bugs.launchpad.net/ubuntuone-control-panel/+bug/933697
<ubot2`> Launchpad bug 933697 in ubuntuone-control-panel "[FFE] Integrate missing pages to Qt Control Panel" [Undecided,New]
<dobey> pitti: what's the fastest way to resolve that then? just ask skaet to make an executive order? :)
<pitti> nessita: ah, I left a comment there two weeks ago
<pitti> dobey: I'm not sure really; as it affects the whole project, it should probalby be on -devel@ first
<nessita> pitti: yeah, but not sure what the kubuntu folds have the final word on that, since this is an ubuntu app
<dobey> pitti: ok, i'll send a mail
<pitti> nessita: ah, it's not in Kubuntu either
<skaet> nessitta, pitti, dobey - given there's a bunch of issue,  monday meeting (in new meeting format) work for folk?   updates should still go to ubuntu-release mail list by tomorrow though.
<nessita> pitti: perhaps your wrote that when there was some confusion about U1 going with the qt control panel by default?
<pitti> nessita: bug updated
<pitti> nessita: I just had assumed that the qt control panel was in Kubuntu
<nessita> pitti: that was fast! thanks :-)
<dobey> skaet: what time is that?
<pitti> skaet: I already have a meeting at 1600 UTC
<pitti> skaet: but the "what is UIF" discussion ought to happen by mail IMHO anyway
<Riddell> ubuntuone-control-panel qt isn't in kubuntu at all, that's something to look at for +1
<skaet> dobey,  time hadn't been set.   Lets see if we can get it handled by mail first,  and if not - I'll try to find a time that works for most regular attendees and put it on the calendar.
<dobey> skaet: ok
<skaet> pitti,  noted.
 * skaet prefers mail if possible after this week too.... 
<jamespage> Daviey: iscsi tests all done
<Daviey> jamespage: \o/
<slangasek> ogra_: could you fill out the Ubuntu Core "new features" section on https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview as well?
<slangasek> ogra_: I think we should probably mention armhf here in some context; Ubuntu Core might be the place to put that?
<stgraber> skaet: Edubuntu is ready for beta1 (fully tested, no bugs identified), I'm running a Chinese OEM install now for fun but even if that breaks it's not really a big use case for us, at least not for beta1 :)
<ogra_> slangasek, no prob, totally forgot that we didnt have -core for armhf in the past
<slangasek> ogra_: thanks :)
<skaet> Thanks stgraber!  :)
<pitti> skaet, Riddell: need to leave to pick up my wife from the hospital; I'll check back again later
<skaet> pitti,  thanks!
 * GrueMaster wakes up, wishes for a bacon maple bar, starts testing mx5 instead.
 * skaet curious about what a bacon maple bar is.... 
<utlemming> skaet: http://en.wikipedia.org/wiki/Maple_bacon_donut (don't look if you've just eaten)
<skaet> utlemming,  thanks!  :)
 * Riddell makes https://help.ubuntu.com/community/PreciseUpgrades/Kubuntu and https://help.ubuntu.com/community/PreciseUpgrades/Kubuntu/10.04LTS
<skaet> Riddell,  do you want me to just remove the images its clear we're not shipping from the tracker now,  or just leave them marked as disabled (ie. stroked out).
<Riddell> skaet: stroked out is good
<Riddell> skaet: which ones are we not shipping?
<skaet> Riddell still waiting for some final results to come in and get jibel's report.
 * skaet will stroke them out as they get ruled definitely no.
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseBeta1TestReport
<skaet> thanks jibel, looking.
 * Riddell makes https://wiki.kubuntu.org/PrecisePangolin/Beta1/Kubuntu
<skaet> thanks Riddell!  :)
 * skaet likes the image in Calligra screen shot.
<Riddell> best app for making hackergotchis :)
<GrueMaster> jibel: Remove bug 925069.  That was fixed with the respin (unless you count kubuntu).
<ubot2`> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Confirmed] https://launchpad.net/bugs/925069
<jibel> GrueMaster, ok, close the bug then, I'll regenerate the report.
<GrueMaster> And bug 924456 was a firefox auto-fill glitch on my end when updating the tracker late last night.
<ubot2`> Launchpad bug 924456 in ubiquity "ubiquity panel crashed with a segfault during oem-config-remove step" [Undecided,Invalid] https://launchpad.net/bugs/924456
<GrueMaster> I already updated the tracker accordingly.
<GrueMaster> bug 925069 closed.  I think this is the first time we've had working audio on Panda at Beta 1.
<ubot2`> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Confirmed] https://launchpad.net/bugs/925069
<Riddell> skaet: on the kubuntu side we're all ready except we don't have anyone who can test netbook amd64 (probably not a useful test) and we don't have anyone who can test wubi
<skaet> Riddell,  sounds reasonable for beta then.  :)
<skaet> Riddel,  kubuntu active - what's the plans for it.
<skaet> ?
<Riddell> skaet: well hopefully get the images working for beta 2, it is --><-- that close
<skaet> RIddell.   :)  coolio.
<Riddell> just needs the session added and working
<Riddell> skaet: what needs doing before I start on the Release minus 15 minutes tasks?
<skaet> Riddell,  adding key bugs to TechnicalOverview (and removing those now fixed ;) )
<ScottK> Is it OK to start dribbling stuff to the builders yet?
<Riddell> skaet: "Ask LOSA to set the distrorelease back to DEVELOPMENT in Launchpad" can I do that now (it says release +1 day which seems curious)
<Riddell> ?
<skaet> Riddell,  notion historically was to wait until the images were out to make sure all the archive snapshots folks were taking were done before the flood started.
<Riddell> archive snapshot talks?
<skaet> Riddell,  see earlier in the checklist....  can you check they're done?
<skaet> ScottK,  wait for us to check on that snap shot before anything serious.   ok for universe at this point,  we've got the images we're going with.
<Riddell> skaet: I don't think it says anything about archive mirrors on https://wiki.ubuntu.com/BetaProcess
<Riddell> skaet: all the mirrors I can think of in far away lands include ubiquity 2.9.23 which was one of the last packages uploaded
<Riddell> e.g. http://kr.archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/
<skaet> Riddell,  not the mirrors - Notify commercial engineering (email: david.murphy@canonical.com AND cc: ce-infrastructure@lists.canonical.com; IRC: schwuk) that the archive is in a consistent state
<skaet> if schwuk is done,  we should be good to start the thaw.
<skaet> Riddell,  sorry to be ambiguous.  typing to fast....
<skaet>  https://help.ubuntu.com/community/PreciseUpgrades
<Riddell> that PreciseUpgrades page looks a bit empty
<skaet> Riddell,  yeah,  can you take a first pass at putting something sane in it.
 * skaet noticed its referenced from the announce usually.
<skaet> ?
<Riddell> skaet: that page is for ubuntu desktop, I've no idea how to upgrade that
<Riddell> seb128: ping
<seb128> Riddell, pong
<Riddell> 17:57 < skaet>  https://help.ubuntu.com/community/PreciseUpgrades
<Riddell> 17:57 < Riddell> that PreciseUpgrades page looks a bit empty
<skaet> https://help.ubuntu.com/community/OneiricUpgrades - should be close, and useful as starting point.
<Riddell> seb128: who can do that page?
<Riddell> 17:59 < schwuk> Riddell: we're done with main, so don't block on us
<Riddell> skaet: ^^
<seb128> let me look, I've no clue about this URL
<seb128> https://help.ubuntu.com/community/OneiricUpgrades?action=info
<seb128> no desktoper updated it previous cycle
<seb128> I would say just copy the oneiric one...
<Riddell> seb128: ok I'll do that
<Riddell> oh except that wiki doesn't let you copy pages, sigh
<GrueMaster> Open two tabs, one for the old page, one for the new.  Open the wiki editor in both, copy, paste.  Not terribly difficult.
<Laney> blasted ghc fails on armhf
<Riddell> seb128: please find an ubuntu person to update the various ubuntu bits on https://help.ubuntu.com/community/PreciseUpgrades
<GrueMaster> I thought that was fixed.  Did a new upload clobber it?
<GrueMaster> (referring the ghc)
<Laney> something has regressed
<Laney> the previous version worked
<Laney> i pinged upstream on their bug tracker. depending on what they say, i'll try a HEAD build on a porterbox
<Riddell> hmm no pitti, didrocks, mvo or seb128 to update the upgrade page.  amazing how a flavour so well resources can be the one we end up waiting on.
<seb128> Riddell, is that blocking anything?
<Riddell> seb128: yes, beta 1
<seb128> Riddell, it's like you ping at 7pm and you need an update NOW
<Riddell> seb128: it is pinging at 7pm and needing an update :)  but beta 1 has been on the schedule for months
<seb128> and the update is not hard to do just do a replace all 11.10 -> 12.04 and then 11.04 -> 11.10
<seb128> Riddell, well, that's the first time in my life I read about this page I think
<Riddell> on you go then, I'm not in a position to read it over and check it's correct
<seb128> it's not like it's something we knew we were supposed to do
<seb128> Riddell, right, I didn't mean it has to be you, like skaet or anything could do it
<seb128> but let me do it
<seb128> I was just doing something and getting late for dinner
<Riddell> seb128: it's not new, it's part of the release for many years, I'm only hassling you because jason and whoever else is on the release team from ubuntu is away
<Riddell> so blame jason :)
<skaet> Riddell,  where are the Ubuntu Core images going to be landing path wise?   can you give me the path...
<Riddell> skaet: that I don't know, let me see if I can work it out
<Riddell> skaet: http://cdimage.ubuntu.com/ubuntu-core/releases/12.04/beta-1/
<skaet> Riddell,  great.  Thanks!   it seems to be missing from the TechnicalOverview.  I'll add it to the announce now, and TechnicalOverview, next time I open it.
<Riddell> skaet: you might want to add an explanation of what it actually is :)
<skaet> Riddell - there's an ubuntu core section.   ogra_ added some comments earlier.   Feel free to add more clarity though if you think its needed.  ;)
<Riddell> skaet: we can unfreeze now?
<Riddell> "Ubuntu Core saw just the general version upgrades for the contained packages."  for a new flavour that's not a very good description
<seb128> Riddell, skaet: https://help.ubuntu.com/community/PreciseUpgrade updated
<Riddell> NCommander: I think you gave us a description the other day?
<skaet> seb128,  thank you!!!
<seb128> yw
<NCommander> Riddell: minimal Ubuntu environment subtiple for highly customized installs
<Riddell> seb128: is that true for both 11.10 and 10.04 LTS ?
<Riddell> NCommander: is it like jeos was?
<seb128> Riddell, I'm about to do an update for that but wiki is slooooow
<skaet> superm1,  how's Mythbuntu's tests looking?   we good to ship?
<Riddell> NCommander: added https://wiki.kubuntu.org/PrecisePangolin/TechnicalOverview#Ubuntu_Core
<pitti> Riddell: sorry, "upgrade page"?
<superm1> skaet: not looking too good with bug 944131
<ubot2`> Launchpad bug 944131 in mythbuntu-live-autostart "Colors are broken in install mode" [Undecided,New] https://launchpad.net/bugs/944131
<Riddell> pitti: I think I hassled seb128 into doing https://help.ubuntu.com/community/PreciseUpgrade for ubuntu
<superm1> somehow the GTK theme got broke with no changes, but not sure exactly when
<skaet> superm1 - ah you might have run into what lubuntu had to do their respin for last night,  some upstream changes borking things.  :(
<pitti> oh, that wasn't on my radar either indeed
<superm1> skaet: oh goodie, if upstream changes fix it that would be wonderful! :)
 * skaet goes looks for reference....
<superm1> bug 944131 shows what it looks like
<ubot2`> Launchpad bug 944131 in mythbuntu-live-autostart "Colors are broken in install mode" [Undecided,New] https://launchpad.net/bugs/944131
<superm1> oops i didn't relaize i put that above already
<Riddell> skaet: shall I add "hassle ubuntu people to update PreciseUpgrade" to BetaProcess?
<Riddell> I mean "ask politely" :)
<seb128> Riddell, pitti: updated https://help.ubuntu.com/community/PreciseUpgrades but it can probably do with some tweaking, like I dupped the desktop upgrade section for 11.10 and 10.04 and just changed the menu use to dash use for 11.10 and the software-properties normal->lts option
<GrueMaster> Riddell: Under Known Issues, bug 871785 no longer affects preinstalled images.
<ubot2`> Launchpad bug 871785 in ubiquity "crash on ARM at the end of install" [High,New] https://launchpad.net/bugs/871785
<GrueMaster> (not sure why it wasn't closed.  It was fixed before Alpha 1 iirc.
<Riddell> skaet: you onto that or shall I? ^^
<Riddell> seb128: lovely, thanks
<skaet> Riddell,  please do.   am on image scrub mode....
 * skaet will find bug for superm1 and pitti after - not showing up after quick search.   Look at the logs (#ubuntu-meeting, #ubunt-testing, #ubuntu-release) from yesterday evening UTC. 
<GrueMaster> Riddell: While you are in edit mode, we should add a section on Arm Hard Float support.  ogra_ should have the details.
<Riddell> GrueMaster: that's the armhf images?
<GrueMaster> yes.
<Riddell> ogra_: anything to say on it?
<GrueMaster> And I believe armel images are being dropped, with the pool reverting to sustaining mode.
<GrueMaster> armel pool, that is.
<skaet> Riddell,  ok,  I've marked off the images we won't be shipping.
<skaet> Riddell, pitti, jibel - can you do a pass on the image set on the tracker and see if it all makes sense to you?
<Riddell> skaet: hmm xubuntu features on the technicalOverview page include "Using the new installer, maybe-ubiquity" I suspect they might not have got the idea of marketing worked out
<skaet> Riddell, yup, tweak it please.
 * skaet going to adjust the Announce to not have Mythbuntu... 
<superm1> skaet: https://lists.ubuntu.com/archives/precise-changes/2012-February/011040.html ?
<skaet> superm1 yes - problem is upstream though, according to the discussion I was seeing.   lubuntu put in a workaround.
<skaet> superm1 - not sure if the unico in the queue right now address it or not.
<superm1> seb128: you were the uploader for the unico in the queue, can you comment on if that will be fixing it?
<superm1> if not, i guess i can probably adapt the workaround that lubuntu is using temporarily for us too
<seb128> superm1, "it"?
<superm1> seb128: bug 938472
<ubot2`> Launchpad bug 938472 in lubuntu-artwork "dialogs are barely readable-- grey on black????" [Undecided,Fix released] https://launchpad.net/bugs/938472
<superm1> the upstream change that skaet and I were discussing
<seb128> superm1, not likely, that would rather be a light-themes update
<GrueMaster> heh.  People on #ubuntu-arm are already chomping at the bit for Beta 1.
<seb128> kenvandine is supposed to upload one once the freeze ends
<skaet> GrueMaster, all the bugs you aware that folks might bump into already in the TechnicalOverview?
 * GrueMaster rechecks.
<kenvandine> seb128, already uplaoded
<seb128> kenvandine, great, thanks
<GrueMaster> There were other bugs for arm server, but mainly annoyances.  Other than that, everything looks fairly accurate.
<ogasawara> skaet: fyi, I just added 911059 to kernel known issue for Technical Overview
<skaet> Thanks ogasawara
<GrueMaster> skaet: On the tech overview, I still see bug 925069 under Desktop issues.
<ubot2`> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Fix released] https://launchpad.net/bugs/925069
<GrueMaster> Leave it under Kubuntu though, as we didn't respin those images.
<skaet> GrueMaster, perfect.  Thanks
<slangasek> skaet, GrueMaster: so did someone fix the md5sums issue, or did it just recur with the latest arm desktop builds?
<skaet> superm1, pitti - https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/943682%C2%A0
<ubot2`> Launchpad bug 943682 in gtk+3.0 "gtk3 draws black backgrounds with unico themes" [High,Confirmed]
<slangasek> s/just recur/just not recur/
<GrueMaster> slangasek: I checked the daily-preinstalled/20120301.1 directory this morning.  They looked ok.
<slangasek> yeah, I've just confirmed here that they're ok
<skaet> slangasek,  infinity thought the problem was someone doing things by hand, but if its reoccured - there is something that needs fixing.
<GrueMaster> ubuntu-server is still out of whack, but they weren't respun.
<slangasek> ok
<slangasek> yes, the problem *hasn't* recurred
<superm1> skaet: ah okay so this won't be fixed by the updated unico in the queue or the light-themes in the queue then
 * skaet having problems parsing that last comment from slangasek..
<Riddell> skaet, Daviey: the BetaProcess page doesn't seem to say anything about the cloud images, presumably someone takes care of those?
<skaet> are the md5checksums ok?
<slangasek> yes
<slangasek> the problem hasn't recurred
<slangasek> :)
<skaet> Riddell,  utlemming will publish.
<skaet> thanks slangasek.
<skaet> :)
<Riddell> skaet: should i add "ensure utlemming publishes cloud" to Process page?
<Riddell> manifest page says the release contact is Antonio Rosales who has no wiki page
<Riddell> Daviey: nudge your friend arosales into makeing a wiki page please :)
<utlemming> Riddell: Antonio (arosales) is my manager
<skaet> Riddell,   yeah,  may as well make it explicit.
<skaet> thanks!
<utlemming> Riddell: as capable as he is, I'm the one that pulls the trigger
<skaet> :)
<skaet> utlemming - trigger pull for yours.
<Riddell> utlemming: this ok for 15 minutes before release task? " 1. Ensure Server Cloud team publishes cloud images (IRC: utlemming)"
<utlemming> Riddell: ah yeah, that is
<skaet> Riddell,  image set up on the tracker match your expectations?
<utlemming> It takes about 15 minutes to do the publishing task
 * skaet wants another set of eyes due to the late changes on the big list.
<Riddell> skaet: yep
 * utlemming starts publishing cloud images
<skaet> Riddell,  ok, go ahead and start publishing that set as well,  we'll be needing to check the links VERY carefully on these before any announce go out.
<Riddell> ack
<Riddell> I don't plan to do anything without it being VERY careful :)
<utlemming> looks like I have a slight bug in the publishing step...investigating
<skaet> Riddell,  :)
<Riddell> skaet, pitti: the diff command says to diff against ../www.prev/full  do I just copy that at the start to get it in sync?
<skaet> slangasek, infinity, ^
<Riddell> "ssh: Could not resolve hostname beryllium.ubuntu.com: Name or service not known"  sync-mirrors out of date?
<Riddell> same for chromium.canonical.com
<Daviey> hey
<Riddell> skaet: this looking good? http://cdimage.ubuntu.com/kubuntu/releases/precise/beta-1/
<Daviey> Riddell: yes, i've been tracking the cloud images.
<Riddell> skaet: that should be kubuntu done, if it's good I can move down the publish list
<skaet> Riddell,  probably need to change sentence at the top "For the most frequently downloaded CD images, see releases.ubuntu.com."
<skaet> actually all 3 probably need rewriting.
<Riddell> skaet: all 3 which?
<skaet> Riddell,  intro paragraph on top of Kubuntu page
<skaet> http://cdimage.ubuntu.com/kubuntu/releases/precise/beta-1/
<utlemming> okay...cloud-image publishing is progressing now. Root cause was that we dropped ARMEL for cloud images and replaced it with ARMHF. The cdimage scripts were looking for ARMEL images.
<Riddell> skaet: I've removed that sentence, what do you mean by "all 3"?
<Riddell> gosh he left quick, must be confident it's all sorted
<Riddell> utlemming: they have arm clouds now?
<Riddell> stgraber: bug 944103 not a big issue for edubuntu?
<ubot2`> Launchpad bug 944103 in xorg "unity does not appear" [Undecided,Confirmed] https://launchpad.net/bugs/944103
 * Riddell skips edubuntu and does lubuntu
<Riddell> skaet: lubuntu into their powerpc are they?
<utlemming> Riddell: armhf images are tech preview for whenever the vapor coloalesces to create a cloud
<stgraber> Riddell: all 4 installs I made all worked, so no, that must be specific to this tester
<Riddell> stgraber: groovy
<stgraber> Riddell: moved the bug to non-serious as 3 other reporters reported the same test as a pass
<skaet> Riddell, yup.  they've got some folks with machines willing to test.  :)
 * Riddell twiddles thumbs waiting on the edubuntu images to publish
<Riddell> hi knome
<knome> hello Riddell
<knome> is there something urgent?
<Riddell> knome: beta 1 :)
<Riddell> knome: ok to publish?
<Riddell> knome: and are you happy with your technical overview
<utlemming> cloud-images are now published
<Riddell> waiting on beta-1 to appear at http://cdimage.ubuntu.com/edubuntu/releases/12.04/ and http://cdimage.ubuntu.com/lubuntu/releases/12.04/
<GrueMaster> Riddell: Couple of things on http://cdimage.ubuntu.com/kubuntu/releases/precise/beta-1/ the armhf images aren't there, and the MD5SUMS for them don't match what I have tested (not that the daily-preinstalled MD5SUMS matched either).
<knome> Riddell, yes, as said in #xubuntu-devel. and yes, that's fine really, though i don't know why the maybe-ubiquity -message was weird.
<Riddell> knome: I couldn't parse it, put it back if you're happy with it
<Riddell> it read like "maybe we have this new installer thing, or maybe not"
<knome> Riddell, no, "maybe-ubquity" is the installer *name*
<knome> +i
<Riddell> knome: I know that now, but nobody reading it for the first time will
<skaet> slangasek, ^ looks like we've got MD5SUMS problems - can you dig into it a bit.
<skaet> ?
<knome> Riddell, okay, the release notes for xubuntu are updated.
<Riddell> GrueMaster: kubuntu-12.04-beta1-preinstalled-desktop-armhf+omap{,4}.img.gz is on the master so I guess it's still syncing
<slangasek> skaet, GrueMaster, Riddell: confirmed that the md5sums are bad for the arm images there; will regenerate
<Riddell> thanks slangasek
 * Riddell moves onto xubuntu and ubuntustudio
<ScottK> Who emptied the New queue?
<skaet> thanks slangasek
<skaet> ScottK ???
<ScottK> https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
<ScottK> Nothing there now.
<ScottK> Someone on #ubuntu-devel is wondering why his package got rejected.
<Riddell> wasnae me
 * skaet shakes head....   really wants that logging....  yesterday
<Riddell> jdstrand logged in?
<ScottK> And I can tell you're really you since you're IRCing in Scottish.
<jdstrand> Riddell: ?
<jdstrand> oh, I am deNEWing
<jdstrand> I accidentally rejected some stuff and am putting it back
<ScottK> OK.
<ScottK> There we go.
<slangasek> md5sums, sha1sums updated; strangely the sha256sums were already correct
<ScottK> Actually it was #ubuntu-motu.
<Riddell> stgraber: http://cdimage.ubuntu.com/edubuntu/releases/12.04/beta-1/ appearing
<Riddell> slangasek: when I do the ubuntu ones they'll be correct now?
<slangasek> Riddell: as far as we know; we haven't reviewed them all
<slangasek> the only ones that have turned up broken so far were the arm ones GrueMaster reported
<slangasek> and the working theory is that someone did something by hand that broke them to begin with
<Riddell> slangasek: do you know how to reset www.prev for diffing?  just rm -r and cp -r ?
<Riddell> (which sounds scary)
<slangasek> Riddell: I rm -r www.prev when done with it, yes
<slangasek> and please cp -al to recreate
<slangasek> so that you're not doubling the disk usage unnecessarily :)
<Riddell> running rm -r anywhere on that server sounds scary :)
<slangasek> yeah
 * ScottK hands Riddell an 'f' to make it even more fun.
<GrueMaster> Add a -f, you'll be fine.
<ScottK> What could go wrong?
<GrueMaster> Oh, and IS likes it when you start from /.
<Unit193> -v lets you see the horror you could have caused had you not done it.
<Riddell> GrueMaster: while I'm waiting on ubuntu to sync, what's the relationship between omap, omap4, ac100 and mx5?
<GrueMaster> Relationship?  They are different platforms.
<GrueMaster> Each arm SOC requires specific kernel & bootloader.
<ScottK> Riddell and/or skaet: Can we start accepting stuff yet?
<Riddell> ScottK: good with me
<ScottK> OK.
 * ScottK looks
 * Riddell asks to set back to Development in Launchpad
<ScottK> Just accepting Universe stuff for the moment so any new main upload would get the next buildd.
<Riddell> GrueMaster: who's the manufacturer of each?  and which is this pandaboard?
<ScottK> Or not due to LP timeouts.  We'll see.
<GrueMaster> Riddell: check http://wiki.ubuntu.com/ARM
<Daviey> Who has been reject'ing NEW things?
<Daviey> (without a rejection mail.)
<Riddell> Daviey: jdstrand (but try not to be grumpy else you'll sound like me :)
<Daviey> hah
<Riddell> ScottK, skaet: https://launchpad.net/ubuntu/precise says "Status: Active Development"
<ScottK> ;-)
<skaet> Thanks Riddell.   time to turn off the bot?
<Riddell> skaet: yes, is that you who does that?
<skaet> stgraber, ^ can you turn off the channel bot now.   We're back to letting things flow in to the archives.
<skaet> not announced though yet - still checking all the links.. etc.
<stgraber> skaet: once unapproved has been flushed it should stop automatically as nothing should hit unapproved anymore
<skaet> stgraber,  coolio.  thanks.
<Riddell> knome: please check over http://cdimage.ubuntu.com/xubuntu/releases/precise/beta-1/
<Riddell> skaet: http://releases.ubuntu.com/ looks updated
<micahg> stgraber: re packagesets and gdebi, the issue was it was a package in main which are generally not allowed in the flavor packagesets, I'm working to have it demoted though which I why I said the case would be moot
<Riddell> pitti, Daviey: please check over http://releases.ubuntu.com/precise/
<skaet> Riddell,  thanks.  will see if the web side can see it now then...
<stgraber> micahg: k
<Unit193> The 32bit ISOs for Lubuntu check with those md5sums.
<Riddell> lovely
<phillw> unit do you want me check the amd64's and ppc ones?
<phillw> Unit193: ^^
<Unit193> Well, I don't have those.
<Riddell> skaet: this for me to do? "Copy .manifest to .manifest.full, pruning all images from previous releases from the .manifest file to allow timely mirror probing."
<phillw> okies, I'm grabbing them now :)
<phillw> lubuntu-12.04-beta1-alternate-powerpc.iso is okay
<phillw> lubuntu-12.04-beta1-desktop-amd64.iso is okay
<Riddell> slangasek: can you tell me what needs pruned in .manifest ?
<Riddell> "Copy .manifest to .manifest.full, pruning all images from previous releases from the .manifest file to allow timely mirror probing." but it has previous releases
<slangasek> yes, prune the previous releases
<slangasek> you only want the precise images in the manifest for milestone publishing
<slangasek> otherwise the mirror prober takes an eternity to check mirrors
<Riddell> slangasek: but it has lots for maverick lucid hardy oneiric, I should scrap them all?
<slangasek> yes
<slangasek> they're backed up to .full, that's the point :)
<Riddell> slangasek: like this http://paste.kde.org/432062/ ?
<phillw> lubuntu-12.04-beta1-desktop-powerpc.iso is okay.
<Riddell> it just seems a bit weird since all the non oneiric ones should have gone last beta
<slangasek> Riddell: exactly right
<Riddell> phillw: I think you only need tell us if one is wrong :)
<slangasek> Riddell: well, post-milestone the .manifest.full is meant to be moved back
<slangasek> I don't know if we have that on the checklist
<Riddell> oh I see
<Riddell> I expect we do
<phillw> Riddell: oops - well Unit193 has checked the i386 ones and I've checked the ppc & amd64 ones... all good to go :)
<Riddell> http://se.releases.ubuntu.com/precise/ seems to be on the ball
<slangasek> it's largely push mirroring nowadays, which helps
<Riddell> slangasek: "Check torrents for proper functionality" that means grabbing a .torrent file and checking it torrents?
<slangasek> yeah
<slangasek> intended as a spot check because we used to have big problems with the torrent server
<Riddell> hmm it says "stalled" when opening in ktorrent
<Riddell> "error(s): [20:46:44] rejected by tracker - Requested download is not authorized for use with this tracker."
<slangasek> do you get the same error for a 11.10 torrent?
<Riddell> slangasek: nope
<Riddell> that starts the download
<slangasek> Riddell: hmm, escalate to #is
<knome> Riddell, there's only alternates for xubuntu?
<Riddell> knome: http://cdimage.ubuntu.com/xubuntu/releases/12.04/beta-1/ lists Desktop and Alternate
<Riddell> if the desktops aren't there yet that's just syncing
<knome> Riddell, right'o, thanks
<Riddell> skaet: besides torrents  (which is being looked at) and mirror syncing I think I'm all done
 * Riddell goes to get some food, back soon
<skaet> Riddell,  thanks!  enjoy dinner.
 * skaet working on editing the release notes a bit to make more consistent style throughout and grammer improvements.
<skaet> lol,  ^ maybe someone else should take the grammar pass on them...
<NCommander> skaet: ping?
<stgraber> skaet: doing a quick pass (though I'm clearly not the best at english grammar for obvious reason)
<slangasek> s/reason/reasons/ ;-)
<slangasek> oh no, I've just volunteered myself
<phillw> slangasek: congratulations :D I was going to approach https://launchpad.net/~pedro3005 as he does my grammar stuff for wiki / tutorials etc :)
<slangasek> ah, stgraber has the lock though
<stgraber> skaet, pitti: shouldn't remmina be listed somewhere on TechnicalOverview?
<stgraber> slangasek: yep, half way through the page (have a few minor fixes)
<slangasek> stgraber: can you fix s/OV/OW/, please :)
<slangasek> that's been bugging my inner wannabe EE
<skaet> slangasek, stgraber - official page has now moved to https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta1 - yes, it needs some love.  All help much appreciated.  signal here, when editing.
<Riddell> torrents are fixed now
 * stgraber dreams of a world where the wiki takes less than 5 minutes to render a preview of a page...
<stgraber> slangasek: should we list resolvconf in Other after the dnsmasq entry?
<slangasek> stgraber: makes sense to me
<stgraber> hmm, is Ubuntu core really still considered "new"?
<stgraber> we already had it for Oneiric I believe, didn't we?
<phillw> are you going to mention the G3 ppc issue for lubuntu as a flag, or do you want to await further testing?
<skaet> stgraber, it was a tech preview in Oneiric,  so new probably should be altered.
<jdstrand> ok, the new queue should be back in order (and yes, it is actually caught up)
<slangasek> stgraber: correct, core existed already in 11.10
<slangasek> stgraber: if you're still editing, can you also replace the references to bugs 904240 and 940396 with a single reference to 927993?
<ubot2`> Launchpad bug 904240 in launchpad "Please give permissions to tue Ubuntu Translations Coordinators team to request full language pack exports" [Low,Triaged] https://launchpad.net/bugs/904240
<ubot2`> Launchpad bug 940396 in update-manager "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime (dup-of: 927993)" [High,New] https://launchpad.net/bugs/940396
<ubot2`> Launchpad bug 927993 in apt "distribution upgrade from lucid to precise failed with : package dpkg is already installed and configured" [High,Triaged] https://launchpad.net/bugs/927993
<slangasek> bug #940240, I mean :)
<ubot2`> Launchpad bug 940240 in update-manager "lucid -> precise upgrade: dist-upgrade/apt-term.log only shows packages being removed" [High,Triaged] https://launchpad.net/bugs/940240
<slangasek> skaet: ^^ bug #940240 impacts automated testing and nothing else
<skaet> Riddell, ScottK, stgraber, gilir, scott-work, phillw, knome - can you look through https://wiki.ubuntu.com/PrecisePangolin/Announcement/Beta1 and make sure I've got the highlights for each of your products accurate.
<skaet> slangasek,  thanks for noticing that.  :)
<knome> skaet, is it intentional that the default shortcuts-section is removed from xubuntu?
<skaet> knome,  yes, was trying to just pick up the big features - this is a teaser so they'll look at the details under your project.
<knome> skaet, coul you also add: "For more information, go to http://xubuntu.org/"
<knome> +d :)
<knome> -,, if you like
<skaet> knome,  happy to.   Adding.  :)
<knome> i mean, a link is always nice ;) thanks :)
<stgraber> slangasek: changes saved (including yours)
<slangasek> stgraber: thanks
<skaet> thanks stgraber
<phillw> skaet: "The final version of Ubuntu 11.10 is expected to be released on  April 26, 2012." ... oops?
<skaet> phillw - you win the prize!   good catch!
<skaet> knome, phillw, changes made.
<knome> skaet, thanks
<highvoltage> oh shoot, I wanted to win the prize this cycle :( (at least there's always next time)
<phillw> skaet: as per what knome said, is it poosible to add For more information, go to https://wiki.ubuntu.com/Lubuntu for us? We may be moving lubuntu.net about a bit soon, so wiki entry is going to be safer
<skaet> highvoltage,  :)
<skaet> phillw - sure.  will change.
<phillw> the new theme is about to go to sandbox, hoping to have it out before 12.04 :)
<stgraber> skaet, slangasek: I'm not sure if we should promote the dnsmasq/resolvconf change to the announcement instead of just the release notes. It technically was already these in alpha-2 but if people start testing with beta-1 they might be a bit surprised (especially for servers)
<slangasek> IMHO it doesn't need to be in the announcement
<slangasek> I think that's the sort of thing people are meant to read release notes for
<stgraber> yeah, I guess they at least will before filing a bug report ;)
<skaet> stgraber,  I agree with slangasek,   announce is just a teaser so folks go read more info,
<gilir> skaet, looks ok for me, thanks phillw for the check :)
<skaet> in release notes, etc.
<phillw> gilir: oooh, Hiyas Boss!
<stgraber> always fun to see slashdot and other news sites announcing a release before the announcement is actually out ;) (http://linux.slashdot.org/story/12/03/01/2047217/ubuntu-1204-lts-precise-pangolin-beta-1-released)
<phillw> he he - is not on OMGUbuntu already? :)
<Riddell> ooh linked directly to the cdimage server, IS won't be happy
<Unit193> It hit that yesterday. ;)
<stgraber> phillw: it's too ;)
 * Riddell is tempted to sync a "hello slashdot" index.html file there for good fun
<phillw> that would be fun as they decided to another re-spin after I finally went to bed :P
<Riddell> that's crazy, that's not even the right server
<ScottK> It's on OMGUbuntu, but they at least link to r.u.c.
<Riddell> well posted to slashdot, let's see if I get any mod's up this time
 * skaet giggles at "hello slashdot" idea...
<knome> just add an .htaccess rewrite to the right place for those whose referrer is slashdot.org
<Riddell> knome: got the magic runes for that?
<highvoltage> "Sorry slashdot, but the princess is in another castle!"
<knome> let me check, i have something like that somewhere
<knome> Riddell, http://paste.ubuntu.com/864204/ <- something along the lines of that
<Riddell> that'll be for apache config which i can't do
<Riddell> dunno if it's set up for RewriteEngine to be turned on in .htaccess, probbably not
<knome> well, as i said, .htaccess...
<knome> what *can* you access? php?
<Riddell> skaet: should I try?
<knome> Riddell, actually, you want line 4 to end with: ^http://(.*)slashdot\.org(.*) [NC]
<skaet> Riddell,   if you can help with the redirect at this point,  might be nice.   kinda sucky they got the wrong link.
<knome> Riddell, and error code prolly 302 (temp redirect) rather than 403 (forbidden)
<knome> Riddell, updated: http://paste.ubuntu.com/864208/
<Riddell> it worked :)
<Riddell> http://linux.slashdot.org/story/12/03/01/2047217/ubuntu-1204-lts-precise-pangolin-beta-1-released  go follow the link
<knome> good
<knome> well now it says not following properly
<Riddell> hmm
<knome> you should add a rewritecond to only affect the index file
<Riddell> well it was working
 * Riddell changes back to 403
<knome> weird, if it's that :)
<knome> ah, right
<knome> yeah, now you just get the forbidden msg, you're not redirected anywhere
<Riddell> hmm, what did I change?
<knome> if you use 302, you should have a rewritecond that allows them seeing slashdot.html :)
<knome> nothing, it just how apache works
<knome> with 403, it's not going to try to redirect
<knome> with 302, it is, and because slashdot.html is also going to be redirected to the same address, it becomes an indefinite loop
<balloons> Riddell, i see your already having to answer the kids on slashdot
<balloons> :-)
<knome> RewriteCond %{REQUEST_URI} index.php
<knome> i suppose..
<knome> or maybe index.php$ :)
 * knome is off. good luck with that :)
<Riddell> ok fixed by moving it to http://people.canonical.com/~jriddell/slashdot.html
<balloons> ugh.. Riddell omg has it out as released also
<balloons> http://www.omgubuntu.co.uk/2012/03/ubuntu-12-04-beta-1-released/
<stgraber> Riddell: your link to ubuntu-announce points to ubuntu-release instead
<stgraber> balloons: yeah, it was mentioned earlier but omg points to the right server at least
<Riddell> stgraber: fixed
<Riddell> I wonder if I sould do similar for omgubuntu
<Riddell> or would that just be immature?
<ScottK> Riddell: Redirect them at each other.
<balloons> ScottK, +1
<Riddell> :)
 * skaet hits send,  announce should be coming out after it gets through the checks...
<Laney> nice
<phillw> Riddell: I could not mention any "news" groups by name... but I just posted https://www.facebook.com/groups/lubuntu.official/
<skaet> Riddell,  want to do the banner honors in #ubuntu-devel?
<stgraber> skaet: can I mark beta1 as released on the ISO tracker and re-enable daily?
<Riddell> skaet: mm I don't know if I have the privilages
<skaet> stgraber, yes please.
<Riddell> 22:26 -ChanServ(ChanServ@services.)- You are not authorized to perform this operation.
<skaet> Riddell,  okie.  just wanted to give you the chance.   if you could.    Thanks for steering the bits out sucessfully. :)
<stgraber> jibel: I'll remove the Edubuntu LTS-to-LTS upgrade testcase as 10.04 wasn't an LTS for us so 10.04 -> 12.04 isn't a supported upgrade path for Edubuntu
<skaet> And thanks slangasek, stgraber, jibel, pitti for your help yesterday and today,  very glad we were able to get that respin.  Nice work indeed.
 * Riddell updates http://people.canonical.com/~jriddell/slashdot.html
<slangasek> skaet: n/p
<stgraber> skaet: and thanks to you too!
<phillw> It was a pretty awesome achievement all round. A big thank-you to everyone from the lubuntu team, we were really struggling - yet the rabbit was produced out of the magicians hat and we have a working beta 1 --- Brilliant work.
<knome> night everybody!
<skaet> Thanks phillw and lubuntu team - nice work indeed.
<skaet> Thanks for staying up late knome and those last edits.  :)
<micahg> stgraber: are your LTS -> LTS upgrade tests published anywhere? (I'm curious about Xubuntu)
<phillw> I guess our payback is that GTK is now recognised as a bug & is being worked on. Scary, very scary for us to be faced with that issue.
<stgraber> micahg: I'm not running any yet because it'd take way too long to run them
<stgraber> micahg: I might be able to if I stop running both i386 and amd64 or if I move to a faster machine
 * GrueMaster returns to his previously scheduled programming.  
 * micahg wonders what's on the GrueMaster channel
<GrueMaster> work.  Lots of work.
 * skaet goes to edit the TechnicalOverview some more - Mythbuntu does have an issue... 
<Daviey> oh?
<Riddell> Daviey: it doesn't exist
<Riddell> might be a release notable issue :)
<Daviey> Minor quibble!
<skaet> Daviey,  they got stung by the same thing that hit lubuntu,  but we didn't have time to respin when they noticed it.   :(
<skaet> https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/943682
<ubot2`> Launchpad bug 943682 in gtk+3.0 "gtk3 draws black backgrounds with unico themes" [High,Confirmed]
<phillw> it was suspected that Mythbuntu would be hit. Any *buntu using GTK would be affected.
 * Riddell invites everyone over to the shiny Qt side of the room </troll>
<phillw> skaet: that bug needs renaming as it has been stated that it is a pure GTK bug, not a Unico one.
<skaet> phillw,  please edit if you can.  If not,  let me know and I'll take a pass.   Be good if you put your comments about the scope of this too.  possible?  :)
 * skaet fighting with the *slow* wiki right now.
<phillw> mutters quietly as to how they managed to get GTK to not accept hex colours ;)
<phillw> I can add on what rafael said, I forwarded his email to ubuntu-qa. that is the most recent information I have from someone who actually understands the problem :)
<superm1> phillw: that's what the problem actually is?  GTK's color parser can't figure out hex now?
<seb128> that bug is not a gtk bug
<seb128> it's a theme bug
<seb128> light-themes got fixed, whatever theme you guys need fixing as well
<seb128> gtk improved their css spec compat and that require updates in the themes css to handle it correctly
<seb128> you guys "use"*
<phillw> superm1: that was one of the comments that was raised, I'm not au-fait (familiar) with GTK etc.
<phillw> seb128: the GTK people see it as a bug. Rafael has been in touch with the devs of both GTK and Unico.
<seb128> weird
<seb128> I would be surprised
<seb128> especially that neither adwaita nor light-themes have that issue
<phillw> seb128: you would be better chatting to Rafael, all I know is that it has affected multiple version of debian based distros and without any checks for possible regressions.
<seb128> well I don't need to check anything, I've no issue, I was just giving some infos
<seb128> if you wait on gtk you can wait for long
<seb128> your theme need to be updated
<seb128> dunno who Rafael is but tell him that having his infos about what is the issue with gtk on the bug would help to get it solved
<seb128> it's not tracked properly enough to be resolved as it
<phillw> seb128: http://pastebin.com/mVzrRsF2
<phillw> seb128: you are more than welcome to chat to Rafael.... rafaellaguna@ubuntu.com
<phillw> It is way beyiond my limited knowledge.
<seb128> phillw, when was that discussion?
<seb128> phillw, well in any case as said before why should I contact anyone, I've no issue
<phillw> in the last 24 / 48 hours.
<seb128> phillw, I'm happy to help if somebody pings me or put details on the bug report
<seb128> but I will not get out of my way to fix others' bug, I've enough on my list
<phillw> seb128: I will go ping Rafael with your comments.
<phillw> emails are easy for me to send :)
<Laney> qwwq[B[A[B
<Laney> oops
<phillw> seb128: I've sent the contents of the chat to Rafael, hopefully he will respond shortly, but I suspect it will be tomorrow as he is a different TZ.
<phillw> as to when the other affected distros can reply? pass.
<phillw> I only have a direct link to lubuntu.
<skaet> superm1 ^
<seb128> phillw, ok
<phillw> oh, and as for not being parse hex colours? I use them all the time in my CSS
<phillw> in fact... i ONLY use hex colour codes :)
<phillw> took a few minutes for that one to sink in. sorry .. it has been a little hectic :(
<phillw> http://mgjuddltd.co.uk/conformance.php
#ubuntu-release 2012-03-02
<skaet> hmm... just spotted the crontab needed turning on.   Missed the start of the day UTC so some may need to be manually generated.
 * skaet turns on the crontab
<skaet> for daily images
<skaet> ~cdimage/.isotracker.conf now updated to "Precise Daily"
<skaet> infinity, slangasek,  if either of you are around, could you take care of: Revert changes to debian-cd/CONF.sh
<skaet> infinity,  just noticed that the mx5 image didn't get posted.   can you see if you can figure it out?
<pitti> Good morning
<pitti> Riddell: publish-image-set.py also outputs the rm -rf www.prev and cp -al commands,  so just follow those
<pitti> Riddell, skaet: congrats to beta-1, nicely done!
<slangasek> skaet: debian-cd/CONF.sh fixed; mx5 published
<Riddell> slangasek: you edited the .htaccess in cdimage.ubuntu.com/releases/precise/beta-1/ to remove the slashdot redirect?
<Riddell> why's that?
<Riddell> they are still linking to the wrong location
 * Riddell adds it back
<micahg> doko: are we not doing a second archive rebuild or has it just been deferred?
<doko> micahg, deferred
<micahg> doko: do we know until when?
<doko> micahg, likely beta2, maybe before
<micahg> ok, thanks
<mdeslaur> Hello. Could someone please grant me a FFe for a new version of my pasaffe package?  LP: #944789
<ScottK> Looking
<ScottK> mdeslaur: Done.
<nessita> hello all! can anyone confirm if this bug requires a UIFe? https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/944120
<ubot2`> Launchpad bug 944120 in ubuntuone-control-panel "Order of the buttons is wrong on the settings tab in the qt control panel for Ubuntu" [Undecided,New]
<mdeslaur> thanks ScottK :)
<ScottK> nessita: It does, but just get an ack from the docs team and it's no problem.
<nessita> ScottK: thanks, I will
<skaet> pitti,  good morning.  :)  thanks for taking care of the mx image.
<skaet> Riddell,  good afternoon - around?
<Riddell> hi skaet
<stgraber> just filed bug 944849 (so far, just want to have the proposal reviewed before I start spending time on it)
<ubot2`> Launchpad bug 944849 in isc-dhcp "[FFe] converting isc-dhcp from sysvinit to upstart" [Undecided,New] https://launchpad.net/bugs/944849
<skaet> hi Riddell,  :)   just noticed one of the images ok'd for release didn't get published,  specifically Ubuntu desktop powerpc had enough testing this time around it looks like the image is basically usable with some workarounds.
<stgraber> (use case is to make dual-stack dhcp servers and relays work)
<skaet> It belongs on: http://cdimage.ubuntu.com/releases/precise/beta-1/ page.
<Riddell> skaet: I think I did run ARCHES='powerpc' for-project ubuntu publish-release daily-live 20120228.1 desktop named beta-1
<Riddell> and it didn't do anything
<Riddell> so I assumed it was incorrect
<Riddell> skaet: shall I try again?
<skaet> interesting...  yes please try again.
<Riddell> skaet: hmm 20120228.1 is gone
<Riddell> maybe it never existed and that's why the command didn't work?
<skaet> yeah that would explain it...  but there was an image there and folks were testing...
<Riddell> skaet: it probably got moved to 20120301 with the respin
<skaet> Riddell, nope,  I explicitly didn't respin it.
<Riddell> skaet: yes the one in 20120301 has a date stamp of 20120229
<Riddell> skaet: so whatever the respin was for didn't affect powerpc?
<skaet> ahh... yeah that would explain it.
<skaet> it shouldn't have - since it was an arch specific rebuild.... ie.  took 9 minutes as opposed to 40.  :P
<Riddell> ok I'll publish 20120301
<skaet> echo ubuntu desktop && date && ARCHES="i386 amd64 amd64+mac" buildlive ubuntu daily-live && (ARCHES="i386 amd64 amd64+mac" for-project ubuntu cron.daily-live &)
<skaet> was what was run...
<Riddell> skaet: powerpc syncing
<skaet> Thanks.   :)
<skaet> see any syntax/glitches in the invocation?
<Riddell> skaet: in which invocation?
<skaet> Riddell,  ^ build invocation to do the others except powerpc.  ;)
<Riddell> skaet: the command is fine if that's what you want to achieve
<skaet> Riddell,  yeah that is what I was trying for.
 * skaet wishes she'd spotted this yesterday before turning on those dailies,  could be no more than 1 old version of the dailies cleanup kicking in too...
<Riddell> yes it will be the no more than 1 old version of the dailies cleanup
<dobey> pitti, skaet: hrmm, there isn't much discussion on -devel for my ui freeze mail :-/
<pitti> dobey: give it some time :)
<GrueMaster> pitti: I have a merge request in for flash-kernel to fix Bug 626749.
<ubot2`> Launchpad bug 626749 in flash-kernel "flash-kernel tries to use MTD devices on OMAP4 when no flash-kernel.conf exists" [Medium,In progress] https://launchpad.net/bugs/626749
<GrueMaster> Just waiting for someone with more privileges than I.
<skaet> Riddell,   what should the support period be for the armhf+omap4 image and the DVD - I had "?" because I wasn't sure if you wanted to be testing them for the point releases... some cases we didn't.
<Riddell> skaet: I assume we don't want to do updates for those
<Riddell> ScottK: agree?
<ScottK> I do.
<skaet> RIddell, ScottK,  then just put down the 18 month. :)
<ScottK> If there's some solid reason to respin them for a point release, we can (we've done it before).
<slangasek> Riddell: I didn't edit any .htaccess files directly; if one changed it was a publish-release accident
<slangasek> hey, seb128 has mentioned to me that there was a problem with the freeze queue getting flushed after the beta release
<seb128> not getting flushed rather :p
<slangasek> apparently the queue was only partially flushed, leading to packages staying in the queue overnight that were supposed to get flushed
<slangasek> I see the wiki page doesn't actually mention the need to flush the queue, so I'm fixing that
<ScottK> I started emptying it, but then was offline all evening.
<slangasek> aha
<slangasek> ScottK: so the partialness of it was a limitation of the UI?
<ScottK> Yes.
<ScottK> Right now it's 3 -5 packages at a time or you get a timeout.
<slangasek> right
<ScottK> Also I was trying to dribble them in a bit just in case there was an OMFG right after the release.
<ScottK> But that was probably me being more careful than I needed to be.
<slangasek> well, I think it's better to just get them all flushed out... and a few of us still have shell access to do that in one go without timeouts :P
<skaet> slangasek, thanks for adding it to the WIKI.
<slangasek> ScottK: so rather than feeling the need to painfully iterate the web UI, do you want to poke one of us to do the flushing?
 * skaet was under the impression that opening the archive would drain it automatically, but should have checked. :/
<seb128> just for the record the reason it's annoying is that there is a bug in the new lightdm and rather than figuring it out on friday morning we figured it out on friday end of european day
<slangasek> (though now it's on the checklist so hopefully won't require poking in the future)
<seb128> (landing a flush on friday is a bad timing to deal with potential issues)
<ScottK> Yes.  That's why I started pushing it out Thursday night.
<ScottK> slangasek: Repeatedly clicking on slow/unreliable LP pages at least lets me feel useful.
<slangasek> heh
<ScottK> Is that exposed through the LP API yet?
 * ScottK wonders
<slangasek> which part?
<ScottK> The accepting a package part
<ScottK> (i.e. can we make it so that I don't have to use the LP U/I anymore)
<slangasek> ah, no idea
<skaet> Riddell,  flavour vs. flavor - text had flavor in it, and http://www.ubuntu.com/project/about-ubuntu/derivatives has "Recognized flavors" as the title,  so am going to unify the spelling of the title of the page https://wiki.ubuntu.com/RecognizedFlavours to https://wiki.ubuntu.com/RecognizedFlavors so its all consistent.
<skaet> added redirects as well, so no matter what you type,  path to content should work.
<Riddell> thanks skaet
<skaet> Riddell,  thanks for making the change.  :)
<Riddell> of course there's a whole "derivatives team" that needs changed
<skaet> yeah I noticed that earlier...  more than a 5 minute tweak for that one.  :P
<stgraber> ouch, I stopped counting the number of places where we aren't consistent a long time ago ;)
<stgraber> the flavour vs flavor part is one issue, the derivative vs flavor is another big one that people still do wrong over and over again...
<Riddell> that's mostly because mdz insisted on using derivative for many years
<Riddell> I quite like the fedora term of "spin" but we can't go copying them :)
<micahg> Riddell: you just have to spin it the right way ;)
<Riddell> ho ho ho
<stgraber> would appreciate if someone could have a quick look at bug 945236 (I currently have upstream sitting next to me ;))
<ubot2`> Launchpad bug 945236 in babeltrace "[FFe] new upstream version (1.0.0~pre3) renaming some binary packages" [Undecided,New] https://launchpad.net/bugs/945236
<skaet> stgraber,  approved, as long as lands prior to March 15th.
 * skaet has inserted comment into bug.
<stgraber> skaet: I'll upload in the next 30s ;)
<skaet> :)
#ubuntu-release 2012-03-03
 * skaet --> EOW, TGIF.
<ogasawara> when an archive admin has a moment, could I get the linux-backports-modules-3.2.0-18.1 package approved in the New queue.  Also, it needs to be promoted to main.
<infinity> ogasawara: Done.
<infinity> ogasawara: Why do we get no LBM love for ports kernels, out of curiosity?  You'd think compat-wireless could prove equally useful on ppc/arm?
#ubuntu-release 2012-03-04
<broder> is the current opinion that multiarchification requires an FFe?
<ScottK> broder: Yes.
#ubuntu-release 2013-02-25
 * cjwatson lands a rewrite of some more of cdimage in Python, this time build-image-set and friends (just in case anyone notices weird failures)
 * ogra_ will only touch find-live-filesystem later today 
<cjwatson> ogra_: I think I should go and do some other things now, so you're good
<ogra_> no hurry, seems i need to do it manually once more anyway
<xnox> ogra_: I'm ready with ac100-tarball-installer changes to copy wifi configs if present in the preseed, which will go together with matching upstart reboot upload, which together will make unattended reflash cycle possible.
<ogra_> xnox, yay, go ahead :)
<xnox> thanks.
<xnox> ogra_: everything uploaded \o/
<ogra_> xnox, i hope you made sure that the reboot hack only appears on arm :)
<xnox> ogra_: there is no hack.
<ogra_> not that people accidentially eun it on x86 :)
<ogra_> *run
<ogra_> oh ? i thought you needed to hack "reboot" for that
<xnox> ogra_: reboot syscall supports rebootcommand on all arches. And you need to specify --force to trigger it anyway, which is a good enough safeguard.
<ogra_> ah, nice, i wasnt aware !
<xnox> ogra_: i had to hack reboot(8) but not reboot(2) =)
<ogra_> hehe
<xnox> one has to use a syscall though, as glibc wraps reboot in a way that one cannot pass that extra / optional rebootcmd string.
<cjwatson> Does anyone still have a system around for which update-manager is showing a partial upgrade due to libreoffice-presenter-console?
<cjwatson> If so you might save me from having to construct a system test environment :-)
<antarus> cjwatson: curious, what are you using as your VM solution?
<stgraber> cjwatson: I might have one, checking. (I have a few 13.04 VMs I haven't updated in a while)
<cjwatson> antarus: kvm
<stgraber> cjwatson: I think I have a reproducer. Let me confirm that update-manager agrees
<stgraber> cjwatson: yep, confirmed, I get a partial upgrade dialog from update-manager
<cjwatson> stgraber: Great.  Does http://paste.ubuntu.com/5565209/ help?
<stgraber> cjwatson: testing
<stgraber> cjwatson: so it appears to work, I'm just surprised by the wording of the upgrader "Updated software has been issued since Ubuntu 13.04 was released." but that's not something you changed.
<stgraber> Running an actual upgrade now to confirm it works.
<stgraber> cjwatson: worked. The presenter package was removed and the rest was updated.
<cjwatson> Great, I'll land that then, thanks
<infinity> stgraber: Hrm.  Looks like someone committed something to upstart that makes your daily builds hang on the buildds.
<xnox> gasp, was that me?! or is the gcc4.7 revert reverted back
<stgraber> infinity: gah, not again... I'll take a look.
<stgraber> last time it was gcc-4.7 but I can't remember doko telling me he'd reintroduced the change that caused it
<infinity> stgraber: Currently hung on sagari, aatxe, allspice, and centaur.
<xnox> my build is hanging https://launchpad.net/ubuntu/+source/upstart/1.6.1-1ubuntu3/+build/4326128 =/
<xnox> which is for the primary archive.
<xnox> infinity: add nasl to the list.
<xnox> it did pass on other arches though =/
<infinity> xnox: Which "other" arches?
<infinity> xnox: I just named all of them.
<infinity> xnox: There's a daily hung on every arch.
 * xnox is talking about 3/4 successes of this build https://launchpad.net/ubuntu/+source/upstart/1.6.1-1ubuntu3 with armhf hanging.
<xnox> in addition to the daily build.
<infinity> Ahh.  Pure luck, I guess. :/
 * xnox ponders if my armhf is the arm cosmic rays that got fixed in trunk, but not backported to 1.6x series.
<infinity> Well, can't speak to the armhf/release one, but the trunk build issues should be readily reproducible, given that it did the same thing on 4 arches.
<stgraber> I'm doing a test build here
<stgraber> I never test built with xnox's change, but trunk right before that was definitely buildable as that's what I used for my last PPA upload
<infinity> It's possible doko inadvertently reverted something.  What was the symptom of the last problem?
<infinity> This one was a bunch of hung /build/buildd/upstart-1.6.1+1436+1423+201302251008~raring1/util/../init/init --session --no-startup-ev
 * xnox thought gcc issue was causing ICE
<stgraber> reproduced here, reverting to last known good trunk
<xnox> not "gcc issue" per se but an issues between upstart and new gcc4.7, which we are now blaming upstart's overuse of __malloc__
<stgraber> xnox: 1434 builds, 1435 doesn't (doing another test to confirm)
<stgraber> xnox: so your change isn't the problem as it's 1436
 * xnox relaxes a little =)
<infinity> stgraber: Definitely not seeing the hang in 1435?  That's comforting.
<infinity> Err, 1434.
<stgraber> infinity: right, 1434 is fine, 1435 appears to be the problem and the merge that happened between the two was environment related
<stgraber> so it's not a toolchain problem, it's a merge that was done with some additional changes to what I actually tested and that wasn't test built properly before merging (or so is my guess)
<stgraber> 1435 is:
<stgraber>   * Merge of lp:~jamesodhunt/upstart/upstart-no-inherit-env.
<infinity> Yeah, I've looked at the diff.
<stgraber> oh, actually, I never tried that specific branch, just did a code review on LP. Not sure if anyone actually did a testbuild with it... (everything suggests that didn't happen)
 * infinity considers it pretty bad form to just tear out old arguments and replace them, but...
<xnox> infinity: i don't think they were ever releases, or have they?
<xnox> s/releases/released/
<stgraber> infinity: well, we never released with the old argument, so only people using from trunk may be confused.
<infinity> Oh, if this is all new code anyway, no big deal.
<stgraber> yep, confirmed it's the problem. Currently in a couple of meetings, will fix that right after I'm done.
<infinity> Though, I also like the autotools and GCC way of every --foo having a --no-foo inverse, for boolean options like this.  So one could have had both. :P
<stgraber> infinity: did you already kill all the affected builds?
<infinity> stgraber: Yeah, they're all cleaned up.  As long as no one triggers new ones.
<stgraber> ok, good. I'll do a quick check for virt ones as we have a few autobuilds there too...
 * xnox is all good. armhf cosmic rays.
<stgraber> infinity: did you miss that one? https://launchpad.net/~canonical-foundations/+archive/upstart-daily/+build/4325548
 * stgraber just cancelled a couple of virt ones
<infinity> stgraber: No, that's new. :/
<infinity> stgraber: Note it's only 33m old.
 * infinity wonders if someone restarted one of the killed ones.
<infinity> Oh, bother.  Being removed from ~canonical-foundations means I can't screw with your PPA.
<infinity> stgraber: Want to just delete that upstart source from the PPA entirely, so no one's tempted to retry it again?
<stgraber> infinity: done
<infinity> stgraber: Thanks.
<stgraber> xnox, infinity: found the problem, sent a merge proposal
#ubuntu-release 2013-02-26
<phillw> hi good people, with reference to bug 1098080 has an SRU request been made? We confirm it works in raring.
<ubot2> Launchpad bug 1098080 in testdrive (Ubuntu) "Testdrive gets stuck on "configuring Virtual Machine" if Virtualbox 4.2 is installed" [Undecided,Fix released] https://launchpad.net/bugs/1098080
<cjohnston> phillw: it does not look like an SRU request has been made
<phillw> cjohnston: thanks, should I go ask https://launchpad.net/~bkerensa to make this? I'm not 100% sure on SRU things, but have managed to get one through (with a lot of help) :)
<infinity> phillw: Anyone can propose it for other series', but if you do, you should also fill out the usual SRU boilerplate in the bug description and justify it.
<infinity> phillw: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<phillw> infinity: thanks, you read my mind... I do recall being sent that link before. I'm sorry to be a slow learner on this stuff and am very grateful for all the help you guys give in pointing me to the correct areas to head for :)
<infinity> phillw: Googling for "ubuntu SRU" brings that up on the first hit, FWIW.
<phillw> infinity: am I any where close on getting the description updated?
<infinity> phillw: Test cases should be instructions that people who aren't you can follow.
<infinity> phillw: Or, more importantly, people who aren't familiar with what "Using Testdrive to gain an iso and launching it using Virtualbox will work." means.  How do I do any of that, and what does "working" versus "not working" look like?
<phillw> Hmm, well, this should be fun :) ... I'm just going to track down Jacksons' classroom session on using testdrive for how to install it all and get iso's :)
<phillw> infinity: am I allowed to use
<phillw> sudo apt-get
<phillw> ?
<infinity> phillw: Of course.
<infinity> phillw: This isn't meant to be an exercise in weird constraints or anything, just "if you gave me these steps, I could make the bug happen".
<infinity> If the bug was "when I hit my laptop with a hammer, the screen stops working", the steps would be "obtain hammer, apply liberally to laptop, observe".
<phillw> infinity: it is not taken as. I've been told off by pleia2 for overly assuming things when I was writing up stuff for the classroom sessions earlier this month :)
<phillw> just, I've got basic knowledge of Testdrive, so it will take a little while as I battle how to remove virtualbox 4.1 (in the repos) and add in 4.2 (not in the repos, but what people use).
<phillw> I'm not even sure where to start with getting 4.2 into the repos!
<infinity> Sure, but someone's going to need to reproduce and verify the bug is fixed, so either you need to know how so you can do it yourself, or you need to know how so you can get others to do it.
<infinity> We're not going to get 4.2 in older releases, period.
<pleia2> I don't tell people off :(
<infinity> Getting it in raring probably means getting it in Debian.
<infinity> pleia2: Maybe you should start. ;)
<pleia2> I really was trying to be helpful to improve documentation for newcomers
<phillw> infinity: 4.2 into older releases is not a requirement. Into 13.04 would be nice.
<phillw> pleia2: I was joking! I simply said that I have been asked to explain more clearly once, or twice, before :D
<pleia2> ok :)
<phillw> infinity: I just used https://www.virtualbox.org/wiki/Linux_Downloads to grab the 12.10 version, GDebi did the rest once I had un-installed 4.1 from the system. Not really sure what is going on here, but that is not the issue with the bug and SRU request.
<phillw> infinity: do the current (12.10) *buntus have Synaptic Package Manager?
<infinity> Probably not installed by default.  You don't need to give EXACT instructions "install this package" is enough.
<phillw> infinity: I need to have 4.1 uninstalled as GDebi will not install 4.2 if it is there :'(
<phillw> Is it sufficient to state 'completely remove VBox 4.1, e.g. via Synaptic Package Manager' ?
<phillw> is apt-get --purge remove virtualbox-4.1* okay?
<phillw> infinity micahg: sorry for keep bothering you, does https://bugs.launchpad.net/ubuntu/+source/testdrive/+bug/1098080 look reproducable?
<ubot2> Launchpad bug 1098080 in testdrive "Testdrive gets stuck on "configuring Virtual Machine" if Virtualbox 4.2 is installed" [Undecided,Fix released]
<micahg> phillw: makes sense, I proposed a similar fix a while back for another version
<phillw> micahg: can I now go hunt down a bug supervisor to mark it up?
<phillw> s/can/should/
<infinity> phillw: I already did.
<phillw> infinity: ahh, thanks.. I was desperately trying not to ping you guys too much :/
<phillw> I guess you guys have had the 'one line change before' SRU request. --> "It's just a one-line change!" Rest assured, if accepted to proposed, it will be tested within the 7 day window. As well as the bug report, there is chatter on the quality mailing list about it. fingers crossed, it will not break anything. My only concern would be the other things that got added into the new release, but I'm sure you people know what you're doing :)
<phillw> infinity: on a slightly different note, as it is more wiki based. It seems that apturl is not installed by default on lubuntu and Chromium cannot use it any ways. Is apturl 'generally' installed or should the wiki people be changing the likes of https://help.ubuntu.com/community/RestrictedFormats#Easy_Install to https://help.ubuntu.com/community/RestrictedFormats#Manual_Install I *know* this is not a release team issue, but if the quick links v
<phillw> users at 13.04 will be scratchign their heads.
<phillw> I ask informally before I ask people to start raising bugs.
<infinity> phillw: And why can't apturl be made to work with chromium-browser?
<infinity> phillw: That would be the correct answer, IMO.
<phillw> infinity: I 100% agree, however https://code.google.com/p/chromium/issues/detail?id=152400 is a an unloved bug.
<phillw> -a
<infinity> phillw: I see no reason this needs to be fixed in chrome/chromium.  Writing an extension to handle apt: URLs should be fairly trivial.
<infinity> phillw: As in, this should be the responsibility of flavors who want to use chromium by default, not upstream.
<phillw> there is an extension. https://chrome.google.com/webstore/detail/apt-linker/oljmaangfgmmokjpnojhfblppgeijikp?hl=en
<infinity> Yeah, I already stumbled on that, it looks incomplete and a bit broken.
<infinity> Plus scary, in that it parses random text in web pages, instead of well-formed apturl lines.
<infinity> Installing that by default would be pretty not okay, IMO.
<phillw> the other side to it, is apturl installed by default? On my firefox install in lubuntu I had to install apturl. So, I'm not sure how lubuntu / Chromium specific the problem is.
<infinity> My gut feeling is that writing an extention that just farms apt: links off to software-center wholesale would probably take someone about 10 minutes.
<infinity> (base)adconrad@cthulhu:~$ apt-cache show apturl | grep ^Task
<infinity> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb, lubuntu-desktop
<infinity> Looks default to me.
<infinity> With the notable exception of xubuntu...
<infinity> Oh, and kubuntu.
<phillw> Hmm, okies, I have a replacement usb drive ordered so I can move from virtual machines to having a 'real' machine without risk of messing up my production machine.
<phillw> but, if apturl is missing from kubuntu and xubuntu maybe I should suggest dropping it from wiki pages and using the sudo apt-get xyz ?
<infinity> kubuntu may do something different entirely.
<infinity> and with xubuntu, it's likely an oversight.
<phillw> infinity: there is another proposed way round, using http://appnr.com/ but I'm not familiar with that site?
<phillw> I found that via http://www.neowin.net/forum/topic/951076-ubuntu-how-to-use-apturl-anywhere/
<phillw> as they are both 'off area', I'm minded to think that we just use sudo apt-get xyz
<phillw> For ubuntu and the default browser, which I assume works fine. for the other flavors they need to sort out this issue for themselves?
<infinity> I have no problems with people giving both an apturl link, and manual instructions, but I think we should be trying to default to apturl type stuff, and flavours should be making that work, ideally.
<infinity> Given that you can feed an apturl URL *directly* to software-center and it does the right thing, integrating that into a flavour's browser should be trivial.
<infinity> The browser/extension needs to know nothing about how to parse them, just that it needs to spew it to SC and let it do the work.
<phillw> maybe the chromium bug needs a bit of 'heat' :D
<phillw> oh, and what software center?
<phillw> in firefox, I'm told the apturl for lubuntu restricted extras is already there, If I select xubuntu it asks if I want to install it. what database is apturl using? I'm assuming it is checking up on the apt-get database?
<phillw> Well, I've troubled / distracted you more than enough. As always, thank you for your patience with me. as it now 05:03 here, I had better get into my alclove for my regeneration cycle :)
 * cjwatson clears a stuck semaphore that meant that the cdimage mirror wasn't getting updated
<cjwatson> Now, what's up with these weird Lubuntu preinstalled build failures
<ogra_> theer are build failures ?
<ogra_> oh, evo crashed once again ... thats why i didnt check my mails yet :P
<ogra_> looks like a stale lock on the builder
<ogra_> cjwatson, oh, there is bug 1133213
<ubot2> Launchpad bug 1133213 in Ubuntu CD Images "cdimage/bin not in PATH of subprocess.check_call" [Undecided,New] https://launchpad.net/bugs/1133213
<ogra_> (awesome that someone uses cdimage out of the DC !)
<cjwatson> I'll sort it out, thanks
<cjwatson> ah, phew, lubuntu/daily-preinstalled build is behaving itself now
<cjwatson> next, look for chaos caused by this
<cjwatson> I've also fixed the bug that led to locks/semaphores not being cleaned up properly on Ctrl-C
<cjwatson> And I think that's pretty much everything cleaned up now.  There might still be some oddities caused by a stale mirror, but those should sort themselves out tomorrow at the latest.
<xnox> all sorted way before nexus7 images are croned =) so when it spins today, it should everything i hope for it to hate ;-)
<xnox> s/hate/have/
 * xnox failed at english.
<Laney> not like you!
<ogra_> cjwatson, phablet syncs -> lool works on getting the android builds happening in the cdimage area, after that (and after all packages are in raring) we will start to roll the userspace with live-build ... since none of that is there and i would have to hack up a lot in cdimage for an interim jenkins sync solution i decided to go with a simple sync script for now (currently outside of the cdimage tree, running under my own crontab on nu
<ogra_> sakan), are you ok with that ?
<dobey> hey all. can someone accept tomboy upload into precise-proposed ?
<cjwatson> ogra_: It's OK as a strictly temporary measure, but could you please run it as the cdimage user instead?
<cjwatson> Just in case anyone else needs to apply emergency fixes when you're on leave or something
<ogra_> cjwatson,
<ogra_> ogra@nusakan:~$ crontab -l|grep sync
<ogra_> 35 * * * * sudo -u cdimage -i /home/ogra/sync-phablet-images
<ogra_> already doing, else i would get permission issues writing to www and log
<cjwatson> Ah
<cjwatson> Grotty, but OK
<ogra_> heh
<cjwatson> It would be clearer to just edit cdimage's crontab for the time being
<cjwatson> (not in bzr, just live)
<ogra_> yeah, i might do that
 * ogra_ does so
<ogra_> doing these builds on our side will require some painful changes (images are a mixture of armel and armhf and have a bunch of different subarches as well as three "subimages" per subarch etc etc)
<lool> ogra_: I am not directly working on getting android builds happening on cdimage
<lool> ogra_: I did propose various options, but I think rsalveti, Sergio and perhaps me need to think of the more concrete steps that are ahead for some bits
<ogra_> lool, huh ? you said you wanted to take that task when i said i was planning to work on it
<lool> ?
<ogra_> when we spoke last week
<ogra_> well, chatted
<lool> ogra_: You mean moving the mwc-demo dir around?
<ogra_> lool, well, in the end someone will have to do it ... i'm fine doing it, but understood you wanted to
<ogra_> lool, before the moving stuff iirc
<lool> ogra_: I don't even know exactly what you're talking about!
<lool> I remember offering to move stuff around the day of the release
<ogra_> lool, building phablet images on cdimage
<lool> Yeah, I don't recall offering that and there are many subtasks to complete around that that Sergio and/or rsalveti are in a better place to handle
<ogra_> i told you that i'm tasked with that and you asked if you could do the android side
<lool> like finishing the patches to the build scripts to use the new LP project names
<ogra_> (which i appreciated)
<lool> ogra_: I tried to grep my logs, and I can't find that; either I said and don't recall it (pointers appreciated), or someone else promised that, or we misunderstood each other
<ogra_> hmpf, and i chatted from my chromebook which doesnt log
<ogra_> grep for TODO
<ogra_> i'm pretty sure i said its on my TODO
<ogra_> or for "tasked"
<lool> 16:26 < rsalveti> lool: I got it ported to a recent livebuild at https://code.launchpad.net/~rocket-scientists/aal+/ubuntu-build-phablet
<lool> 16:26 < ogra> sergiusens, but i had it on my TODO for later
<lool> [...]
<lool> 16:27 < lool> sergiusens, rsalveti: see also email I've sent earlier today on this (lol, like you guys can read email today)
<lool> 16:27 < ogra> if lool does it i'm fine with that
<lool> I never said I would!
<ogra_> heh, ok
<lool> ogra_: sent you the log
<ogra_> well, seems there is a lot of stuff to be sorted out before it can happen anyway
<ogra_> so lets talk again once its ready :)
<lool> in the context, rsalveti offers to finish porting of the live-build to new branch names
<lool> ogra_: So much is happening that you made me doubt I had promised something and had completely forgotten about it
 * lool is relieved now
<ogra_> heh, sorry
<ogra_> lool, btw, do we already have a kernel upgrade plan for these images ?
<ogra_> (or android system upgrade plan since i think thats one blob)
<rsalveti> lool: ogra_: I'd vote to just port when we start having the raring based image
<rsalveti> which will happen soon I believe
<ogra_> rsalveti, heh, well, we need all the UI bits in the archive first
<rsalveti> ogra_: "soon" :-)
<ogra_> :)
<rsalveti> unless we *really* want to run lb at cdimage *now*
<ogra_> on cdimage ?
<ogra_> we usually dont do that
<rsalveti> not cdimage
 * rsalveti just woke up
<ogra_> k
<ogra_> do you do cross builds or native ?
<ogra_> (i assume cross)
<rsalveti> ogra_: the ubuntu lb runs natively with armhf builders at offspring
<lool> rsalveti: +1
<rsalveti> just the android part that is cross
<ogra_> thats what i mean
<ogra_> ubuntu userspace is clear to me already
<ogra_> and shouldnt need more than a specific seed
<ogra_> but we need the android side from somewhere ... and preferably properly integraded in cdimage
<rsalveti> yeah
<rsalveti> ogra_: do you think it'd be a problem to keep it running at jenkins?
<ogra_> apart from the fact that its ugly to not build them in the common system we use for all images ?
<ogra_> dunno, it would be good if we could just actually run the builds with the common commands and scripts
<ogra_> having the images scattered across miltiple datacenters doesnt seem sane to me in the long term
<ogra_> *multiple
<ogra_> and even then, cdimage must be able to trigger builds etc at release times so we would definitely need to integrate jenkins with it to be able to run builds etc, i'm not sure if its clever to do that on a system where the cdimage team has no control
<ogra_> dunno what other cdimage team members think about it
<cjwatson> By an order of magnitude, I'd prefer being able to run it in our usual configuration - that is, ssh to a machine with an ssh trigger set up to run BuildLiveCD
<ogra_> yeah
<cjwatson> If it's already based on live-build this shouldn't be that hard
<ogra_> same for me
<cjwatson> And it will be way easier to integrate than having to invent something to deal with jenkins
<ogra_> well, not sure about the cross built android bits
<ogra_> i guess that would need to be run from some cdimage command on the x86 builder
<ogra_> for the ubuntu userspace live-build already has what we need, the android parts are buiolt from a git tree though, we would need something that handles this
<cjwatson> Sounds like those could reasonably be separate-ish build jobs which we than collate
<ogra_> well, but we would have to be able to trigger them as well
<cjwatson> Yeah
<rsalveti> cjwatson: ogra_: sure, we'll get there, was more concerned about the timeframe for it
<rsalveti> I'd suggest the full migration to be part of the quantal -> transition
<rsalveti> *-> raring
<ogra_> yeah
<lool> rsalveti: (sorry for putting you on the spot here!)
<lool> rsalveti: Yes; I think it makes sense to get the livefs builds working on raring on developer machines, then look at scheduling builds on livefs builders; I don't think we need to use jenkins for that, but I definitely think we ought to use jenkins for the android cross-builds for now
<lool> rsalveti: I was also thinking we could look at building some parts of the phablet images relatively soon for raring such as boot.img
<rsalveti> lool: these android specific parts are not depending on the ubuntu series
<rsalveti> lool: ogra_: and when I say we should worry about this during raring transition is that I know we still have a lot to come even from the architecture perspective
<rsalveti> like if we're able to make ubuntu as the main host, then the way we're building the android part will change completely
<lool> Yeah
<rsalveti> we might not even need jenkins/etc
<lool> There are some interdependencies between Ubuntu and Android changes too for now
<ogra_> i guess there will always be
<lool> So I'd wish for some way to track which Android bits we combine with which Ubuntu raring bits fairly closely
<ogra_> and thus i think its even essential that both come out of the same build infrastructure
<lool> Yup; eventually they should
<rsalveti> sure
<ogra_> and i agree that we dont need jenkins for that in the long term
<lool> rsalveti: So you're the one currently porting the lb configs to the public branches and to raring?  Didier mentioned a list of branches he had published, but I'm not sure how to track progress of the raring merge/rebase of the phablet packages
<ogra_> we should just have a cross build machine where cdimage can trigger the builds via ssh ... as cjwatson descrived above ...
<ogra_> largely how we use live-build today but well, wirh a make command on the other end
<lool> I think cjwatson meant the livefs builds; not sure about the cross-built bits
<lool> but indeed, I guess we could use livefs x86 builders for that; not a bad idea
<rsalveti> lool: yup, we'll be discussing and coming to a better plan about the transition this week
<rsalveti> there are still a lot to packages to port to raring
<ogra_> right, and have something like live-cross ... that builds the three android images
<ogra_> yeah
<rsalveti> and the unity* ones are kind of a concern
<ogra_> no hurry yet
<rsalveti> yup, lot of fun ahead :-)
<ogra_> but we should have a UDS discussion and blueprint imho
<ogra_> to plan that properly
<lool> rsalveti: Ack; sounds all good -- and fun  :-)
<ogra_> rsalveti, the other thing spinning in my head are upgrades of the android side ... do you already have plans for that ?
<ogra_> i assume we'll just mount recovery and dump the zip in and reboot or some such
<rsalveti> ogra_: yup
<rsalveti> ogra_: that will come this/next week
<ogra_> great
<rsalveti> ogra_: as you see, all to be investigated/discussed still :-)
<ogra_> yeah
<ogra_> thats the exciting bit :)
<rsalveti> yeah :-)
<rsalveti> new stuff, everybody is excited :-)
<rsalveti> which is good
<ogra_> yup, and we even win prizes with a half way done system :)
<ogra_> thats so awesome
<rsalveti> ogra_: yeah :-)
<lool> ogra_: I see a new image was pushed today; would you be tempted to send an udpate to phablet-tools to point at it?
<lool> ogra_: a mp against lp:phablet-tools, and then check how to land it in Ubuntu
<ogra_> lool, i think sergio just did
<lool> cool
<ogra_> should have a switch to use dailies
<lool> uploaded as well?
<ogra_> duno, i just saw rsalveti signing it off
<ogra_> so it will be soon, if it isnt yet
<rsalveti> lool: ogra_: CI should publish the package automatically soon
<rsalveti> the branch was merged
<ogra_> great
<lool> rsalveti: awesome, so which jenkins is this?
<dobey> any archive admin around? if so can someone please approve https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=tomboy
<infinity> dobey: Changing the bug task to fix committed made it somewhat difficult to notice that one series wasn't.
<cjwatson> dobey: done
<cjwatson> And yes, agreed with infinity, DDT please
<dobey> sorry. i didn't realize it wasn't approved then. pitti had marked the merge proposal 'merged' which suggested it was, and i noticed that it wasn't fix committed on the bug.
<cjwatson> ogra_: is that kubuntu-active build failure just now you working on nusakan, or is it my breakage?
<cjwatson> cardamom's the i386 builder so I'm going to guess it's my fault :-(
<cjwatson> oh, no, kubuntu-active defaults to i386
<cjwatson> except why are preinstalled builds enabled for it ...
<cjwatson> I guess somebody must be working manually
<infinity> Sounds like Oli, yes. :P
<ogra_> cjwatson, that was a manual test build
<ogra_> i didnt make any code changes or anything, just tried a build with ARCHES set to see what happens
<ogra_> sorry if that caused confusion
<ogra_> i didnt get any build failure mail :/
<ogra_> oh, full disk ... hmm
<ogra_> and there it is
<ogra_> urgh
<ogra_> cjwatson, hmm, so i used "ARCHES=armhf+nexus7 for-project kubuntu-active cron.daily-preinstalled", looking at livefs.py i dont see how it could pick the x86 livefs builder instead of celbalrai.buildd
<ogra_> ogra@nusakan:~$ PROJECT=kubuntu-active /srv/cdimage.ubuntu.com/bin/find-live-filesystem armhf+nexus7 rootfs.tar.gz
<ogra_> sh: 49: /srv/cdimage.ubuntu.com/etc/config: default-arches: not found
<ogra_> http://celbalrai.buildd/~buildd/LiveCD/raring/kubuntu-active-nexus7/current/livecd.kubuntu-active-nexus7.rootfs.tar.gz
<ogra_> hmm, that looks okayish too
 * ogra_ doesnt see where the error could be ...
<ogra_> Riddell, som the livefs build succeeded ... but i cant convince buildlive to accept armhf+nexus7 for it in teh right way ... i'll go on inspecting that tomorrow
<ogra_> err
<ogra_> s/buildlive/for-project/
<Riddell> ogra_: thanks, probably some confusion about what it image name and what is image type
<infinity> ogra_: Don't you mean ARCH=, not ARCHES=?cdimage@nusakan:~$ default-arches kubuntu-active daily-preinstalled raring
<infinity> i386
<infinity> Err.
<infinity> TYPING FAIl.
<infinity> cdimage@nusakan:~$ default-arches kubuntu-active daily-preinstalled raring
<infinity> i386
<ogra_> well, i looked through all the code and ran each bit individually, they all seem to DTRT
<ogra_> cdimage@nusakan:~$ ARCHES=armhf+nexus7 buildlive kubuntu-active daily-preinstalled && ARCHES=armhf+nexus7 for-project kubuntu-active cron.daily-preinstalled
<ogra_> kubuntu-active-armhf-nexus7 on celbalrai.buildd starting at 2013-02-26 16:55:03
<ogra_> kubuntu-active-armhf-nexus7 on celbalrai.buildd finished at 2013-02-26 18:30:18 (success)
<ogra_> You have new mail in /var/mail/cdimage
<infinity> ogra_: You have no daily-preinstalled for kubuntu-active in etc/default-arches
<ogra_> infinity, why did the buildlive command DTRT then (and yeah, emabrrasing))
<ogra_> (or if i could type ...)
<ogra_> infinity, yes, on purpose since i wanted to set ARCH manually (which i obviously failed :P )
<infinity> 'ARCHES=armhf+nexus7 for-project kubuntu-active cron.daily-preinstalled' seems to work here...
<ogra_> yeah, i just clashed with you
<ogra_> sacry errors that throws
<ogra_> *scary too
<ogra_> infinity, well, your command only does a mirror sync up to now
<ogra_> ah, and failed the same way
 * ogra_ tries with ARCH
<infinity> No, I was wrong about ARCH.
<ogra_> oh
<infinity> That was the typing fail, I meant to delete that line. :P
<ogra_> heh
<ogra_> and guess what, ARCH indeed failed the same way, it seems to ignore it written either way
<ogra_> but i see etc/config parsing it
<infinity> PROJECT=kubuntu-active find-live-filesystem armhf+nexus7 rootfs.tar.gz
<infinity> ^-- That behaves.
<ogra_> yes, see above
<infinity> Ahh, yes.
<ogra_> download-preinstalled-filesystems also looks fine (i didnt run that one though)
<ogra_> somewhere at the toplevel ARCHES gets reset i assume
<infinity> Oh well.  Just set up etc/default-arches, and worry about ARCHES later? :P
<cjwatson> ogra_: ARCHES - fixed in trunk
<cjwatson> ogra_: I just didn't expect anyone to be trying this before I had a chance to merge it :)
<cjwatson> ogra_: try again no
<cjwatson> w
 * ScottK suspects release engineering is about to get much simpler.
<TheDrums> Bleh, another flash update...
<infinity> ScottK: I wouldn't bank on it.
<ScottK> UDS every three months makes no sense with a 6 month release cycle.
<knome> from the flavor point of view, i'm not sure how it'll make communicating with other teams any easier than it is now. judging that, i'm not sure if uds is rendered useless for flavors.
<ScottK> knome: I think it's rendered useless period.
<knome> ScottK, unfortunately it seems like it
 * ScottK certainly isn't going to take a week off of work to do Google+.
 * knome isn't going to join G+
<jbicha_> if there's enough backlash, they could keep 1 in-person UDS a year at least
<knome> if that's in the states, it doesn't make it much easier for our team than an online udes
<knome> -e
<ScottK> Wait until release schedule changes are announced.  Two UDS's per release doesn't make any sense, so I think there is another shoe waiting to drop.
<ScottK> And I doubt they are about to double the number of releases.
<knome> ScottK, does that comment imply you have some inside information with your release team hat on? :P
<ScottK> No.
<ScottK> That's me inferring stuff from what I've heard.
<ScottK> AFAIK there's been no discussion of the UDS change (or any other) outside Canonical.
<jbicha_> ScottK: maybe that's what we're supposed to discuss next week since there's little time for blueprints
<knome> ScottK, why would there? in the end, it's canonical-driven event. if the community wants, nothing stops us creating our own
<ScottK> I've no idea.  I'll read about it afterwards.
<ScottK> I kind of have work commitments for next week already.
<ScottK> knome: If Ubuntu, the project, is a free software project that's bigger than Canonical, then that's not accurate (and other corporations sponsor UDS too).
<knome> not without canonical though
<knome> it's clear that uds brought big benefits for canonical internal communication as well, no doubt there
<ScottK> True.
<knome> that's one of the reasons i don't really get it
<ScottK> That was also true because most of them were there the week before.
<ochosi> i would assume it's primarily a monetary issue
#ubuntu-release 2013-02-27
<knome> i can't agree more. i had no problem going to copenhagen paid by canonical, but still i think it was all a huge waste of money
<knome> not the whole event, but many of the things
<knome> expensive accommodation and per-diems to start off with a few things
<ScottK> If they kept the interval at 6 months, I might agree it was just financial.
<ScottK> 3 months makes no sense.
<ochosi> i think the 3 months is mostly a "distraction" to keep ppl from complaining too much
<knome> maybe their rationale is to increase quantity to make up some quality
<ochosi> you can't just take something away without giving them something in return
<knome> 3 months doesn't make sense for the xubuntu team. we're barely starting our engines in that time!
<knome> (and no, i'm not telling canonical should adjust their plans to fit the xubuntu team)
<TheDrums> And if they change to the rolling idea?  (IIRC, that was just a side comment too)
<knome> TheDrums, i belive that would support the 3-month cycle, and i believe that's what ScottK also has in his mind
<ochosi> TheDrums: you mean rick-rolling?
<knome> i just double-checked the date to make sure it's not april fools
<ScottK> TheDrums: It's my assumption that'll be the next announcement.
<knome> that would've been a good one though...
<TheDrums> That could make things fun for the flavors.
<ScottK> I think they'll be unrecognizable when it's all done.
<xnox> ScottK: online UDS is 2 days every 3 months vs 4/5 days every 6 months. Closer to a sprint than a half-marathon.
<ScottK> My current best idea it to remove KDE from the archive and just distribute the different versions from different PPAs.
<xnox> ScottK: I'm sure there will be people against that.
<ScottK> xnox: So what am I doing at this first one?  Planning 13.10?  A little soon for that.
<ScottK> xnox: Then they shouldn't cancel the releases we depend on.
<knome> xnox, i'm sure there are people against everything.
<ScottK> Canonical will do what it will do and we'll have to figure out the best way to adjust.
<ScottK> I don't think they get the right to change the whole release process and tell us we can't change things as a result.
<xnox> ScottK: i am not sure what will be planned. Now that ubuntu touch has landed out-of-archive one big chunk would be integrating that into raring images. But that's not as important for flavours.
<knome> ScottK, i can empathize
<slangasek> ScottK: why removing KDE from the archive?
<slangasek> it's obviously for the Kubuntu team to decide what works best for them, but I don't understand the reasoning there wrt moving things to ppas
<ScottK> I think that if we're trying to manage a no release between LTS situation, it' simpler to remove everything except kde4libs and then have one PPA per the four KDE releases that wiould then be happening per Ubuntu release.
<slangasek> (and I'm not sure how that squares with the rules for official flavors / use of Ubuntu marks, regarding everything building from the archive)
<ScottK> It's just my opinion, not the Kubuntu team.
<slangasek> ah, I see
<ScottK> You mean like Ubuntu touch?
<slangasek> yeah, like that
<ScottK> Ubuntu brands have been used lots of times for non-archive builds.  If someone wants to make us call it Ubuntu Kubuntu Remix, then fine.
<slangasek> well, the standing "remix" language specifically only allows for archive builds, which was my point :)
<xnox> ScottK: there is more qt coming into the archive (all of Ubuntu touch), and PPAs don't have armhf/powerpc. And somehow I don't think Blue Systems will be in favour of a Remix.
<cjwatson> Removing all but kde4libs from the archive would make a fair number of other things unbuildable due to bindings and such; it's all fairly intertwingled.
<ScottK> xnox: Blue Systems doesn't control Kubuntu.  They don't really have any say at all.
<ScottK> cjwatson: I'm just talking outloud at the moment.
<xnox> ScottK: ok.
<ScottK> It happens one of their employees is on the Kubuntu Council, but only one, IIRC.
<ScottK> cjwatson: I'm speculating in the face of an information deficit.
<ScottK> It would be nice if the whole story came out at once.
<knome> as always, it seems that the communication from canonical seems to be badly organized
<tumbleweed> it would be nice if we knew what next week's UDS is for. I see a couple of haphazard blueprints, and no sprint on LP
<cjwatson> ScottK: understood
 * cjwatson quickly rebuilds kubuntu-active/daily-live, since it broke
<cjwatson> Has queuebot lost its notion of stable release queues?
<stgraber> cjwatson: that can happen, let me poke it
<stgraber> cjwatson: hmm, it's getting some 401 from LP, let's try a restart
<cjwatson> stg	Thanks
<cjwatson> gah, lag
<cjwatson> stgraber: Thanks
<ogra_> cjwatson, thanks ! working fine now
<ogra_> Riddell, http://cdimage.ubuntu.com/kubuntu-active/daily-preinstalled/current/ please test, if its fine i'll enable the cron job (and default-arches)
<psivaa> cjwatson: infinity: today's server images have the kernel mismatch issue, please let me know if you are respinning them for me to watch the smoke tests. Just reported bug 1134123 to tag the failures
<ubot2`> Launchpad bug 1134123 in Ubuntu CD Images "Raring server installations fail with kernel mismatch with 20130227 images" [Undecided,New] https://launchpad.net/bugs/1134123
<cjwatson> psivaa: Yeah, I suppose I shouldn't have processed some kernels through NEW just before going to bed
<cjwatson> And I guess somebody processed NBS or something
<cjwatson> Hm, no
<cjwatson> Well, I'll sort it out after I get back from the shop, to allow linux/armhf time to publish
 * ogra_ wonders if anyone ever read the cdimage user mail on nusakan
<ogra_> i get the "you have new mail" notice since a few days
<cjwatson> Once a year or so :)
<ogra_> heh
<cjwatson> Ah, yeah, buildlive still witters at us in cronmail
<cjwatson> Once I get buildlive converted to new code I'll probably move that to proper logging
<psivaa> cjwatson: ack, thanks
<Riddell> ogra_: ooh thanks, testing
<psivaa> OEM config short-cut is not present in the desktop images today, reported bug 1134162 for that
<ubot2`> Launchpad bug 1134162 in ubiquity (Ubuntu) "/home/oem/Desktop/oem-config-prepare-gtk.desktop is not present in the desktop images" [Undecided,New] https://launchpad.net/bugs/1134162
<psivaa> cjwatson: xnox: ogra_ ^
<xnox> yeah.... I actually don't know how the shortcuts appear on the desktop, I take it that ubuntu-cdimage project is better for such bug, as my guess is that shortcuts are added at cd building.
<xnox> wait, this is oem. config. it should be there.
<ogra_> yeah
<ogra_> and if anything gets added casper does it, not the build process
<xnox> i see.
<ogra_> at least in terms of .desktop files
<xnox> ogra_: tough chance on having a shortcut if oem-* packages are not installed though =)
<xnox> hmm. but it was apt-install'ed.
<ogra_> right, either unity changes somehow or we dont install the .desktop file anymore
<xnox> ogra_: should oem-* be on the manifest? it's currently missing.
<ogra_> i think it should, compare with an older one
<xnox> (in squashfs or in the pool, that's the other question)
<psivaa> xnox: ogra_ : this issue is with both precise and raring in today's images
<ogra_> xnox, in squashfs
<ogra_> afaik
<xnox> psivaa: oem-config is on the iso in ./pool/main/u/ubiquity/oem-config_2.13.12_all.deb
<xnox> let me sync new images.
<psivaa> xnox: ahh ok, that may explain why the static validation tests are filing with ./pool is not being present in the images
<xnox> psivaa: right, maybe that should be fixed first ;-)
<psivaa> xnox: do you need a new bug for that or is the above bug enough to account that? :)
<xnox> psivaa: i think it's best to move that bug above to ubuntu-cdimage project.
<psivaa> xnox: ack
<xnox> psivaa: where do you see static validation errors?
<xnox> psivaa: are there raring validation jobs?! https://jenkins.qa.ubuntu.com/search/?q=static
<psivaa> xnox: they are both precise and raring but not published
 * ogra_ wonderas if we lost the live-ship seed or some such ... pool is filled by it usually
<xnox> ogra_: it's interesting there is ./dists/ with usual set but the Packages.gz is empty and there is no pool at all on the cd =)
<xnox> psivaa: i expect installing 3rd party software in offline mode not to work either as it depends on the /pool/ as well.
<psivaa> xnox: ok, i have not tried that yet. will do in a little while
<xnox> psivaa: no need. Image is borked.
<psivaa> xnox: ack
<xnox> (half-borked for non-essential features)
<cjwatson> I'll look shortly
<cjwatson> No doubt it's my fault
<doko> so what keeps the php-horde packages out of raring?
<Laney> their uninstallability
<xnox> doko: the fact that -passwd and -whups need removing. As they depend on 4.x stack & php-horde has moved on to 5.x stack.
<xnox> doko: or finding / uploading -passwd & -whups that can be installed with 5.x stack.
<xnox> doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695898
<ubot2`> Debian bug 695898 in php-horde-passwd "php-horde-passwd: not installable in sid, depends on old php-horde" [Serious,Open]
<xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695899
<ubot2`> Debian bug 695899 in php-horde-whups "php-horde-whups: not installable in sid, depends on old php-horde" [Serious,Open]
<xnox> and -wicked apperantly as well.
<doko> Laney, which reminds me ... haskell in -proposed ;)
<Laney> yep, feel free to help :-)
<doko> next +1 maintenance cycle =)
<cjwatson> Maybe I should teach proposed-migration that udebs may not depend on debs ...
<ogra_> cjwatson, hmm, my ubuntu-touch sync script runs sync-mirrors as the last command, it looks like this doesnt happpen (i see the synced dir on nusakan but not on cdimage) do i need to add a PATH to my script (i thought running it as cdimage the PATH would be set correctly)
<cjwatson> ogra_: bug 1133315
<ubot2`> Launchpad bug 1133315 in Ubuntu CD Images "Export PATH as soon as possible to use cdimage tools" [Undecided,New] https://launchpad.net/bugs/1133315
<cjwatson> Let me see about fixing that
<cjwatson> Actually, that's something else
<ogra_> well, it seems to have actually died before
<ogra_> else it would have sent the log by mail
<cjwatson> cjwatson@nusakan:~$ sudo -u cdimage env | grep PATH
<cjwatson> PATH=/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<cjwatson> cjwatson@nusakan:~$ sudo -u cdimage -i env | grep PATH
<cjwatson> PATH=/home/cdimage/bin:/home/cjwatson/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<cjwatson> Or something along those lines
<cjwatson> Or you could just set PATH, which I think is what I would do
<cjwatson> Note how cdimage's crontab sets PATH at the top
<cjwatson> Not sure why that isn't set in your script in that case
<ogra_> cjwatson, yeah, the script had a bug right before sync-mirrors
<cjwatson> Ah, OK, I didn't read you properly
<Laney> can someone please promote libarchive13?
<cjwatson> Laney: done
<Laney> merci
<doko> Laney, do you have an idea where to start with the haskel migration?
<Laney> it's already well underway
<Laney> but there's at least one sub transition
<Laney> I've been pulling the latest stuff from exp, rebuild testing and then syncing
<doko> I think I added another one.
<Laney> starting at the top of the table
<Laney> if there's no new package (a sub transition for stuff we already synced), just do a no-change rebuild
<doko> libgc1c3,
<Laney> some of the things at the top fail to build and require upstream changes (I fixed a few of those already)
<doko> and now kaya ftbfs, but as it looks, for unrelated reasons
<Laney> check if stuff ftbfs in experimental too, that's usually a good sign that it needs porting
 * xnox ponders if we can automate rebuild tries in a ppa or some such.
<Laney> i thought about writing a script to do that locally
<Laney> read .ben file, try rebuilding, dch --rebuild if successful
<infinity> The biggest problem with the Haskell transition is that people overzealously sync/upload too quickly and let arches get out of sync.
<infinity> And then you sometimes get to rebuild a chain 17 packages deep to fix it again.
<infinity> Such a pain.
<Laney> Yeah, wait for the slowest arch
<Laney> yay sagari
<infinity> Usually, the problem isn't speed, it's FTBFS and people not checking.
<infinity> But speed sometimes too, yeah.  Especially when queues are slammed, like today.
<cjwatson> Let's drop amd64, it's too far behind
<infinity> +1
<infinity> Well, no.
<infinity> -1
<infinity> Let's drop i386 and give all its buildds to adm64.
<infinity> amd, too.
<ogra_> just replace it with arm64
<infinity> Speaking of the confusion between amd64 and arm64, I wonder if everyone else is as excited as I am about AMD getting into the AArch64 race.
<infinity> Like, someone who actually knows how to fab and market server-class CPUs...
<infinity> I look forward to a future when all our ARM buildds are AMD-based HP DL(mumble)s.
<ogra_> ++
<ogra_> and then later AMD arm64 laptops with radeon graphics :)
<xnox> the most sold processors in the world are still 8-bit, more than 60% market share last time I checked.
<xnox> 16bit is still teething in.
<slangasek> "give all its buildds to adm64"? infinity has his own port now?
<slangasek> though I didn't think he was that old
<ScottK> Doesn't help much if it's octal either.
 * slangasek thbts at bug #1134461
<ubot2`> Launchpad bug 1134461 in base-files (Ubuntu) "/var/mail is real instead of symlink :: /var/spool/mail is symlink instead of real" [Undecided,Invalid] https://launchpad.net/bugs/1134461
 * xnox failed to parse "thbts"
<slangasek> xnox: a raspberry
 * ScottK thought it was a "Bill the cat" imitation.
<ScottK> ;-)
<ScottK> Of course you all may be too young for that reference.
<slangasek> ScottK: the preceding 'ack' was absent
<ScottK> Good point.
<infinity> cjwatson: *blink*... Did britney have an aneurysm?  The outdates it lists for linux are NBS...
 * infinity wonders if the .dsc is wrong.
<infinity> Nope.
<infinity> cjwatson: Oh, that's because of the NBS in -proposed.  Bother.  I guess I'll clean that manually.
 * infinity fixes.
<cjwatson> infinity: Lack of reports for -proposed?  I wonder what happened to that work ...
<infinity> Dunno.  But now I want them for $stable-proposed too.
<infinity> Cause I realised that my change to make linux-* not show on sru-report (for many good reasons) also meant it stopped showing removal commands for it, and now I have built-up cruft. :P
<ScottK> Isn't that called exceeding expectations?
<infinity> Hrm.
<infinity> You just can't make a your face / your mom retort to that.
<infinity> "Your face exceeds expectations!"
<infinity> "Why, thank you, good sir."
<cjwatson> You could make linux-* not show in the main tables but still show removal commands for them.  Just exclude in a different place.
<infinity> cjwatson: Well, I wanted "not show" to also mean "not pointlessly walk bugs", and there seemed to be only one place to do that.
<infinity> cjwatson: But, yes, some refactoring could fix that.
<cjwatson> Yeah, that might involve a pair of changes, or refactoring.
<infinity> stgraber: Since slangasek and cjwatson don't seem to be around, want to wield your TB bat and add daviey to ~ubuntu-sru, so he can drive the tools while I'm training him?
<stgraber> infinity: will do in a minute when I have a web browser again (doing PXE tests on my laptop at the moment)
<infinity> Hah.
<stgraber> infinity: added
<bdmurray> Can somebody tell me where 'libappindicator_0.4.92-0ubuntu2.diff.gz already exists in Primary Archive for Ubuntu'?
<jbicha> bdmurray: https://launchpad.net/ubuntu/+source/libappindicator/0.4.92-0ubuntu2
<infinity> bdmurray: It's been superseded, but once a version's used up, it's gone.  No can re-use.
<bdmurray> infinity: so just skip over ubuntu2 and ubuntu3?
<infinity> bdmurray: Which series are you targetting?
<bdmurray> precise
<infinity> 0.4.92-0ubuntu1.1
<ScottK> Yep
<antarus> infinity: around?
<antarus> or anyone on release team?
<antarus> looks like one of your files is busted
<antarus> hrm
<antarus> spoke too soon
<antarus> silly engineers lying to me ;p
<infinity> antarus: Glad I resolved it without doing anything.
<ScottK> Good job infinity.
 * infinity buffs his nails on his shirt.
#ubuntu-release 2013-02-28
 * ogra hugs nusakan and the livefs builders and hopes we never need to switch to jenkins ...
<ogra> i just spent a damned hour trying to find a detailed build log for a failed phablet build ... seems jenkins has no concept of showing you actual info thats not mangeld
<Daviey> ogra: I think it does.. it's a build artifact.. If not, i would suspect the job hasn't been created properly to collect logs.
<xnox> usually downloadable as a zip file.
<ogra> the only build artefact log i can find is a very top level one
<ogra> and seriously, that UI is completely unusable
<ogra> finding a build log on nusakan takes me less than a minute .... 2min through http (since its a few extra clicks)
<ogra> (and i dont eant to download and unpack a zip file, i just want to see the last few lines of the live-build log telling me whats broekn)
<ogra> *want
<ogra> they should sell it to to valve... surely makes a good adventure game
 * ogra types "go north" into the search box
<ogra> ..." you have been eaten by a grue" ...
<ogra> gah
<Riddell> so is raring really cancelled?
<TheLordOfTime> wait what?
<GridCube> lol no
<ogra_> Riddell, seems rather that raring is 14.04
<ogra_> Riddell, btw, how did your nx7 tests turn out, did you get to it already ?
<Riddell> ogra_: sorry it gave some error about something missing and dropped to a busybox shell
<Riddell> ogra_: I was going to test the ubuntu image to compare then report back but got distracted
<ogra_> ok
<Riddell> should still get to it today
<ogra_> i'm around if you need me
<jbicha> nah, it's Rolling Raring and Stable Salamander (but of course the decision isn't quite final yet either)
<jbicha> I think it depends on whether an Occupy Millbank movement spring up in the next week or something
<Laney> Bluefin*
<slangasek> heh
<xnox> jbicha: feel free to Occupy Millbank =) we are on the other side of the river now ;-)
<xnox> to be honest my mate asked if he should install quantal and I replied well precise and raring are far better at the moment.
<xnox> he went with raring.
<Laney> now he gets more than he bargained for ;-)
<jbicha> yeah, precise is great and raring is great too if you have a friend who's an Ubuntu developer ;)
<xnox> jbicha: and if that friend has all technical leads on a quick ping away ;-))))))
<Laney> well, every ubuntu developer has that
#ubuntu-release 2013-03-01
<seb128> hum
<seb128> can somebody reject https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.10 from precise-proposed?
<seb128> it's broken
<seb128> libsoundnua.so bails out on a undefined symbol: gvc_mixer_ui_device_is_output
<seb128> which is pretty weird seeing the diff for the update
<seb128> https://launchpadlibrarian.net/131132089/gnome-control-center_1%3A3.4.2-0ubuntu0.9_1%3A3.4.2-0ubuntu0.10.diff.gz
<seb128> did the toolchain change or something that could explain that?
<seb128> ignore the toolchain question, found the issue, fixing it
<seb128> please somebody from the SRU team approve http://launchpadlibrarian.net/132662315/gnome-control-center_3.4.2-0ubuntu0.11_source.changes
<seb128> it's to fix a breakage from the current version in proposed, diff is trivial:
<seb128> http://launchpadlibrarian.net/132662660/gnome-control-center_1%3A3.4.2-0ubuntu0.10_1%3A3.4.2-0ubuntu0.11.diff.gz
<ogra_> cjwatson, slangasek, infinity, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-cdimage-android-builds
<cjwatson> seb128: accepted
<seb128> cjwatson, thanks
<apw> cjwatson, i have inadvertantly uploaded linux-meta-lowlatency to precise directly (which makes no sense) could you reject it please
<apw> cjwatson, (in precise)
<ogra_> *giggle*
<ogra_> i think for the android builds spec i could actually revive livecd-rootfs to be something more than a wrapper for live-build again
<cjwatson> apw: I don't see it - where's that?
<apw> cjwatson, seems infinity sorted it for me
<apw> thanks for checking tho.
<cjwatson> OK
<adam_g> is it acceptable for a proposed SRU  to install an entirely  new binary that was added upstream as part of a bug fix?
<xnox> adam_g: sometimes yes. E.g. mdadm added "forgotten" /sbin/mdmon in an SRU into precise. But it needs to be justified with a testcase.
<xnox> (was missing from /debian/mdadm.install whoops)
<adam_g> xnox, well, in this case (quantum) the upstream solution to a critical bug was to introduce a new cleanup utility. there's a package in quantal-proposed that is expected to ship it, but an .install needs updating. can't think of a test case other than [ ! -e /usr/bin/quantum-ovs-cleanup ]
<xnox> adam_g: the test-case in the "critical bug" that now needs a cleanup utility.
<xnox> adam_g: e.g. reproduce the bug, use clean-up util make sure it fixes everything.
<adam_g> xnox, right
<xnox> adam_g: is the utility cronned or like executed on upgrade?
<xnox> adam_g: document that as well.
<xnox> adam_g: there is a reason why the standard SRU template ( https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ) included "In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug."
<xnox> ;-)
<adam_g> xnox, great, thanks. that helps.
<ogra_> cjwatson, wrt your mail answer to highvoltage on the ML ... see that he did "s/13.04/12.10/g (oops)" in a followup
<stgraber> there's something wrong going on with the LP API that's causing a lot of json decode error in queuebot
<stgraber> I'm debugging this now, so no queuebot for a little while
<stgraber> fixed I think, corrupted cache apparently. Has been quite a while since this last happened (pretty much since I started using a separate cache per thread)
#ubuntu-release 2014-02-24
<knome> any specific reason the xubuntu installer has a debian wallpaper on today's daily? :)
<elfy> Riddell: hi - I've no idea who's down to deal with flavours and B1 this week - but I've not seen anything in m/l yet
<Riddell> elfy: stgraber's name is down https://wiki.ubuntu.com/TrustyTahr/ReleaseTaskSignup
<elfy> Riddell: aha - useful wiki page to know exists :) thanks
<stgraber> elfy: sorry, sort of forgot about it, mail sent now...
<knome> stgraber, i've updated the slideshow branch, so whenever you are ready.. :)
<stgraber> knome: ok, will do that in a minute
<knome> thanks!
<knome> (we didn't update the changelog, but i will do that for the final release; we need to update the slideshow at least once more anyway
<knome> you can add a generic item if you wish
<stgraber> yeah, already did
<knome> thanks again
<stgraber> just waiting for a LP translation export and I'll upload it.
<knome> cool
<stgraber> knome: uploaded
 * knome bows
<stgraber> Laney: where's your block generator script again?
<Laney> stgraber: lp:~laney/ubuntu-archive-tools/generate-freeze-block
<Laney> please to review the MP
<stgraber> Laney: oh, I must have missed the MP, will get it in today
<xnox> Laney: stgraber: we are freezing the archive tomorrow, not today, right?!
<Laney> We have been doing Tuesday, not sure if something different is happening for betas
<knome> i thought it was agreed that tue works for betas as well
<stgraber> wiki says
<stgraber> Beta 1 Freeze (for opt-in flavors; Mon/Tue)
<knome> but afair, that hasn't been updated after the ML discussion
<stgraber> ah, could be, let me change that to Tuesday then
<stgraber> ok, done
<knome> good, much better that it has a single day anyway
<Laney> wait
<Laney> I think the ML discussion actually came to the conclusion of Monday
<knome> really?
<Laney> https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002551.html
<knome> to me it looks like steve proposed that, but nobody really replied to that
<Laney> I don't see anything else
<Laney> Kylin asked for longer rather than shorter for beta
<knome> yep
 * Laney shrugs
<Laney> Feels like Monday to me
<knome> though since nobody replied saying that's bad, looks like everybody was fine with monday
<stgraber> ok, Monday it is then
<knome> though to be exact...
<knome> steve talked about the *final beta*
<Laney> "Monday (for betas)"
<knome> oh wait, also "betas"
<knome> yeah
<doko> Laney, freezing while eglibc is in -proposed?
<Laney> not me
<stgraber> doko: when can we expect eglibc to get promoted to trusty?
<stgraber> s/promoted/moved/
<stgraber> I'm guessing it's running through the milion of rdepends adt?
<Laney> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1282907
<ubot2> Launchpad bug 1282907 in eglibc (Ubuntu) "Block migration of eglibc 2.19 from proposed" [Undecided,New]
<doko> stgraber, has an explicit block from infinity
<stgraber> doko: ok. I have a meeting with infinity in 30min, will ask there (if he doesn't reply on IRC earlier).
<stgraber> doko: anyway, if it lands in say the next 3-4 hours, then that's fine, otherwise it'll have to wait until after we lift the freeze
<doko> stgraber, just saying that it might be difficult to pick up things during the freeze which depend on 2.19
<stgraber> doko: do we actually expect many things to have a >= 2.19 dependency on libc6?
<xnox> stgraber: all of ppc64el, but i guess it had that already anyway.
<xnox> (thus shouldn't block migration)
<stgraber> xnox: since AFAIK none of the participating flavours have ppc64el images, that probably won't be a big problem.
<xnox> libnss-db & nscd are the only ones that picked up 2.19 dependency.
<xnox> so anything that uses private 2.19 symbols will get a hard 2.19 dep, but nothing else should.
<xnox> my machine keeps getting random segfaults and internal compiler errors, both on the host and chroot.
<xnox> i'm not sure what's causing them =/
<Laney> meeeeeeeeeeemcheck
<xnox> Laney: actually, got point.
<ogra> that will teach you to build your own machines :P
<xnox> ogra: phf
<ogra> :)
<stgraber> zequence, superm1_: can you update https://wiki.ubuntu.com/TrustyTahr/Beta1 please?
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Alpha 2, 12.04.4 | Archive: feature freeze (+ beta1 migration block) | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<stgraber> cron jobs for the flavours that opted in have been turned off now
<zequence> stgraber: Thanks
<stgraber> zequence: added you to the manifest, updated the migration blocks and turned off your cronjob
<zequence> stgraber: Cool
<infinity> stgraber: Bah, you freeze blocked eglibc before it could go.
<infinity> stgraber: Permission to unblock? :P
<stgraber> infinity: sure
<doko> and gcc-4.8 too please, once built on powerpc
<infinity> I'll get that one too.
<doko> and care to overwrite the libreoffice autopkg tests and get python3.4 in too?
<doko> then I'm happy for the test rebuild
<infinity> doko: That libatomic-ops diff is a lot bigger than the changelog implies...
<doko> infinity, fixed
<doko> infinity, hrm, and now succeeds  ... ?
<infinity> doko: That test is racy.
<infinity> doko: Hence why the original bug noted that it passed, then failed, then passed, then failed...
<doko> infinity, please accept python-repoze.lru, fixing python3.4 failures
<ScottK> If there's a u-d-a moderator around, I'd appreciate you letting my DMB meeting minutes out.
<slangasek> done
<ScottK> Thanks.
#ubuntu-release 2014-02-25
<infinity> stgraber: doko wants python3.4 unblocked.  That cool with you, mister RM?
<stgraber> infinity: I take it this has been reasonably well tested?
<stgraber> infinity: because, "Python 3.4 release candidate 2." doesn't inspire me with confidence especially considering that our installer happens to be using that interpreter ;)
<stgraber> however it does fix a couple of bugs that have been annoying me quite a bit, so there's that...
<stgraber> infinity: ok, so copy if you want, though if you do so, do it in the next 4 hours. That way early european time respins will pick it up (for those flavours that haven't started building candidates yet anyway). Just note that if things go wrong, my plan is an immediate revert to rc1 (seems reasonable as build time is around 3h on slowest arch and there was no new binaries or any problematic change of the sort).
<stgraber> I don
<stgraber> gah
<stgraber> I don't want us stuck debugging a weird python3 issue that somehow makes ubiquity blow up in an interesting way, if that happens we'll just do an ugly revert of the rc1 => rc2 change and do proper debugging after beta1 is out.
<xnox> stgraber: i think i've fixed strange python3.4/new-gobject-introspection bugs already. So I'm ready for round #2 ;-)
<stgraber> xnox: yeah, I'm just not too sure we want to spend time debugging this kind of issue in the middle of a milestone week :) so if we do get that kind of weird regression, we'll just revert python itself and try again after beta1 is out :)
<xnox> stgraber: meh, i wouldn't let it in. It can totally wait until thursday 18:00 UTC.
<infinity> stgraber: I have no real opinion on the matter either way.  I think doko just wants it in for his test rebuild, and he could easily copy it to a PPA for that, if you're wary of the upgrade and likely to revert at the first hint of a bug.
<infinity> doko: ^
<elfy> stgraber: not sure what's going on here - there's no beta 1 available for Xubuntu, I've requested a rebuild on the tracker - but I've no idea how long that takes to do anything
<darkxst> elfy, ours (Ubuntu GNOME) showed up about an hour after hitting rebuild
<elfy> darkxst: ok - thanks
<peterm-ubuntu> infinity xnox is there a list of releases and dates (month for launch, end of hardware support and end of life) like on https://wiki.ubuntu.com/ReleaseTeam#Releases.List_of_releases for the future?
<xnox> peterm-ubuntu: there is https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule the rest of the future is flexible. We do look at holidays and other major events and wiggle things left and right. So estimating anything beyond one release, is guesswork. And like any guesswork, it's easy to extrapolate.
<xnox> peterm-ubuntu: do note the change for intermediate releases, they only have 9 month support, since raring.
<xnox> and LTS is five years.
<peterm-ubuntu> xnox ok... we are just trying to update http://assets.ubuntu.com/sites/ubuntu/latest/u/img/business/screenshot-server-release.png up to 16.04
<xnox> peterm-ubuntu: use nine-month long  gray cubes spaced at 14.10, 15.04, 15.10.
<peterm-ubuntu> will do
<peterm-ubuntu> thanks
<xnox> peterm-ubuntu: also the hardware and maintenance updates should have lts-to-lts overlap: e.g. 12.04 dark orange should be
<xnox> peterm-ubuntu: until ~ 14.07
<xnox> peterm-ubuntu: and i don't think 10.04 had "hardware" updates in the same sense as precise and trusty do/will (there wasn't hardware enablement packs back then)
<peterm-ubuntu> xnox yikes... this chart has been around since before my time
<xnox> peterm-ubuntu: but yeah, we plan is to stay at .04/.10 cadence. =)
<cjwatson> There were linux-lts-backport-{maverick,natty,oneiric} packages in lucid-updates
<xnox> cjwatson: oh, i didn't know. Sorry my mistake.
<cjwatson> They were a bit different in approach but at the level of detail on that image it's close enough
<xnox> peterm-ubuntu: ^^ ignore the "hardware" updates comment. It's all good.
<peterm-ubuntu> ok... cjwatson and xnox we will update and run it by you guys again
<elfy> cjwatson: sorry to bother you - xubuntu is still without a b1 release on the tracker, I did do the rebuild button about 2 hours or more ago
<elfy> not sure who to talk to about it either :)
<xnox> elfy: you probably want stgraber, as he is driving b1 release. And morning hasn't arrived to his location yet =)
<elfy> xnox: ok - thanks - not sure why the rebuild button isn't - but there you go, I'll catch him later
<Laney> elfy: I just tried 'rebuild' and xubuntu seems to be building atm
<Laney> dunno what went wrong for you but hopefully it'll show up soon
<elfy> Laney: ok - thanks
<Laney> unless the problem is after this point, of course
<elfy> :)
<ara> good morning! shall we move the 12.04.3 image to old-releases?
<ara> it is not available here: http://old-releases.ubuntu.com/releases/
<Laney> elfy: would you look at that
<Laney> ;-)
<elfy> thanks Laney :)
<cjwatson> ara: I already put it there on the backend but the sync to the public site isn't working and I haven't had time to investigate why.
<cjwatson> ara: (it might have run out of space or something)
<ara> OK, thanks for the update :)
<cjwatson> Also I think I already told one of your team this?
<cjwatson> Ah, no, different team
<rsalveti> can anyone unblock pulseaudio? small fix that is only affects touch
<stgraber> elfy: has everything been sorted out for you?
<elfy> stgraber: all sorted thanks :)
<robru> ping release team? can somebody unblock ubuntu-ui-toolkit for me? I pushed a minor bugfix, should not regress anything on desktop.
<robru> stgraber, infinity ^
<stgraber> robru: is that missing fix actuall blocking anything major? (as in, why can't this wait till Thursday?)
<robru> stgraber, well, it's a fix for some big test failures on the phone, which regressed this weekend. I'm just trying to pin down the recent phone regressions.
<stgraber> ok. The change itself seems fine and doesn't appear to be in any of the binary packages the flavours participating in beta1 are shipping, so I'll let it through
<robru> stgraber, thanks
<slangasek> stgraber: if it's not in the binary packages used by the opt-in beta flavors, why is it blocked at all?
<stgraber> slangasek: the source produces a bunch of binaries, two of which are on the media of some flavours, however the change that robru did doesn't impact any of those binary packages
<slangasek> ah, ok
<stgraber> lubuntu added to beta1, block updated
<bregma> hey folk, I need a FFe ack for https://bugs.launchpad.net/unity/+bug/1282804 (Unity7), do I need to wait for the beta freeze to lift?
<ubot2> Launchpad bug 1282804 in Unity "[FFe] Move DPI settings over to use u-c-c settings." [Medium,In progress]
<infinity> bregma: You don't need to wait until after beta, no, your bits might just end up stuck in proposed until Thursday.
<infinity> bregma: I'm not sure I'm qualified to comment on the scope of the change, however, so I'l leave it to Laney who appears to have already been on the case.
#ubuntu-release 2014-02-26
<darkxst> can we get gnome-shell unblocked?
<darkxst> For Bug 1284496
<ubot2> Launchpad bug 1284496 in casper (Ubuntu) "Booting the Ubuntu GNOME live DE from the advanced boot menu results in a largely unusable DE" [Low,Confirmed] https://launchpad.net/bugs/1284496
<stgraber> sure, I'll let it through
<infinity> Unfortunately stuck behind a security update of doom on powerpc.
<infinity> Scored it up to see if it can get lucky.
<darkxst> thanks guys
<jdstrand> infinity: if you want to kill the powerpc build on say saucy or quantal, feel free and we/I can restart it later
 * jdstrand drifts off
<jdstrand> (I'll check on it later)
<infinity> jdstrand: Shouldn't be necessary.  Got gnome-shell built.
<seb128> would it be possible to unblock indicator-datetime if there there are respins planned (not sure on what basis we unblock things nowadays ;-)
<seb128> the update fixes some segfault issues which are not hitting quite some users
<infinity> seb128: Mostly up to stgraber.
<Laney> infinity: have you seen http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-server-omap4/latest/livecd-armhf.out ?
<Laney> Looks like component-mismatches to me
<infinity> Laney: No.  server-omap4 and server-omap just need love (or dropping) in general.
<infinity> Laney: I need to see if anyone's actually still using those images (QA might be), and then decide which route to take.
<Laney> I hear that
<Laney> Every day I get a mail for the build failure. :)
<infinity> Serves you right for signing up for livefs build failures. :)
<Laney> It's often stuff that's fixable for me
<Laney> But yeah. Trying to build images over and over which aren't going to work seems less than ideal.
<infinity> Feel free to uncron them for now to reduce the noise.
<infinity> But I need to either fix or drop them, this was a post-FF TODO item for me.
<ogra> infinity, is there any chance we could get the pulseaudio from proposed into the archive (i need to build a new touch image and it fixes a CPU hog that makes a test fail)
<ogra> (afaik trsalveti and diwic tested the binary on phone and desktop)
<infinity> ogra: That's up to stgraber and the flavours doing beta.
<ogra> ah, i thought you both do it
<ogra> sorry then
<infinity> Nah, I'm staying away from alphas and betas I'm not signed up for.
<ogra> right, i'll just do a build without the fix then
<xnox> Laney: hm. d-i components should always be frozen at milestones. I thought grub-installer was frozen, but it wasn't.
<Laney> xnox: hmm, I guess
<Laney> patches to generate-freeze-block welcome :)
<Laney> can someone look at the trusty-proposed NBS packages from dolfin on arm64 please?
<infinity> Laney: Sure.
<infinity> Err, why only arm64, I wonder?
<infinity> Weird.  Maybe it never migrated.
<infinity> Removing the NBS.
<Laney> Yeah, dunno
<Laney> ta
<infinity> Fixed.
<seb128> infinity, do you know about "out of date on ppc64el: empathy, empathy-dbg, mcp-account-manager-goa, nautilus-sendto-empathy (from 3.8.6-0ubuntu4) "? where https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu4 is not having a ppc64el build?
<seb128> infinity, (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#empathy)
<infinity> seb128: It's out of date because it's out of date...
<infinity> It used to build before its rdeps disappeared.
<infinity> (In the previous archive, before the rebuild)
<seb128> infinity, well, 3.8.6-0ubuntu4 had the same issue, how can it be a regression in the new revision?
<infinity> seb128: I'll fix that up tomorrow.
<seb128> infinity, thanks
<infinity> Or, later today.
<infinity> seb128: Also, I was going to yell at you for some recent upload with arch restrictions instead of build-dep hacks...
<infinity> Which one was that?
<Laney> https://lists.ubuntu.com/archives/trusty-changes/2014-February/010640.html
<infinity> Oh, right, gnome-control-center-signon
<seb128> I hate that package
<infinity> "arm64 used to build but doesn't have qt5", that was the whole POINT of the build-dep hack.
<seb128> shrug
<infinity> To make it stop building on arches where it would subsequently be uninstallable.
<seb128> well, that creates issue that I don't know how to resolve
<infinity> Anyhow, most of this faff should go away (I hope) with qt5.2, we really need to get that in soon.
<seb128> e.g britney was unhappy about empathy depending on libaccount-plugin-1.0-0 on arm64
<seb128> that wouldn't exist anymore
<infinity> And we can stop having half our desktop arch-restricted.
<Laney> I saw some requests for QA reports and all sorts of stuff for Qt 5.2 earlier on
<seb128> right
<Laney> So I'm not sure if that is close...
<infinity> seb128: Right, empathy's deps there either should be arch-restricted, or it should just not exist on those arches (like it doesn't on ppc64el).
<seb128> Laney, Pat started pushing thing yesterday, let's see what happens next
<seb128> Laney, (I hinted that they might miss trusty if they don't start making progresses soon)
<infinity> Laney: We all need to push to make it closer, IMO.  Anything anyone can do to help them fix things up.
<seb128> infinity, right, so I should have deleted the empathy arm64 old binaries?
<seb128> infinity, and I think empathy is not alone
<seb128> tracking those issues down seems a waste, we just need to land qt5.2 as you said
<seb128> meanwhile the g-c-c-signon arch restriction is the cheap and easy workaround
<Laney> Pushing good, shifting sands bad
<infinity> seb128: We get to rebuild all the qt5 rdeps for the armhf ABI break anyway, so that'd be a good time for people to go through and drop all the arch restrictions at the same time and see how well the new world order works.
<infinity> seb128: Maybe I should try this in a PPA with PPC and arm64 enabled and see how bad/good the situation is.
<seb128> right
<mapreri> Can you unblock qemu? it's mainly for bug #1284344
<ubot2> Launchpad bug 1284344 in qemu (Ubuntu) "qemu-user-aarch64: dns is broken" [High,Confirmed] https://launchpad.net/bugs/1284344
<ogra> stgraber, any chance that we can get the pulseaudio fix in ? i belive diwic and rsalveti tested on phone and desktop before uploading
<stgraber> qemu and pulseaudio unblocked
 * ogra hugs stgraber 
<mapreri> thanks stgraber :)
<seb128> stgraber, what are the current rules/can we get packages in or does that mean respinning isos if we do? the indicator-datetime update in proposed fixes some common segfault
<seb128> stgraber, unity-control-center has some changes that would be nice to push to users so they test that new version, but if that's after beta it's not the end of the world
<seb128> stgraber, having unity in could be nice as well, since that enable the scaling option for HiDPI
<Laney> haha
<seb128> Laney, what? ;-)
<stgraber> seb128: it doesn't mean respinning ISOs but it means that if anything breaks as a result of me letting the package in, I'll be very very unhappy ;)
<seb128> stgraber, don't worry, it's only good code :p
<stgraber> I'll look at indicator-datetime, the rest sounds like it can wait until after we lift the freeze
 * seb128 crosses finger there are no bugs
<seb128> stgraber, fair enough, thanks
<Laney> seb128: I just found listing all your uploads funny :P
<seb128> Laney, "all", it was just a nicely selected set :p
<Laney> stgraber: I think everyone's been staying away from unblocking stuff in 'your' beta, but that seems like a quite conservative approach... would you have minded if others did some unblocks?
<Laney> I'd have considered pulseaudio and datetime
<seb128> it's a bit of a shame that we beta test an unity version which doesn't include HiDPI, that testing is not as useful as it could be, but I guess it's the unity's team fault for not landing it before the freeze
<stgraber> Laney: I don't mind other members unblocking things so long as they actually look at the diffs and are 99.9% sure this won't cause changes/regressions
<Laney> nod, that'd be my approach
<Laney> cheers
<xnox> seb128: ubuntu is not in a beta test, kylin/edubuntu are. Not sure it's nice to beta test unity in kylin/edubuntu milestones without ubuntu also participating.
<xnox> seb128: it would make more sense to "let new unity in, and respin ubuntu-desktop".
<Riddell> Laney: should upgrade not be on the iso testing site for beta 1?
<Laney> Riddell: If you like, but don't ask me - I'm not involved with this beta. :)
<Laney> You can put them up there if you know how
<infinity> xnox: If you let it in, it affects the others if they need to respin for some unrelated reason
<Riddell> Laney: oh yes, sorry :)
<seb128> xnox, right, I know ubuntu isn't, meanwhile we run/test and unity version which is not the one we should be testing (we might hit bugs already fixed and not see bugs in the current version)
<Riddell> stgraber: should upgrade not be on the iso testing site for beta 1?
<xnox> infinity: yeah, my point is without ubuntu-desktop partitipating, you /only ever/ affect others
<stgraber> Riddell: they probably should, let me add them
<xnox> seb128: i think we can wait till tomorrow's freeze block lift. ;-) still should be faster than ci-train unblock =))))
<seb128> xnox, yeah, and build failed on ppc64el anyway, so need to fix that first
<stgraber> Riddell: there you go
<infinity> seb128: Oh, probably about time to ask for all those pre-landing PPAs to get ppc64el enabled.  We're not resource constrained anymore.
<Riddell> stgraber: you meanie, you just gave me hours of extra testing to do!
<seb128> infinity, speaking of which, do we have a porter box?
<infinity> seb128: That's in progress today.  I'm about to nap, but will hopefully get together with an APAC GSA later tonight to make it go.
<infinity> seb128: (And you get a powerpc porter box for free out of the deal)
<seb128> cool
<directhex> so what's the quickest way to get mono ppc64el removed from the archive? it's a blocker for -proposed transition, and i *really* want that unblocked for FFe reasons
<directhex> i recognise that critical test suite failures should cause package build aborts. i'm discussing the best way to do that with upstream
<bdmurray> slangasek: can you merge this? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-rate-increase/+merge/208445
<Noskcaj> Can someone please approve bug 1282937
<ubot2> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
<slangasek> bdmurray: merged
<bdmurray> slangasek: thanks
<infinity> directhex: So, would it hurt your feelings if I said the better option is that I'm having people looking into fixing mono on ppc64el?
<infinity> directhex: Is it actively breaking anything if it's allowed to build there?
<directhex> infinity, more working arches is fabulous. but upstream have never looked at ppc64el - the fact that it even builds is accidental more than anything else
<infinity> directhex: That didn't answer my question.
<infinity> directhex: Does having mono broken in the way it is *actively break* other packages (ie: in the sense that they'd need to be rebuilt after mono was fixed), or just cause some/many of them to fail at runtime?
<directhex> is it actively breaking anything? no
<infinity> directhex: If they're just failing at runtime and a fixed mono would fix the world, I say we just let it build and work on fixing it.
<infinity> (Which I have people looking into)
<directhex> if leaf packages fail to build on ppc64el then, well, there's not much i can do about it
<infinity> directhex: Failing to build is fine.  It's building incorrectly and needing a rebuild that's a mess to track down.
<infinity> directhex: But as I understand mono, the latter shouldn't be the case.
<directhex> infinity, yeah, most of the packages are arch:all
<directhex> and the ones that are arch:any, only the C portion varies between arches
<directhex> where, surprisingly enough, it's gcc's problem if it's screwy
<directhex> i guess technically there could be glue code which would need a rebuild... but i suspect the glue code is assuming the same size of C types as ppc64, which is correct
<infinity> Kay.  It's the cleanup of the arch:any stuff that I'm trying to avoid here (though will revisit if I have to, if mono isn't fixed by release).
<infinity> Cause tearing out all the arch:any binaries for mono rdeps would mean reuploading all those sources when mono is fixed.
#ubuntu-release 2014-02-27
<directhex> nggggg
<directhex> well, the problem with some of the more esoteric arches is availability of porter hardware
<directhex> e.g. i expect giving alexrp root on a ppc64el box for a week would yield a fixed port
<directhex> but canonical don't give externals access, and ppc isn't that common anymore unless you have space at home for pseries, and all the money
<directhex> lack of hw is why ppc64 is broken, too. i can't investigate since there's no debian porterbox for debian-ports arches
<directhex> right, bedtime
 * amjjawad is away: Be Right Back :)
<utlemming> stgraber: I need to add a bunch more types for the test suites for EC2
<utlemming> stgraber: specifically "Ubuntu Server EC2 HVM ({SA-East-1, Asia-Pacific-SouthEast-Australia, Asia-Pacific-NorthEast, US-West-1)}" and "Ubuntu Server EC2 HVM-Instance Store (<all regions>)"
 * amjjawad is back (gone 03:12:18)
<knome> amjjawad, could you please not use public away messages? thanks.
<amjjawad> ?
<cjwatson> amjjawad: "13:41  * amjjawad is back (gone 03:12:18)" - people generally don't care, please turn that feature of your client off
<amjjawad> cjwatson, I do hate IRC just for the record :) so I know little bit about it
<amjjawad> I have no idea how to turn that off
<amjjawad> I use XChat and I choose away when I'm away, that is all.
<knome> amjjawad, afaik, you didn't have that turned on before. ask the xchat channel how to disabled that.
<knome> -d
<cjwatson> Google for "xchat disable public away messages
<cjwatson> "
<amjjawad> why not that is a problem?
<cjwatson> Looks like "/set away_show_message off", perhaps
<amjjawad> I don't even come here unless I have to :) I'm not an IRC user at all
<amjjawad> now*
<cjwatson> Because it shows as real-conversation activity in the channel rather than things that IRC clients can automatically determine is uninteresting
<cjwatson> Also because people asked you to
<cjwatson> It's polite
<xnox> amjjawad: 132 people spent 3 seconds of their productivity time, reading that message, causing 2 context switches =)
<amjjawad> I don't know much about it so I will try to search on Google :) or even better not use it :)
<amjjawad> xnox, wow? didn't know that :)
<amjjawad> sorry about the 3 seconds that I wasted from your time :)
 * infinity notes that xnox has a very inefficient string parsing engine in his brain.
<infinity> amjjawad: It's not about "wasted time", it's that if all 132 people in the channel has verbose away/back messages, the entire channel log would just be spam from people going away and coming back.
<cjwatson> amjjawad: The point is, imagine how unreadable the channel would be if every one of the 132 people (or whatever) in the channel decided to have their IRC client tell us when they're going out to the toilet.
<cjwatson> Right, that.
<infinity> amjjawad: So, either you're a unique snowflake who needs to tell us when he's around, or none of us should do it.  We're opting for recommending the latter. :P
 * knome giggles at the mental image
<amjjawad> Again, I know nothing about IRC so could we please move on and point taken, I will do my best to not use that :)
<knome> "* cjwatson is off to the gents"
<amjjawad> all my teammates know I hate IRC
 * jpds tries to imagine #ubuntu like that.
<amjjawad> I'm forced to use it from time to time
<amjjawad> so point taken, thanks :)
<knome> jpds, ow, my head!
<cjwatson> OK, you don't need to go on about how much you hate IRC either :)
<amjjawad> 2nd point taken :)
<bregma> hey, we've got a critical fix in -proposed, what are the chances we can get it migrated to release withing the next couple of hours?
<cjwatson> it'd help to say what it is :)
<bregma> well, I was hoping someone would ask
<bregma> this is a fix to Nux for bug #1282884
<ubot2`> Launchpad bug 1282884 in nux (Ubuntu) "compiz crashed with SIGSEGV in __dynamic_cast()" [Critical,In progress] https://launchpad.net/bugs/1282884
<plars> xnox: psivaa said he or davmor2 talked to you already about the server install failures - is there a fix coming soon for that?
<xnox> plars: yeah.
<xnox> plars: did you open a bug report number for it?
<plars> I didn't, but perhaps psivaa or davmor2?  If not, I'll be happy to open one
<cjwatson> stgraber: Do you have any Edubuntu, Ubuntu Kylin, or Xubuntu rebuilds still planned for beta 1 (I see they're all marked as ready)?  If not would it be OK if I unblocked nux?
<davmor2> plars: it was psivaa
<psivaa> plars: xnox: i haven't, do you want a bug report for that?
<knome> cjwatson, no rebuild planned for xubuntu. i don't know what nux is, but i'll leave unblocking it to your judgement :)
<xnox> plars: psivaa: that's ok, i'll just reopen the existing one, that i've closed.
<psivaa> xnox: ack
<highvoltage> cjwatson: no rebuilds planned for edubuntu.
<cjwatson> stgraber,bregma: nux unblocked
<stgraber> so for Beta 1, I'm planning for a mid-afternoon release. I've got a couple of meetings now but will prepare the announcement after that.
<stgraber> (mid-afternoon eastern time, so in 4-5 hours)
<stgraber> utlemming: I'll try and get those done in a tiny bit
<infinity> stgraber: Does that mean you're happy with the ISOs and we can unblock?
<infinity> (the world, I mean)
<stgraber> infinity: not the whole world yet, still waiting for Kubuntu and Lubuntu to mark them ready
 * infinity nods.
 * highvoltage copies and pastes edubuntu notes so long
<utlemming> straber: thank you kindly
<highvoltage> stgraber: hmm... where will the note links be?
<Riddell> stgraber: marking kubuntu as ready, I'm about to run away for a long weekend, shadeslayer and apachelogger are your contacts
<stgraber> Riddell: ok, thanks
<stgraber> utlemming: HVM is 64bit only right?
<utlemming> stgraber: yes, only 64-bit
<stgraber> utlemming: ok, I have added the products, still have to link the tests and add them to the trusty manifest
<stgraber> utlemming: all done
<stgraber> highvoltage: what are you referring to?
<stgraber> highvoltage, shadeslayer, apachelogger, zequence, knome, amjjawad, darkxst, elfy: http://pad.ubuntu.com/trusty-beta1-announcement
<stgraber> I'm still doing some sed on that though :)
<highvoltage> stgraber: yes that's it
<directhex> infinity, so, for now, ubuntu1 my mono 3.2.8 upload to re-enable ppc64el, so those binaries build & that blockage on proposed->main transition goes away?
<infinity> directhex: Yeah, that's what I'd advise.  If I don't get it fixed by final freeze, we can back it out and tear out all the dependant binaries, but I'm pretty confident we'll get someone on the case.
<infinity> directhex: Or were you asking me to do the ubuntu1 upload?  I can do that.
<directhex> infinity, i can do it now, that's fine
<infinity> Kay, cool.  Thanks.
<directhex> huh, i hadn't looked at this diff in detail before, it's not just tinkering in debian/, it's a substantial body of work
<directhex> i may have misrepresented that when i said i wasn't happy about it having been unilaterally uploaded. wonder how much of this helps on BE powerpc64
 * infinity downloads to look.
<infinity> Also, whee, 78MB orig?  Really?
<infinity> Oh, indeed, that's a lot more patch than doko's changelog implied...
<infinity> directhex: I'll hunt down where that came from, so we can get it properly fixed.
<infinity> directhex: Okay, so some of this is upstream.  Not sure how much...
<directhex> infinity, not seeing much of it in master
<directhex> beyond the existing bitrotted ppc64
<infinity> directhex: Yeah, I think the first file I checked happened to be a fluke on that score.
<cjwatson> Riddell,ScottK,Mirv,didrocks,asac: any/all of you up for subscribing to https://blueprints.launchpad.net/ubuntu/+spec/core-1403-qt5-versioning (scheduling late)?
<infinity> directhex: So, wherever doko got this mystery patch from was someone who had pulled some bits from upstream and then got to work on the porting.  I'll hunt that all down and sort it out.
<infinity> (Sadly, I think doko just disappeared for the weekend, but I'll figure it out)
<infinity> directhex: In light of that "someone was obviously working on porting it" thing, though, I feel more confident about re-enabling it and assuming it'll get fixed.
<asac> cjwatson: you rock :)
<didrocks> cjwatson: sure
<asac> cjwatson: thats a UDS session?
<ogra> asac, obviously
<cjwatson> that's the idea
<ogra> (see the "Sprints" part
<ogra> )
<directhex> infinity, i think that's fair
<asac> i didnt open yet.
<asac> :)
 * asac subscribes
<asac> cjwatson: who will come with the proposals to discuss?
<asac> nevermiund
<cjwatson> there's a whiteboard with notes
<asac> let me read it first
<directhex> infinity, seems the biggest gap here was a lack of coordination with the debian packaging team, then - especially by whomever was writing patches this sophisticated
<directhex> swapping out target registers isn't casual hackery
<xnox> infinity: i've had similar mistery patches from doko for e.g. boost port, that i've upstreamed. he didn't tell me where he got them from...
<infinity> directhex: Fail on doko's part for the really non-verbose changelog and not forwarding to Debian.  Fail on the mystery porter's part for this not being upstream.  I'll try to make sure both are appropriately chastised (once I figure out who that second party is...)
<Laney> hahaha
<Laney> I love that doko has kidnapped some people to live in his basement and work on porting software for scraps of food every few days
<xnox> infinity: i wonder if the mystery porter, is doko, intoxicated hard....
<knome> if it is, i guess i want that booze to be able to write sophisticated code
<xnox> Laney: don't give out foundation's secretz.
<Laney> the klose peak
<directhex>  20 files changed, 363 insertions(+), 281 deletions(-)
<infinity> xnox: I guarantee it's not.
<directhex> this is pretty comprehensive work, and yes, i'm happy to include this in an ubuntu1 for now. if it goes upstream, it can be a patch branch in -4
<directhex> the changelog fooled me as to the scope of the changes
<infinity> directhex: You and me both.
<directhex> signing/uploading.
<infinity> directhex: Many thanks.
<directhex> infinity, looks like 1 file gained doko's changes between 3.2.3 and 3.2.8, but none of the rest of it is upstream
<directhex> and that might be an unrelated fix
<infinity> directhex: I've already hunted down the porter in question, and we'll be working on both upstreaming and fixing.
<directhex> infinity, is that canonical confidential, or can you name them?
<infinity> directhex: It's vaguely confidential until they make themselves known via a pull request. :/
<directhex> infinity, that's fine
<directhex> infinity, are you also doing BE ppc64? i'm curious whether this patch set affects BE ppc64, but my only means to test that is to upload something to Experimental & keep an eye on buildd.debian-ports.org for a few days
<infinity> directhex: Hah, loving the changelog comment.
<xnox> stgraber: Laney: does qa tracker allow to trigger respins of the "daily" milestone?
<stgraber> yes
<xnox> stgraber: may i have rights, to trigger e.g. ubuntu desktop and ubuntu server respins on daily images? =) e.g. i don't like waiting a day to see automated jenkins results, after landing fixes to bugs that automation picked up.
<xnox> stgraber: or shall i wait, and / or poke people? E.g. please respin ubuntu-server i386/amd64 to pick up new grub-installer, which should make server.iso promotable to current again.
<xnox> stgraber: also, all testing is complete and almost everything marked as ready. Isn't it past respin point, and thus freeze block should be lifted?
<stgraber> xnox: waiting for lubuntu
<stgraber> but yeah, if I don't hear back from Julien by then, I'll lift the freeze in an hour or so
<xnox> stgraber: thanks.
<stgraber> as for respin access, I'd to think about how to structure that, possibly making ~ubuntu-installer have product ownership access to some of the images, will have to think about it
<stgraber> JackYu: hey there, can you update: http://pad.ubuntu.com/trusty-beta1-announcement
<stgraber> flood gates opened
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Alpha 2, 12.04.4 | Archive: feature freeze| Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Alpha 2, 12.04.4 | Archive: feature freeze | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<seb128> stgraber, \o/
<xnox> stgraber: well, i wish to only be able respin dailies.... but milestones and dalies are the same thing, when milestone is active
<stgraber> ok, that's all the flavours, doing publishing now
<stgraber> utlemming: feel free to do your bits now (if any)
<utlemming> stgraber: ack, and done already :)
<shadeslayer> stgraber: \o/
<rtg> infinity, when you get a moment could you approve linux-firmware 1.79.11 in Precise ? Its causing issues for some folks 'cause I removed the iwlwifi firmware from the kernel package. See bug #1285727 - guess I should have waited.
<ubot2`> Launchpad bug 1281964 in linux-lts-saucy (Ubuntu) "duplicate for #1285727 Firmware iwlwifi-7260-7.ucode is missing" [Undecided,Confirmed] https://launchpad.net/bugs/1281964
<infinity> rtg: We still have .10 in proposed.  What's meant to happen with that?
<rtg> infinity, supersede it and approve the SRU bugs ?
<infinity> rtg: Looks like releasing .10 would fix this... Unless there's a reason it shouldn't be?
<rtg> infinity, the commit logs from Intel are totally confusing, but the second one 'iwlwifi: update firmware for 7260 / 3160 devices' actually adds a new file and API revision that a stable update added to the 3.11 kernel
<rtg> which is why I'd like to see 1.79.11 get released
<infinity> rtg: Sure, just saying that this "missing iwlwifi-7260-7.ucode" is in .10
<infinity> rtg: And .10 appears to be tested, just that no one marked all the bugs v-done.
<rtg> infinity, right you are. the second commit adds -8 which is for trusty.
 * infinity nods.
<infinity> So, let's release .10 and then accept .11 for testing.
<rtg> infinity, works for me
<infinity> First bit done.
<infinity> rtg: Maybe we should consider pulling firmware into the PPA and tracking it with shanky, so we don't misplace updates that are needed to match kernels.
<rtg> infinity, I think I've got everything we need for Trusty LTS, so there shouldn't be anymore changes.
<rtg> it might help for the Trusty linux-firmware package though
 * infinity nods.
<rtg> I'll bug bjf
<infinity> rtg: Anyhow, .10 should push out to mirrors soon enough and close that particular bug for you (well, you'll have to close it by hand, I leave that to you).
<infinity> rtg: And .11 accepted to proposed.
<rtg> saw that. thanks
 * seb128 shakes fist at ppc, so 4 builders, all taken by private jobs
<infinity> seb128: Is there something that desperately needs building or the world will explode, or is that just a general complaint?
<seb128> infinity, just annoying to see everything else blocked, seems like we could keep/spare 1 builder for "normal business"
<infinity> seb128: Security updates are "normal business".
<infinity> And intentionally scored higher than everyone else, too. :P
<seb128> well, more annoyed that the delay for my build is "one hour" and I wanted to see the result before eod
<seb128> but that's not an important one, so just ignore me
<xnox> infinity: i have a weird request -> and android-copyright binary be published into universe component, or should enabled multiverse in ubuntu-touch-meta?
<xnox> infinity: s/and/can/
<infinity> xnox: That sentence needs more English.
<xnox> infinity: yeah, let me try again.
<xnox> infinity: i have a weird request -> could you move bin:android-copyright (built by a source package in multiverse) be published into universe component. Or instead should I be enabling multiverse component in ubuntu-touch-meta package, since it needs android-copyright seeded.
<seb128> infinity, let's say I'm just glad we don't have security fixes for webkit, qt and webkit, or we would block the archive for a week :p
<infinity> xnox: multiverse source packages can't build binaries in universe, no.
<xnox> infinity: ok.
<infinity> xnox: Which part of Android's license makes it non-free?
<infinity> (I haven't looked, just curious)
<infinity> Or do we have binary blobs in there or something? :/
<bdmurray> infinity: someone wants to do an SRU for d-rats to multiple releases with the same package version? Is that possible?
<infinity> bdmurray: Sort of.
<infinity> Given that it's already the same version, it's not unacceptable to suggest maintaining that status quo.
<infinity> bdmurray: What would need to happen is an upload to precise, -3ubuntu0.1, and then copy it with binaries to Q/S
<bdmurray> Ah, so you can't copy it from S to Q/P?  I already approved the Saucy SRU.
<infinity> bdmurray: Depending on how anal you are, you can copy to Q/S-proposed and make them verify three times, but at least it only needs to be uploaded once.
<infinity> bdmurray: No, can't copy back.  (Well, you can, but you'll probably break it).
<infinity> bdmurray: We guarantee no toolchain backward compatibility, only forward. :P
<infinity> So, in the case of C stuff, you'd get a libc dep too high, for instance.  In this case (python mess), maybe the dh_pyupport or other debhelper bits try to do something that older releases hate.
<bdmurray> infinity: okay, thanks.
<infinity> bdmurray: Pretty much a lost cause at this point, just ask them to do a precise SRU as well.  And I wouldn't bother with Q, unless it's a seriously nasty bug.
<bdmurray> well the app doesn't work at all
<infinity> Doesn't work at all seems alright, to be honest. :P
<infinity> No one who's been running quantal for the last year is relying on that app, I'd assume.
<infinity> But, up to the uploader and you if they want to do it.  *shrug*
<xnox> infinity: binary blobs, which are included in the built images, which came from the other package.
<xnox> infinity: android-src-vendor, is in multiverse, is a build-dep of android package. and blobs from android-src-vendor included in android.
<xnox> infinity: the non-free bit of their license is "non-commerical usage"
<infinity> xnox: Well, the binary blobs are non-free entirely. :P
<xnox> and well the fact that those blobs are without source and not-modifyable.
<infinity> xnox: So, yeah, build-depending on that explains it.
<xnox> infinity: so i need to enable multiverse on ubuntu-touch-meta, since althought android-copyright is seeded, it wasn't actually so far been included on the images and thus our legal tab, doesn't show all the notices it should.
<stgraber> beta1: publishing done, waiting for mirrors to update and torrent to publish
<apachelogger> \o/
<stgraber> to make things all round and nice, let's say I'll send the announcement in 45min
<xnox> infinity: hm, that will not help, as multiverse component is not enabled on the touch images... (well at least in apt-sources), but i think it wouldn't be enabled during image builds. And i don't want to break touch image generation....
<stgraber> that should be enough for bittorrent and leaves some more time for Kylin to update the announcement text (or I'll just point to their website and call it done)
<infinity> xnox: It could be enabled.  *shrug*
<infinity> xnox: Or you could build the copyrights thing from a free source package. :P
<xnox> infinity: yeah, i don't want mutliverse enabled thought.
<xnox> infinity: cause that has a potential flood gate.
<infinity> Which flood gate is that?
<xnox> infinity: right, let me work on extracting them properly into a standalone package.
<xnox> infinity: well, things that are seeded and have depends | multiverse-package.
<xnox> infinity: or i could get android package into restricted, and complete it's m.i.r.
<stgraber> amjjawad, knome, elfy: I see you guys jumped the gun a bit ;)
<amjjawad> stgraber, I didn't send anything yet but about to
<knome> stgraber, yeah, oops, i quickly saw the topic change on this channel and thought it was out so...
<knome> my bad
<stgraber> amjjawad: I just saw your announcement in my rss feed
<knome> don't blame elfy
<knome> (this time)
<amjjawad> I finished the post on our website already
<amjjawad> but didn't send anything yet
<amjjawad> I however had to update the link on the website :)
<stgraber> amjjawad: well, your post is on planet.ubuntu.com already ;)
<amjjawad> so now, I can safely send with a working link ;)
<amjjawad> Xubuntu team were a bit hurry ;)
<amjjawad> stgraber, oh, that was quick hehe
<stgraber> anyway, doesn't really matter, though I expect the torrent links to still be broken at the moment.
<elfy> stgraber: I try to keep him under control - but it's not easy :)
<stgraber> elfy: haha :)
<ScottK> cjwatson: Subscribed.  Thanks.
<stgraber> beta1 announce is out
<stgraber> cjwatson, slangasek: can one of you let my e-mail to u-d-a through please?
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Beta 1 | Archive: feature freeze | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
#ubuntu-release 2014-02-28
<JackYu> stgraber, done:).
<darkxst> anyone able to look at gnome-online-miners in NEW?
<apw> jibel, i think the linux autopkgtest testing for amd64 has broken at the testbed stage, we really ought to make that not a test failure, but a third type
<ogra> test failre, test success and test wonky ?
<xnox> ogra: if no tests managed to run the state is unknown. it tells nothing about the test success-rate. I'd expect wonky to be something that is flapping between pass & fail, with no good reason (e.g. racy)
<jibel> apw, right. BTW it will likely fail again with no space left on device. But the disk size is already set to 40G and there is only 96GB left on the machine so if 2 tests run in parallel it'll quickly kill the host.
<ogra> xnox, heh, ok
<jibel> apw, is there any change in -14 that made the kernel become much bigger on amd64?
<jibel> in this case it is not wonky or unknown, it is ENOSPC
<apw> jibel, checking
<apw> jibel, nothing stands out, the resulting binaries seem in the normal ball park, and the changes to the source are minimal
<apw> jibel, how much space are we allowed to consume when building
<jibel> apw, 40GB, how much space do you need?
<apw> about 5 i would say
<jibel> apw, it is already 37G Feb 28 10:22 trusty-amd64-linux-20140228_085329.GIxHVG.img and will crash in 3
<xnox> apw: launchpad tells me that build needed "1747884k disk space" is that lies, or was there cleanup done along the way? what does adt test do to require so much space?
<xnox> apw: can we do intermediate clean-ups at all?
<jibel> apw, actually the build tree is 12GB, we need twice that size because adt does a copy but we run out of inodes
<apw> jibel, ok based on what i have here, it is 11G per flavour, and you have the thing set to say it is autopkgtest which only builds one flavour
<xnox> jibel: would declaring access to writable tree help? (then no copy is done?!)
<apw> yeah 12GB is believeable, we do have a heck of a lot of files and always more
<apw> so somewhere we have doubled from 5ish to 11ish, which i suspect is the new module signing stuff
<apw> but we should cap out at that
<apw> to be honest this is one of those cases where the testing config is not rich enough, and we don't want linux testing run on linux, only on deps of linux
<apw> (or is that rdeps, but you get my drift)
<apw> can we test which package we are testing on behalf of ?
<jibel> apw, we have this info but no exclusion rule like "don't test myself". Currently when a new kernel is uploaded it triggers a test of the kernel and eglibc
<ockham> could someone grant me an FFe, please? https://bugs.launchpad.net/ubuntu/+source/gourmet/+bug/1286073
<ubot2`> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
<xnox> jibel: but can the trigger reason be included in the environment? e.g. that way adt tests in linux package whould check that environment variable and do "exit 0" straight away without doing anything.
<jibel> xnox, yes, I can probably extend the system of overrides used to define a specific environment to support this, and add something like if the cause is myself then skip the test. But I need to think a little bit because the causes of the test and the definition of the environment are physically in 2 different places. And I don't want to spread too many configuration files all over the place.
<ockham> ^ anyone, pls?
<xnox> jibel: i don't think it's a good idea to define policy in the infrastructure. it's just a test is free to act/test different things depending on what triggered it.
<apw> xnox, jibel, if i knew via environment or whaever in my test i assume i could write one to do it right
<infinity> ockham: So, a few things: (a) why the added ipython Recommends?  (b) can you get it updated in Debian instead and ask for a sync?
<infinity> ockham: None of the upstream changes look like they need an FFe, it's just simple bugfixes.
<infinity> ockham: But the ipython Recommends is a bit heavy unless that one file/interface is a critically important part of the overall package.  If it's not, I'd suggest dropping that to Suggests.
<infinity> ockham: And I'd definitely suggest forwarding any packaging improvements to Debian instead of forking in Ubuntu.
<ockham> infinity: thx a bunch for reviewing this! answered your questions over at the bug report.
#ubuntu-release 2014-03-01
<darkxst> infinity, can you take a look at gnome-online-miners in NEW ( I assume it doesn't need an FFe since it was uploaded before freeze?)
<infinity> darkxst: I'll try to get to it.  Running around like a crazy person tonight before an early flight tomorrow.
<infinity> darkxst: And no, it's probably fine without an FFe.  In fact, unless it's being added to a seed, a new package likely doesn't need an FFe at all.
<darkxst> it will be seeded on ubuntu-gnome
<infinity> Alright, then it sort of should have one, but meh.  Verbal FFe preliminarily granted, assuming it passes NEW review. :P
<darkxst> infinity, thanks!
<ockham> i'd like to ask how to proceed with https://bugs.launchpad.net/bugs/1286073
<ubot2`> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
<ockham> infinity: ^
<xnox> Please remove motion and minidlna, bug 1253071. That is the last two holding up libav8 (nbs). The rest is ported.
<ubot2`> Launchpad bug 1253071 in motion (Ubuntu) "Removed from testing, RC-buggy, FTBFS against libav9" [Undecided,Triaged] https://launchpad.net/bugs/1253071
<Noskcaj> Can someone please look at bug 1282937
<ubot2`> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,Confirmed] https://launchpad.net/bugs/1282937
#ubuntu-release 2015-02-23
<flexiondotorg> infinity, Are you about?
<bjf> moin
<cjwatson> proposed-migration is now running by default for trusty and utopic (in no-automatic-copies mode).  I also tweaked the control scripts to make sure proposed-migration runs again if any tests are in progress, so that we don't get stuck if the archive doesn't change but say an autopkgtest finishes.
<rbasak> cjwatson: o/
<rbasak> cjwatson: this is https://bugs.launchpad.net/ubuntu/+bug/1321691 ?
<ubot93> Launchpad bug 1321691 in Ubuntu "autopkgtest test suites are not automatically run against SRU uploads" [Undecided,New]
<rbasak> Or something else?
<cjwatson> Oh, I didn't notice that
<cjwatson> (recently)
<cjwatson> bdmurray: Would you be up for attempting to integrate stable release autopkgtests into pending-sru.html?  The best approximately machine-readable form is probably http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.yaml
<cjwatson> Though we should get rid of the HTML tags from that IMO
<cjwatson> Well, maybe
<cjwatson> Anyway if we knew that u-a-t was using it we could take appropriate care about compatibility
<bdmurray> cjwatson: yes, of course
<cjwatson> lovely, thank you
<bdmurray> what am I looking for in update_excuses?
<cjwatson> anything with the reason set to autopkgtest
<cjwatson> in which case the excuses field will contain more detail
<cjwatson> we could perhaps argue that anything with is_candidate: false should at least be a yellow flag to SRU admins
<cjwatson> and reason/excuses are refinements of that
<cjwatson> that may take a while to settle down though
<cjwatson> yeah, on reflection I think is_candidate: false is the top-level thing to look for
<bdmurray> got it
<apw> cjwatson, how often are those running ?  and are the <series>/* results the right ones?
<cjwatson> apw: any time the relevant suites change and also now any time tests are still in progress, same as vivid; and yes
<cjwatson> saw no reason to invent new logic there
<apw> cjwatson, hmm, i have been looking at the generated-date: to confirm proposed-migration is running to completion, that seems flawed in the light of that
<apw> cjwatson, is there some way i can tell otherwise?
<cjwatson> apw: if I understand correctly then you could look at http://people.canonical.com/~ubuntu-archive/proposed-migration/log/trusty/ etc. instead
<cjwatson> if it has "Finished at:" at the end then it's good
<cjwatson> the last log
<apw> cjwatson, wergely 9m that last log
<cjwatson> the same strategy was always flawed in principle for the development suite, it's just that it changes all the time
<cjwatson> apw: yeah that's mostly because it's noticing vast piles of binary differences and applying a Debian-specific "smooth updates" thing; I need to work out how to turn that off correctly
<apw> cjwatson, yes indeed, as you say i thought it was safe, because it always runs, i don't think i am downloading that heap to work it out though
<cjwatson> I'll try to do something about that this week if I don't get hopelessly distracted
<cjwatson> Since the log volume will become a problem over time
<apw> cjwatson, it might be that i want to know when the last update to the pocket was, and that proposed migration finished since then
<cjwatson> Perhaps we should put this in the SRU report
<cjwatson> Though it seems slightly like human nagios :-)
<elfy> Laney: is it you who's going to be sorting the vervet beta1 images tomorrow?
<Laney> yes sir
<flexiondotorg> Is there anyone here who can review some uploads for Ubuntu MATE that are awaiting review in the upload queue?
<elfy> Laney: cool - timezones should be a bit easier then - what time do you think you'll be firing it up?
<Laney> Dunno, morning?
<elfy> okey - afaik the wiki I set up is right, I'll be gone before you're about likely, around lunchtime then 4ish
<elfy> by wiki - I mean I assume that those taking part have said yes
<Laney> seemed okay from what I was expecting
<elfy> yep
<cjwatson> slangasek: did you get a chance to look at https://code.launchpad.net/~cjwatson/britney/dynamic-arches/+merge/250462 ?
<cjwatson> (thanks for merging the rest of my stack!)
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu/+bug/1423597 (MAATE Tweak)
<ubot93> Launchpad bug 1423597 in Ubuntu "[needs-packaging] mate-tweak" [Wishlist,New]
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu/+bug/1423581 (MATE Menu)
<ubot93> Launchpad bug 1423581 in Ubuntu " [needs-packaging] mate-menu" [Wishlist,New]
<cjwatson> Ah, there are the MATE tasks now
 * cjwatson kicks off a fresh build
<cjwatson> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate/+build/20555 is the amd64 build
<cjwatson> Oh
<cjwatson> I forgot to devirt that
<cjwatson> Bah and thrice bah.  Cancelling
<flexiondotorg> cjwatson, Thanks for your help. I really appreciate.
<cjwatson> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate/+build/20557 should be better
<cjwatson> Looks like there's been a batch of KDE uploads, though, so there's a bit of a queue.
<flexiondotorg> cjwatson, Thanks. I'll check on that later.
<wxl> Laney: any clues as to what time tomorrow beta 1 images will be available?
<flexiondotorg> cjwatson, Does this mean it worked? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate/+build/20557
<cjwatson> flexiondotorg: Looks promising.  It's waiting on a few other things - http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/vivid/daily-live-20150223.1.log is updated every 15 minutes
<cjwatson> I'm just watching it on the build system
<flexiondotorg> cjwatson, So would that job you started produce a cd image? Or is that just a job for the livefs?
<cjwatson> It should do the whole thing
<cjwatson> The livefs is built on Launchpad and then the rest of it assembled separately
<flexiondotorg> cjwatson, Thanks for the info. Will be interesting to see what it does, if anything.
<cjwatson> flexiondotorg: http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/
<flexiondotorg> cjwatson, Wow! Brilliant.
<flexiondotorg> cjwatson, Thanks for your help. I'll give it a test and see what is busted.
<cjwatson> flexiondotorg: You can probably reasonably ignore the oversized warning for now, since the size limit is a bit arbitrary anyway, but perhaps there's stuff there that shouldn't be.  Anyway, it's more important to see whether it works at all first.
<flexiondotorg> cjwatson, I think I ship way more language than the other flavours.
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-mate.vivid/ may be useful too.
<flexiondotorg> cjwatson, Thanks.
<cjwatson> flexiondotorg: I've set it to build nightly, now that it at least somewhat works.
<cjwatson> So hopefully you can take it from here.
<flexiondotorg> cjwatson, Excellent. I taken some days of work later this week to try and knock everything into shape.
<cjwatson> Great.
<infinity> flexiondotorg: Sorry, on a call.
<flexiondotorg> infinity, No problem ð
<flexiondotorg> infinity, I've pushed the copyright changes, updated the original package requests. I think cyphermox is going to upload them.
<cjwatson> finally, lp:ubuntu-cdimage tests pass again
<cjwatson> hopefully they can be kept that way :P
<cjwatson> stgraber: I guess "Ubuntu MATE Desktop amd64" and "Ubuntu MATE Desktop i386" should exist on the tracker at some point now?
<elfy> is that going to impact on beta tomorrow?
<cjwatson> what, mate?
<elfy> yea
<cjwatson> I don't see how
<elfy> if it's going on tracker
<cjwatson> won't make a difference
<elfy> cjwatson: by impact I mean - do they want to do that
<cjwatson> I think you misunderstand
<elfy> probably
<cjwatson> all the images we build should exist on the tracker
<cjwatson> that's not the same as tracking them for a particular milestone
<cjwatson> it means that they can be tracked for milestones in the future
<elfy> yes I understand that - just assuming that if it is on the tracker that Mate would want to use *it*
<cjwatson> well, that's up to them
<cjwatson> but I would like the error messages from cdimage about the lack of tracker support to go away :)
<elfy> :)
<elfy> I can understand that as well :p
<cjwatson> I would think that it's far too late for ubuntu-mate to be ready for beta
<cjwatson> I could be wrong, but it would be pretty exceptional speed even if working full-time on it
<cjwatson> and I understand not all their packages are in yet
<elfy> right - actually only asked as I wasn't awake and I  put my name down onReleaseTaskSignup :)
<flexiondotorg> elfy, Remember you said you'd show me round the QA stuff ð
<flexiondotorg> cjwatson, There are 3 packages missing.
<flexiondotorg> 2 of those are in the upload queue.
<cjwatson> elfy: fair enough :)
<cjwatson> flexiondotorg: *nod*
<flexiondotorg> cjwatson, So would you expect to ubiquity to fail if there are missing packages?
<flexiondotorg> Still downloading the iso...
<elfy> flexiondotorg: I can't find that anywhere in my logs :p
<cjwatson> flexiondotorg: Probably not; it'll mostly be copying the filesystem it's given
<elfy> flexiondotorg: place for that with me would be #ubuntu-quality though
<flexiondotorg> cjwatson, Interesting, thanks.
 * flexiondotorg goes to join #ubuntu-quality
<flexiondotorg> cjwatson, Initial testing is positive ð
<cjwatson> Cool.  No need to tell me about further progress though, I was just the build monkey :)
<flexiondotorg> cjwatson, It might be suitable for Beta1. Is that even possible at this stage?
<cjwatson> I don't know, ask the people driving it
<cjwatson> https://wiki.ubuntu.com/VividVervet/ReleaseTaskSignup
<cjwatson> It would be pretty amazing to be able to do a milestone three days after your first images roll out, but I guess it's possible
<elfy> flexiondotorg: as far as I'm concerned - all I'd want to know is that you wanted to take part and that Ubuntu MAte was on the beta1 wiki before I wander off in the morning
<elfy> https://wiki.ubuntu.com/VividVervet/Beta1
<flexiondotorg> elfy, I want to participate.
<flexiondotorg> elfy, I have updated https://wiki.ubuntu.com/VividVervet/Beta1
<flexiondotorg> elfy, Although it looks like my changes need approving.
<elfy> it was there - dodgy wiki error - I moved you though :)
<balloons> stgraber, actually I have no permissions to set owners on iso.qa.ubuntu.com.. can you fix that?
<elfy> Laney: just in case you don't notice - Mate added to Beta 1 run
<flexiondotorg> elfy, Thanks.
<bdmurray> cjwatson: only use update_excuses for Trusty and Utopic though correct?
<stgraber> balloons: so what's the LP team for MATE access to the tracker?
<elfy> https://launchpad.net/~ubuntu-mate-release
<elfy> stgraber: ^^
<stgraber> ok, access updated
<elfy> ty stgraber - I see that here
<cjwatson> bdmurray: For now, but it'll hopefully exist for precise fairly soon too.  Never lucid though.
<bdmurray> cjwatson: something like this? http://people.canonical.com/~brian/tmp/sru-report.html
<cjwatson> bdmurray: looks pretty good!
<cjwatson> (modulo lack of line breaks and such in a few places which I'm sure you've spotted)
<cjwatson> but yeah, that's pretty close to what I was thinking of.  Indeed probably doesn't make sense to introduce a new column and have the page be even wider
<bdmurray> cjwatson: right, I'll fix that up
<bluesabre> I don't seem to be able to upload thunar to vivid/vivid-proposed... "The signer of this package is lacking the upload rights for the source package, component or package set in question." I still appear to be in the packageset, http://people.canonical.com/~ubuntu-archive/packagesets/vivid/xubuntu - any idea whats going on?
<ScottK> bluesabre: Seems a bit odd.  It's in mythbuntu and studio, but not xubuntu
<bluesabre> ScottK: don't suppose there's an easy resolution? :)
<ScottK> Easy is ask Laney and wait.  Won't be quick however.
<bluesabre> ok, np
<bluesabre> Thanks ScottK
#ubuntu-release 2015-02-24
<bluesabre> also unable to upload light-locker
<bluesabre> Laney: Can you take a look at your convenience? :)
<Laney> bluesabre: done
<Laney> you had added a new 'core' seed which our script wasn't looking at
<Laney> ochosi: fyi
<Laney> elfy: ready to get freezy and imagey?
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Alpha 2 | Archive: Beta 1 freeze, Feature Freeze | Vivid Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<Laney> cron builds are off
<Laney> spins spinning
<apw> Laney, can i assume freeze blocks are in place?
<Laney> that would be a safe assumption
<apw> awsome, thanks
<Laney> go forth and break vivid-proposed!
<apw> :)
<bluesabre> Laney: thanks!
<bluesabre> Release team: With xfce 4.12 due to be released this weekend, the Xubuntu team would like to include it in vivid.  Since we've been carrying development versions of each component since 14.04, the releases will be largely bug fixes with a major version number bump.
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887
<ubot93> Launchpad bug 1424887 in xfwm4 (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,New]
<bluesabre> Can we get an ack to include these latest versions?
<ScottK> bluesabre: Approved.
<bluesabre> ScottK: thanks!
<bluesabre> Also, you're always awake :)
<ScottK> Meh.  Sleep is for the weak.
<bluesabre> :D
<cjwatson> Laney: Would you have a minute to review/merge https://code.launchpad.net/~cjwatson/britney/dynamic-arches/+merge/250462 for me?  I'd really like to be able to enable non-copying proposed-migration runs for precise.
<cjwatson> Would let me cross that task entirely off my list.
<Laney> cjwatson: Alright
<Laney> Now what's it doing? Taking the original config file and substituting the list of arches to create a per series one
<cjwatson> Laney: Right
<cjwatson> I could make the whole thing be explicitly a template but it doesn't really matter
<sil2100> Hello release team! We have an unity8 landing ready to be released, but one part of the changes in it might be considered a new 'feature'
<sil2100> The developer says that partially it's a feature, but also fixes a bug when running on the desktop
<sil2100> https://code.launchpad.net/~mzanetti/unity8/reveal-launcher-with-mouse-hover/+merge/248913
<sil2100> Should we fill in an FFe for it, or can I publish it as it is?
<ScottK> sil2100: It is a new feature that should have an FFe, but looking at the merge proposal, I'm willing to say "FFe granted" right now, so consider it done.
<sil2100> ScottK: oh, thanks - would we need to fill in an FFe bug for it anyway, or can we simply let it in without a formal one?
<Logan> sounds like you don't need to ;)
<sil2100> o/
<elfy> Laney: thanks :)
<Laney> cjwatson: done - are you going to take care of enabling?
<elfy> Laney: is there something awry with Mate for the Beta 1 ?
<Laney> like what?
<elfy> like it's not showing
<Laney> hmm
<Laney> it's still "(re-building)"
<Laney> why might that be?
<Laney> Invalid entry 'Ubuntu Mate Desktop amd64' for 'vivid'
<Laney> Invalid entry 'Ubuntu Mate Desktop i386' for 'vivid'
<elfy> no idea personally - though Mate is all new ofc
<flexiondotorg> Laney, wish I could help. Ubuntu MATE was manually built yesterday and then via the nightlies.
<cjwatson> Laney: Brilliant, thanks, and yes.
<cjwatson> Laney: Oh it's just a case disagreement
<Laney> Yes, fixed
<cjwatson> You fixed it in cdimage?
<Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate/+build/20690 etc
<cjwatson> I think I'd have changed the tracker
<cjwatson> But whatever :)
<Laney> Yeah. Could have, but I'd already got to the file. :P
<elfy> thanks Laney
<elfy> disappearing again for a couple of hours
<Laney> woot
<cyphermox> yay
<ogra_> wow
<flexiondotorg> Laney, cyphermox Thanks!
<flexiondotorg> I've been keeping a list of all that helped. You've all been great.
<flexiondotorg> Laney, so I'm new at this. What happens now with Beta 1?
<flexiondotorg> Laney, Is that it or is there time to test and fix?
<Laney> flexiondotorg: There's time until Thursday afternoon-ish
<Laney> flexiondotorg: Generally flavours do QA on the ISO tracker (https://wiki.ubuntu.com/Testing/QATracker)
<Laney> Report any bugs you find there, fix any you consider critical (ones which bust the image)
<flexiondotorg> Laney, and between now and then are the archives frozen?
<Laney> Once you're happy, before the cut-off of late Thursday afternoon Europe time, mark it as ready on the tracker then it gets included in the release
<flexiondotorg> For example, will nightlies effectively be Beta 1?
<Laney> We freeze all of the packages which are on the flavours participating in the release
<Laney> And turn off nightlies. Good point - if you need a fix in, you need to get the release team to unblock it and then you need to manually (via the ISO tracker) request a new image to be built.
<flexiondotorg> What about seeds? Will germinate updates happen?
<Laney> You should have access to do this for MATE via the tracker
<flexiondotorg> Laney, I do.
<Laney> If not, grab stgraber because I don't know how to set that up. :)
<flexiondotorg> Tracker is up. Have 2 QA guys who know the ropes.
<Laney> I think germinate happens from bzr checkouts
<Laney> Just the meta package requires a real upload (AFAIK)
<Laney> flexiondotorg: As far as we're concerned, be marked as ready by the time we want to release (people will start hassling you if you're not).
<Laney> On your side, do whatever QA you want to be happy ticking that box.
<Laney> You can add new test cases to the ISO tracker if you like - Ubuntu desktop has some if you want inspiration
<flexiondotorg> cjwatson, You know we discussed no-recommends earlier.
<flexiondotorg> cjwatson, There is an issue in that gnome-settings-daemon has been pulled in and Ubiquity is not using all the MATE gsettings.
<flexiondotorg> cjwatson, Laney If I prepare updated seeds and meta package can they be uploaded ahead of Beta 1 release?
<flexiondotorg> cjwatson, Laney What else do I need to do other than prepare pages?
<flexiondotorg> *packages?
<Laney> flexiondotorg: Just update the seeds, any sponsor can generate the package themselves
<bdmurray> cjwatson: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/autopkg-excuses/+merge/250795
<flexiondotorg> Laney, I've pushed changes to the seeds.
<Laney> flexiondotorg: what's the address of the branch?
<flexiondotorg> Laney, Would you sponsor generating the ubuntu-mate-meta package generation?
<cjwatson> bdmurray: can you drop the release != 'trusty' bit?  duplicates the following test, and we should be able to get utopic too
<flexiondotorg> Laney, lp:~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
<flexiondotorg> Laney, however this change also mean a little change to ubuntu-mate-artwork.
<cjwatson> bdmurray: also seems like it would behave weirdly as pkg_excuses isn't initialised otherwise
<flexiondotorg> Laney, how should I proceed with requesting a new package release for that?
<cjwatson> oh in fact you just lose whole sections of the report otherwise don't you?
<bdmurray> cjwatson: yeah, that was for testing removing!
<Laney> flexiondotorg: who's your previous sponsor?
<bdmurray> cjwatson: updated
<cjwatson> bdmurray: should we show tests in progress too?
<flexiondotorg> Laney, several.
<cjwatson> if it's still in progress after the timeout there's something wrong, of course, but it seems like maybe it'd be good to see
<flexiondotorg> cyphermox, Could you be helpful again?
<Laney> Maybe one of those could do the needful
<Laney> Otherwise I might be able to tomorrow
<flexiondotorg> Laney, are you doing the meta package or shall I ask a sponsor to help with both?
<Laney> I'll do meta
<flexiondotorg> Laney, thanks.
<bdmurray> cjwatson: okay, I'll have a look at in progress test support
<cjwatson> I think it should be a one-liner
<cjwatson> 'Test in progress' is the key
<cyphermox> flexiondotorg: hey, what with?
<flexiondotorg> cyphermox, I new ubuntu-mate-artwork release please.
<Laney> flexiondotorg: Are you aware that your meta package is blocking on mate-menu & mate-tweak?
<cyphermox> flexiondotorg: ok, just point me to the code and I'll sponsor
<flexiondotorg> Laney, I realise that mate-menu (in the upload queue) and mate-tweak are missing.
<flexiondotorg> Laney, Does that prevent making a new meta package?
<flexiondotorg> cyphermox, Thanks - bzr branch lp:~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
<cjwatson> Laney: germinate-update-metapackage should omit those since they're not in the archive
<flexiondotorg> Laney, what is the authoritive bzr repo for ubuntu-mate-meta now?
<Laney> cjwatson: Seems someone has configured ubuntu-mate-meta to use a PPA
<cjwatson> *-meta aren't typically stored in bzr
<flexiondotorg> Laney, because it has been uploaded with the old PPA references in it. Which I am more than happy to fix.
<cjwatson> Laney: ugh, that should surely be ripped out now that it's in the archive
<Laney> Yes
<cjwatson> caja-actions too
<Laney> That's gone in bzr
<cjwatson> OK
<flexiondotorg> I'm happy to do the PPA removal. Just seeking clarification which bzr repo is authritative for ubuntu-mate-meta now/
<flexiondotorg> ?
<cjwatson> flexiondotorg: I did clarify that
<cjwatson> You appear to have one historically, but I would recommend that the answer be "none"
<cjwatson> They're a waste of effort for what's largely autogenerated
<cjwatson> And since other *-meta don't have them, other developers are unlikely to remember to commit to them, so they'll become out of date
<flexiondotorg> cjwatson, OK. Are the meta package automatically regenerated?
<cjwatson> The process of uploading *-meta is typically to run ./update and build a new source package
<flexiondotorg> cjwatson, Understood.
<cjwatson> Anyway, just my recommendation
<cyphermox> flexiondotorg: changelog in ubuntu-mate-artwork doesn't match what got uploaded before, could you please fix that?
<flexiondotorg> cyphermox, Sure.
<flexiondotorg> cyphermox, It is a new version though.
<cyphermox> yes
<cyphermox> but we should keep track of the changelog as it gets uploaded, etc.
<cyphermox> for example, you got ubuntu-meta-artwork 0.4.2ubuntu1 in the archive, it probably should just have been 0.4.2, and it's not at all in debian/changelog in the branch
<flexiondotorg> cyphermox, Sorry. I see what you mean. One sec.
<Laney> flexiondotorg: I can fix update.cfg directly and drop Vcs-* from debian/control if that's what you want
<flexiondotorg> Laney, fine with me.
<Laney> Okay
<flexiondotorg> cyphermox, ubuntu-mate-artwork should be good now.
<cyphermox> alright
<Laney> flexiondotorg: okay, uploaded, I guess you're going to want this in the beta?
<Laney> ah, it's not blocked anwyay (because it isn't in release) - never mind
<flexiondotorg> Laney, yes please. But, I'd also like ubuntu-mate-artwork in the archive is possible.
<flexiondotorg> *if possible.
<Laney> Let one of us know when that's uploaded
<infinity> Laney: Hey, what's the story on Beta1?  Would you hate me if I slide a new kernel in from proposed (ie: are people pretty much guaranteed to still be respinning right now?)
<Laney> infinity: I only know of MATE planning it, maybe elfy knows more
<elfy> infinity: I don't know of anyone doing so
<infinity> elfy: Okay, so at this point, the current images are RCs?
<infinity> elfy: If so, I won't go breaking your freeze. :P
<infinity> elfy: But let me know if I can slip that kernel in due to some other rebuild triggering event.
<infinity> (ie: ubiquity bug causing the world to respin, whatever)
<elfy> well I've got one atm
<elfy> just need to check it in kvm and hardware
<elfy> bug 1425047
<elfy> bug 1425047
<flexiondotorg> elfy, I'll take a look at #1425047 also
<infinity> elfy: Curious.  The installation looks like it makes it all the way to the end (removes the live stuff, installs non-free and updates target), so I'd need more to go on than the description.
<elfy> well I thought it might help to do that debug ubiquity business from the other night with cyphermox - so just doing that
<elfy> sorting a usb to boot hardware from as well
<cyphermox> elfy: what debug business?
<elfy> cyphermox: sorry - didn't mean to ping you ... just the bug you fixed for us - using that knowledge I picked up :)
<cyphermox> oh, I thought you meant you were working on some other fix
<cyphermox> I see I just misparsed the sentence above
<cjwatson> bdmurray: proposed-migration is on for precise now too.
<mlankhorst> can someone accept libdrm / armhf ?
<flexiondotorg> infinity, If you have the time please take a look at mate-tweak and mate-menu in the upload queue ð
<infinity> flexiondotorg: Getting there.
<elfy> infinity: mmm so kvm just boots to a blank desktop here
<flexiondotorg> infinity, Thanks ð
<infinity> elfy: Blank destkop, as in the invisible ubiquity bug is back? :(
<infinity> cyphermox: ^-- I think this is all you.
<elfy> infinity: in kvm - possible I don't have it set up properly though - that's new to me
<elfy> and hardware is not looking good either - just redoing that
<elfy> I've added the debug logs from running aybe-ubiquity debug-ubiquity on this in vbox to the report
<infinity> elfy: I don't use any of the pretty frontends, but if you have a disk image (ie: a massive empty file), you can just "kvm -hda disk.img -cdrom my-testing.iso" and it should give you something plausibly useful.
<elfy> mmm - did something like that the other day and managed to fill / :p
<infinity> Oh, also needs '-m 2048' or similar, since the default machine's memory size is STUPIDLY TINY.
<elfy> :)
<infinity> elfy: Grabbing your latest i386 ISO and running a test install in the background to see if I can reproduce that bug.
<elfy> thanks
<elfy> infinity: ok - seeing exactly the same on hardware here
<cyphermox> infinity: doh
<elfy> though - if you reboot - all of these appear to have installed
<elfy> lubuntu appears to work
<wxl> you're DARN tootin it works
<elfy> well ... it installs :p
<wxl> xubuntu doesn't?
<elfy> kinda
<wxl> hm i guess not huh
<wxl> let me guess
<wxl> (def var (fn
<wxl> yeah see i was getting there :)
<wxl> maybe
 * wxl likes explicit
<elfy> install with something else works from livesession - without livesession - appears to crash at the end
<elfy> but it boots if you reboot
<wxl> oh man
<wxl> sorry for all the lispy b.s.
<wxl> wrong channel
 * wxl cries
<infinity> elfy: +1 for Grumpy Cat being the avatar for the example user in your slideshow.
<elfy> lol
<cyphermox> elfy: so is ubiquity still busted?
<cyphermox> looks fine to me with a one-shot very unscientific test in kvm ;)
<elfy> cyphermox: right - boot to the menu - install not try
<elfy> installs ok - then crashes seemingly - but boots fine
<elfy> I've seen this happen 3 times in vbox, twice on hardware
<infinity> elfy: Any specific options need to be picked, or just a default install?
<elfy> just install rather than try
<infinity> Oh, hrm.
<infinity> Yeah, got to the end and the ubiquity window just went poof.
<cyphermox> elfy: ah, but that's something quite different
<elfy> installing from within the livesession - works
<cyphermox> ok
<elfy> cyphermox: than what?
<cyphermox> elfy: than what I last fixed
<cyphermox> do you have a bug report open?
<infinity> cyphermox: After removing live stuff and setting up langpacks, etc, ubiquity seems to have just... Disappeared.
 * cyphermox starts the install
<elfy> cyphermox: oic - yea - I didn't say it was the same thing - blame infinity foir that :)
<infinity> elfy: How do I get a terminal here?
<elfy> in install rather than try you'd need vt1 or something
<elfy> nothing available other than that
<cyphermox> elfy: maybe we should put in a hook just so that it's a bit easier
<cyphermox> ie. Super-T or Ctrl-Alt-T to open a terminal
<elfy> cyphermox: bug 1425047
<ubot93> bug 1425047 in ubiquity (Ubuntu) "Install (manual partitioning) in Xubuntu Desktop i386 for Vivid Daily doesn't finish installation" [High,Confirmed] https://launchpad.net/bugs/1425047
<cyphermox> thanks
<cyphermox> only manual or does entire disk do the same?
<elfy> seemingly only manual
<elfy> I'll check entire now
<cyphermox> heh
<cyphermox> here ubiquity doesn't show up :/
<cyphermox> infinity: can't you right-click the desktop to get a menu in xubuntu ?
<elfy> you can - but it's pointless
<elfy> cyphermox: yea - no ubiquity
<cyphermox> elfy: I didn't even get to start the installation
<cyphermox> trying to open a terminal gets me a terminal, but way off-screen
<cyphermox> ugh
<infinity> cyphermox: entire disk blew up the same for me.
<cyphermox> infinity: ok, that's what I hoped... I didn't want to come up with some weird partitioning scheme :)
<infinity> And hah, you're right, the right-clicked terminal totally "works", it's just not anywhere I can see it.  It's running, though!
<infinity> How amazingly unhandy.
<bdmurray> cjwatson: ack
<cyphermox> infinity: right side, hover the pointer near the edge and you'll see a different cursor
<cyphermox> you can resize the terminal to get to it
<cyphermox> (or anyway, I could)
<infinity> cyphermox: So, ubiquity seems to still be running.  I imagine it's meant to be showing me a "hey you, I'm all done, wanna reboot?" dialog.  So maybe it's the same visibility issue in another spot.
<cyphermox> I bet this is the same crap ubiquity was doing, so it's not fixed properly
<cyphermox> infinity: likely
<cyphermox> I bet none of it is visibility, it's all location on screen
<cyphermox> that is, if you can get your terminal the way I suggested
<infinity> Possibly, yes.
<infinity> I can't find the terminal, it's lost forever. :P
<cyphermox> nah
<infinity> But alt-tab shows both ubiquity and the terminal hiding... Somewhere.
<cyphermox> you don't see any weird white line near the edge of the screen?
<infinity> And yes, the ubiquity window is titled "installation complete".
<infinity> So, it's done, it's just off screen somewhere.  Or something.
<cyphermox> yuck
<cyphermox> infinity: you doing this in kvm?
<infinity> cyphermox: Yeah.
<cyphermox> ok
<cyphermox> infinity: scratch the cursor part, it doesn't show up, but I can still drag from the higher half of the right side of the screen to resize a terminal window
<infinity> It's starting to smell like an xfce or gtk bug, maybe.
<infinity> Or, I guess, ubiquity-dm is setting up an incorrect workspace layout.
<cyphermox> yeah
<cyphermox> but there aren't multiple workspaces
<cyphermox> or at least not that I can notice
<elfy> just one as default
<cyphermox> but the screen size is definitely wrong, things appear off-screen
<infinity> Yeah, if I alt-tab to ubiquity, alt-space-m, I can move it on-screen.
<cyphermox> same for desktop settings
<infinity> The dialog's there, just not where it should be.
<infinity> But given that every thing I start from the right-click menu has the same issue, it's not ubiquity doing this.  Though maybe ubiquity-dm.
<cyphermox> yeah
<cyphermox> less likely to be X, given that it doesn't appear to happen on non-xubuntu
<cyphermox> though I wonder if it's not that kvm and virtualbox aren't exactly helping, I'm going to spend a bit of time testing this on hardware
<infinity> Well, and not too likely to be xfce or gtk in general, per se, since the live session and installed system don't have the positioning issue.
<infinity> So it's the "special" session we're setting up with u-dm that sucks.
<cyphermox> hm, good point
<elfy> so - basically - more than one thing going on here
<infinity> elfy: Hopefully just the one thing, actually.  It's finding out what that thing is that might be a challenge. :P
<elfy> :)
<elfy> good job I drive a van for a living then ;)
<cyphermox> usually bugs are fairly simple once you find what piece to change
<cyphermox> xrandr reports the right screen size
<cyphermox> elfy: do you know if _NET_NUMBER_OF_DESKTOPS gets used for something special in xfce?
<wxl> you guys having any issue with the various software center? this affects both lubuntu and ubuntu bug 1424362
<ubot93> Ubuntu bug 1424362 in software-center (Ubuntu) "no permissions to install packages in vivid daily lubuntu beta 2" [Undecided,New] https://launchpad.net/bugs/1424362
<elfy> cyphermox: I don't know the answer to that - I'll try and find out
<elfy> wxl:  in my normal install usc is fine so is synaptic
<wxl> interesting
<wxl> wonder why this is affecting us trying to use it
 * wxl scratches his head in wonder
<elfy> synaptic works - and has a pkexec policy, the lubuntu tool fails for me - and the error makes me think that's the reason - can't see a policy for it
<elfy> probably better suited to the quality channel perhaps *shrug*
<bdmurray> cjwatson: merge-proposal updated now
<flexiondotorg> Evening
<flexiondotorg> Is there anyone in here who can kick off a new Beta 1 spin for Ubuntu MATE?
<elfy> rebuild flexiondotorg ?
<flexiondotorg> elfy, Yep.
<elfy> you can do that - adjourn to -quality :)
<flexiondotorg> Some changes have been made and new packages are now in the official archive.
<ari-tczew> please delete julia (0.3.2-2ubuntu1~ppa0) vivid; from -proposed. it has been wrong uploaded to ubuntu instead of ppa. sorry.
<infinity> ari-tczew: Done.
<slangasek> cjwatson: sorry for not getting to your dynamic-arches branch; I had Friday brain by the time I looked at that one.  I see Laney has merged it now
#ubuntu-release 2015-02-25
<flexiondotorg> Laney, would it be possible to sync ubuntu-mate-artwork 0.4.3ubuntu1 from proposed so it can be used to spin Beta1?
<Laney> flexiondotorg: OK (FWIW the request is for an 'unblock', it's being held because of the beta 1 freeze)
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-mate-artwork
<Laney> Done - once rmadison shows the new version is in vivid you can start your rebuild
<flexiondotorg> Laney, Thanks.
<oSoMoN> whatâs the freeze currently in application that prevents packages from migrating from proposed to release?
<cjwatson> oSoMoN: beta 1
<oSoMoN> cjwatson, pardon my ignorance, when will it be lifted?
<cjwatson> oSoMoN: after beta 1 is released.  see the release schedule
<cjwatson> https://wiki.ubuntu.com/VividVervet/ReleaseSchedule
<oSoMoN> tomorrow if I read correctly then. thanks
<cjwatson> flexiondotorg: ^- powerpc appears to have succeeded too, it's just only on the tracker for daily and not beta 1 at the moment
<cjwatson> Laney: ^- doesn't appear to have download information set up on the tracker
<cjwatson> http://iso.qa.ubuntu.com/qatracker/milestones/326/builds/89692/downloads
<flexiondotorg> cjwatson, OK. Is that something I can fix?
<cjwatson> flexiondotorg: I think it needs ubuntu-release, which is why I asked Laney
<cjwatson> oh, sorry, you mean beta 1
<cjwatson> I don't remember, maybe Laney can
<flexiondotorg> cjwatson, What is most important is it produce a powerpc iso I can get the ppc guys playing with.
<cjwatson> flexiondotorg: Well, you have that
<cjwatson> flexiondotorg: http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/
<cjwatson> Don't commit the error of thinking that the tracker is everything :)
<flexiondotorg> cjwatson, ð
<Laney> flexiondotorg: cjwatson: Done, added to Beta 1 milestone also
<flexiondotorg> Laney, Thanks!
<cjwatson> Laney: ta
<flexiondotorg> Laney, I rebuild the Ubuntu MATE isos a little while ago.
<flexiondotorg> Laney, This spin is looking good for Beta 1.
<flexiondotorg> Laney, Do I have to do anything to mark it as Beta 1 candidate or will it just automatically get ellected?
<Laney> flexiondotorg: Use "Mark as ready" on the tracker to indicate so
<flexiondotorg> Laney, does that mean "i've tested it and it is ready"?
<Laney> It means that it's ready to be released with the milestone
<flexiondotorg> OK
<Laney> Whether it's tested or not is a matter for the person pressing the button. :P
<bdmurray> cjwatson: the autopackage stuff is ready for review https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/autopkg-excuses/+merge/250795
<bdmurray> and there is another ubuntu-archive-tools mp - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-deleted/+merge/250811
<cjwatson> oh, right, yeah, those were on my to-do for today, let me look now
<cjwatson> bdmurray: both merged, thanks!
<bdmurray> cjwatson: great, thank you
<infinity> bdmurray: Say, if you're fiddling in sru-report, I have a bug for you that I was just looking at how best to fix.
<infinity> bdmurray: In get_srus, we skip packages we don't want showing up in the lists due to noise (langpacks, kernels, etc), but that's the wrong place to skip them, as it means they also don't show up on the removals list.
<infinity> bdmurray: Which has never been a problem until we did britney integration, now we really do want the proposed versions deleted if they're hanging around.
<infinity> cjwatson: Though, maybe this is a self-solving problem if the ultimate goal is for migration to be unblocks, and britney does an atomic copy/delete for me, like it does in the devel series?
<infinity> Would still be nice to have the report tell me about removals when that screws up, though.
<bdmurray> infinity: noted
<infinity> bdmurray: The naive fix would have just been to move the filter into the HTML output section instead, but if we're not displaying all the info for those, it's pretty inefficient (especially for kernels) to go bug-scraping, etc.  So, perhaps something more clever like having them still be in the srus list, but skip scraping for extra info, and add a display=bool property set to false?  I dunno.
<cjwatson> infinity: Yeah, I think this is ultimately why I just had to do a big pile of binary removals from -proposed for old kernels.  I was thinking about the same thing today.
<infinity> cjwatson: Yeah, it's definitely the cause of your pain.  We used to remove old kernels from proposed, and then I started filtering them out of the list, which meant they hung around forever.
<infinity> cjwatson: I never cared, since it has zero impact on the size of /pool/ and minimal impact on proposed/Packages, but it suddenly matters.
<cjwatson> infinity: If I get round to finishing my copyPackage(move=True) patch, then you could just use that in sru-release, of course, and the removals section no longer matters.
<cjwatson> (Or movePackage.  Whatever.)
<cjwatson> proposed-migration would use that too under the hood, of course, but it could equally be used directly.
<infinity> And, of course, my filtering was just a cargo-cult of the existing langpack filtering, but langpacks don't suffer the same issue, since they don't introduce NEW binaries on every upload.
<cjwatson> Or, even now, sru-release could do the same thing that promote-to-release does and do the delete.
<infinity> cjwatson: Yeah, sru-release could do the copy-and-delete together, but we still know that (very rarely) fails to delete sometimes, hence the removal list is still helpful.
<infinity> We still catch the odd manual removal needed in vivid here and there.
<infinity> Unless that was finally hunted down and stamped out?
<cjwatson> Right.  This is ultimately why I want an atomic move operation.
<cjwatson> It's entirely bogus to have to do those separately.
<infinity> Yep.
<infinity> An actual atomic move would be lovely.
<cjwatson> The case where copyPackage succeeds, the actual copy job fails, and the delete succeeds is much worse, and does happen once in a blue moon.
<infinity> I'd also like some atomic batch operations... I wonder if I ever files bugs.
<cjwatson> Batching can be harder due to timeouts, but atomic move of a single package is quite easy.
<infinity> (ie: change-override should be using an atomic batch interface, and an atomic batch for a set of moves would also be awesome, so I don't get hit by a random delay making linux-meta release before linux)
<cjwatson> I had most of the patch for that but I keep getting distracted ...
<infinity> cjwatson: I assume the API is flexible enough to be able to crank up timeouts for specific operations?
<infinity> cjwatson: Seems a waste to back this whole thing on a database with transactional support and not leverage it more.
<cjwatson> That's controllable by feature flags per-operation if necessary, yes.
<infinity> And, actually, a batch change-overrides would probably be much faster than what we currently do, too.  So long as it doesn't lock an entire table when it happens. :P
<infinity> Or worse, several.
<cjwatson> That's probably the issue.  I don't understand the data model quite well enough for that.
<cjwatson> Also we'd need to put the operation on some other base object.
<infinity> cjwatson: Well, I can hold off on these fancy requests, since I know that both overrides and copies are on wgrant's hitlist for his feature redesign.
<cjwatson> And I suspect we'd end up encoding a bit more policy into the Launchpad side, because it would need to have things like checking for which architectures still have active publications, that are currently checked on the change-override side.
<cjwatson> Yeah.
<infinity> cjwatson: So, a fresh data model might make these things easier.  Though, "will this allow for sane batching and locking" should probably be a design goal.
<cjwatson> I need to go off and understand the current bits of that redesign at some point.
<cjwatson> But slightly full right now. :)
<elfy> I suspect that I've missed Laney by a country mile ...
<Laney> elfy: suspect no more
<elfy> :)
<elfy> so  - it looks like everyone (except us) are all looking good where testing
<elfy> I'll chase studio up shortly
<elfy> xubuntu has a contingency plan - doesn't look like we'll get our issue sorted in time to test
<elfy> not sure what other things you need from me tbh
<elfy> atm anyway
<elfy> I'll sort out the release announcment tomorrow
<Laney> just herd the cats into being ready in time, and send the announcement tomorrow
<elfy> yea
<elfy> loads of fun, I'm not internet friendly at work :)
<wxl> hey infinity you ever figure out what's wrong with our alternate? it looks like the issue may extend beyond just that last point release :( http://pastebin.com/VKECPUCK
<wxl> infinity: nevermind. bad tester.
<infinity> wxl: I'm not sure what you mean?  You mean trusty dailies still show it?  Of course they do, nothing has changed to fix it since 14.04.2 was released.
<wxl> i meant in vivid infinity but i see that this is based off of 14.04.2 :/
<elfy> infinity: someone a lot cleverer than me has worked out why the install windows are off -> somewhere :)
<infinity> elfy: Oh?  Have a pointer to the analysis/fix?  I'm curious.
#ubuntu-release 2015-02-26
<sak> I really hope we are able to release 15.04 this cycle. It would be a shame if not based on all the effort that was put into it
<bluesabre> infinity: we have a solution for our complete dialog opening offscreen, https://code.launchpad.net/~bluesabre/ubiquity/fix_1425690/+merge/251030
<bluesabre> I was able to test it by swapping out the code and restarting ubiquity, and continuing with a successful installation
<bluesabre> if at all possible, can we land this fix tonight
<bluesabre> (or any other release-team, ubiquity folks) :)
<ypwong> bdmurray, could you help with the sru for ubuntukylin-theme in bug 1415792, it's needed by our oem project, thanks
<ubot93> bug 1415792 in OEM Priority Project trusty "[SRU]After install ubuntukylin-theme the grub can't be updated" [Undecided,New] https://launchpad.net/bugs/1415792
<elfy> ypwong: hey - are you going to be in a position to get your vivid beta's marked ready soon?
<elfy> darkxst: same :)
<ypwong> elfy, let me check with the tester
<elfy> ypwong: you've got about 10 hours :) just pinging now as I'm afk most of my day
<ypwong> elfy, ubuntu kylin is ready now
<flexiondotorg> elfy, Not sure if I need to tell you this? Ubuntu MATE on i386, amd64 and powerpc are ready.
<darkxst> flexiondotorg, congrats, thats a fair effort to get everything ready in a few days of your first buils
<darkxst> builds
<flexiondotorg> darkxst, Thanks ð Team effort.
<darkxst> flexiondotorg, ofc, that is what flavours are all about ;)
<darkxst> flexiondotorg, despite the troll wars that happen on the interwebs its just one big happy family of different DEs ;)
<flexiondotorg> darkxst, It totally is. The Xubuntu team have been great for example ð
<darkxst> flexiondotorg, I have servers hosted by lubuntu, but this is probably getting a little off topic for this channel, Welcome to the family (and your team ofc)
<elfy> Riddell: hi there - how's your beta stuff looking? I see you've got bunches of tests done - but not looked at them other than that :)
<Riddell> elfy: all good but I noticed upgrade hasn't been added to the beta 1 testing and I don'ty think anyone has tested that so I was about to
<Riddell> elfy: did you have any expected ETA for release?
<elfy> Riddell: well I'm home for lunch, back later and am same tz as Laney - so I would suspect late afternoon/evening UTC
<Laney> elfy: I probably disappear around 6pm so would be looking to start pres butan about 5 if possiblee
<elfy> Laney: right
<elfy> well I will be driving still then
<elfy> I'll mark xubuntu ready - we know there's an issues with Install, but installiing from livesession works correctly
<Laney> was going to say
<Laney> I guess you can release note that issue
<elfy> yep - that's all in hand
<Laney> is studio the same?
<elfy> studio have the same install issue I smoketested that this morning
<elfy> zequence: what's the state of play with your beta's ?
<Riddell> Kubuntu marked as ready
<elfy> Riddell: thanks
<Laney> cool beans
<elfy> Laney: if you ping me in here to say go - I'll get the release announcement posted
<Riddell> our release page at https://wiki.ubuntu.com/VividVervet/Beta1/Kubuntu
<elfy> I might possibly be back ealrier than I anticipate - but I'm an hour behind already :|
<elfy> Riddell: thanks :)
<elfy> wxl: release notes? :)
<Mirv> Laney: we'd be ready regarding bug #1418060 on our side. not hurry otherwise with freeze and all, but if possible getting the fix included in tomorrow morning's image would be beneficial.
<ubot93> bug 1418060 in qtdeclarative-opensource-src (Ubuntu) "[FFe] QML compilation cache patch needs adaptation for Qt 5.4" [Critical,In progress] https://launchpad.net/bugs/1418060
<tjaalton> could someone ack libdrm from proposed to vivid, it's under MRE anyway
<tjaalton> and missed FF because debian doesn't process the new queue too actively
<cjwatson> tjaalton: it's not about MRE, it's about the archive currently being frozen for image prep
<cjwatson> since beta 1 is today
<tjaalton> ahh, yeah that's fine then :)
<flexiondotorg> I see the oversize threshold for the Ubuntu MATE iso images is 703MB. Any chance that could be change to 1GB?
<cjwatson> I think that's just a bug in the error message
<cjwatson> Note your images are over 1GiB anyway
<flexiondotorg> cjwatson, Yes, but I am going to try and get the image to 1GB for Beta2.
<flexiondotorg> Other flavours appear to have a 1GB threshold.
<cjwatson> Yeah, you already do
<cjwatson> It's just the error that's buggy
<flexiondotorg> Oh.
<cjwatson> I'll fix it in a moment
<flexiondotorg> cjwatson, Thanks.
<cjwatson> flexiondotorg: fixed, though won't update the existing web pages
<flexiondotorg> Thanks.
<mvo> please reject my freeradius upload to utopic-proposed
<mvo> (and sorry for the noise)
<zequence> elfy: I'm testing now
<bdmurray> ypwong: what kind of help do you need? its not clear to me from the bug
<ypwong> bdmurray, we're working on sru the package to trusty, does it need sru team approval?
<bdmurray> ypwong: I don't see anything in the Trusty SRU queue yet for ubuntuklyin-theme. https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<ypwong> bdmurray, what went wrong? the package should have already been uploaded
<bdmurray> ypwong: oh, is it this? https://launchpad.net/ubuntu/+source/ubuntukylin-theme/1.0.2
<ypwong> bdmurray, yes it is
<bdmurray> ypwong: okay, somehow the bug wasn't updated with testing information. You can read about it here - https://wiki.ubuntu.com/StableReleaseUpdates/#Verification
<ypwong> bdmurray, thanks, will get it tested tomorrow
<bdmurray> ypwong: okay, we do't release packages to -updates on Friday, so if it is tested tomorrow we can release it on Monday then
<ypwong> bdmurray, that's good enough, but why no updates on friday?
<bdmurray> ypwong: because if things go horribly wrong nobody should be working on Saturday to fix it
<ypwong> I see
<xnox> Laney: or other release people -> please unblock upstart package, it has privilege escalation security fix.
<Laney> xnox: freeze will be lifted momentarily
<xnox> Laney: ah, cool.
<Laney> zequence: progress?
<zequence> Laney: I'm done
<Laney> great, thanks
<zequence> Marking ready
<Laney> rcj / utlemming: cloud images looking okay?
<rcj> Laney, Cloud images look good
<Laney> thumbs up
<Laney> the freeze... it's getting warm...
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Alpha 2 | Archive: Feature Freeze | Vivid Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<Riddell> elfy, Laney: any plans to announce beta in the next 30 mins? (I'm going out and will be a few hours is all)
<Laney> Riddell: No, won't be publishing for an hour ish
<Riddell> ok I'll pop into the office later to finish it
<Riddell> release-upgrader still need an update to fix it, hopefully bdmurray is on the case
<Laney> I guess consider linking to the bug in your release notes
<Riddell> yeah
<bdmurray> I am looking at it
<bdmurray> Riddell: the tests passed for me
<Riddell> bdmurray: great, go ahead and upload
<Riddell> maybe they didn't like the half upgraded utopic machine I'm running them on
<elfy> Laney: I see that everyone's marked ready
<Laney> indeed
<Laney> starting work on publishing in 5 minutes
<elfy> Laney: ok
<rcj> Laney, should I start cloud publication for beta1?
<Laney> rcj: At your leisure, go for it
<elfy> Laney: I assume that the images will be at http://cdimage.ubuntu.com/flavour/releases/vivid/beta-1 ?
<Laney> yep
<elfy> ta
<elfy> cloud at http://cloud-images.ubuntu.com/releases/vivid/beta-1/
 * Laney stabs cron.source
<Laney> I'll sync without that, it can catch up later
<Laney> elfy: should start appearing soon
<elfy> ok - good to announce?
<Laney> I'd wait a bit until you see them
<elfy> ok - I'll go off and find out what's up with the teapot then
<Laney> the torrents take a little while to hash too, up to you if you want to wait for those to start working
<elfy> okey doke
<Laney> you can just whack one in your client and wait for it to start downloading
<elfy> yep
<elfy> still after release notes from lubuntu and studio
<Laney> it's not essential, go without if they don't want to provide them
<Laney> guess studio might for the ubiquity thing though
<elfy> yep - I expect wxl will want one for lubuntu
<Laney> elfy: I'm going to take off - everything should show up in the coming minutes, but if you have any problems get someone to text me
<elfy> studio might be waiting for ours
<elfy> Laney: ok - thanks for your help :)
<Laney> no worries
<elfy> rcj: any reason why http://cloud-images.ubuntu.com/releases/vivid/beta-1/ just gets a 404 instead of just nothing actually there yet?
<flexiondotorg> elfy, Don't know if you need this? https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1/
<elfy> nope - I got your release notes - unless you want ^^ to appear on the announcement?
<elfy> flexiondotorg: ^^
<flexiondotorg> elfy, You took the notes from the wiki?
<elfy> yea
<flexiondotorg> Not sure what you do. Do you link to them or reformat them?
<elfy> https://wiki.ubuntu.com/VividVervet/Beta1/UbuntuMATE
<elfy> just link
<flexiondotorg> Then link to https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta1 please ð
<elfy> flexiondotorg: ack
<flexiondotorg> Thanks
<elfy> we're doing the same this time
<elfy> rcj utlemming Odd_Bloke - is the cloud beta1 images definitely supposed to be living at http://cloud-images.ubuntu.com/releases/vivid/beta-1/ ?
<elfy> wxl - looking to get this announcement out - release notes for you?
<rcj> elfy, it will
<elfy> rcj thanks :)
<elfy> keeps 404ing for me and didn't want to make me look any dafter than I already do by pointing everyone at the wrong place :)
<rcj> elfy, I understand.  The cloud images are in the process of being published and the download location you have is correct
<elfy> ta :)
<stgraber> bdmurray: your unattended-upgrade SRU is making all my containers crash once an hour ;)
<bdmurray> stgraber: hunh?
<stgraber> you can't set negative nice values in an unprivileged LXC container even if you're root inside it
<stgraber> so now every time unattended-upgrade runs (in my case every hour), it crashes on that os.nice call
<stgraber> what we've done in other tools (like systemd) is make this non-fatel if the error is EACCES (typical for unprivileged containers) or EPERM (typical for apparmor preventing it)
<bdmurray> stgraber: but then wouldn't bug 1422345 still happen?
<ubot93> bug 1422345 in unattended-upgrades (Debian) "stop being nice does not work" [Unknown,New] https://launchpad.net/bugs/1422345
<flexiondotorg> elfy, Where will the Beta 1 release post go?
<flexiondotorg> For all the releases.
<elfy> ubuntu-devel-announce and ubuntu-release
<flexiondotorg> Not web then?
<elfy> nope
<stgraber> bdmurray: sure, the bug would still happen in this case
<stgraber> bdmurray: root in a userns has the same rights as a regular user with regard to process priorities
<stgraber> bdmurray: and as a regular user, you can increase the niceness but never decrease it
<bdmurray> would it better to first try decreasing and only increase it if decreasing works?
<stgraber> yep, that'd be a good trick
<stgraber> so -1, if that works then 20, otherwise keep is it is
<mlankhorst>  
<stgraber> bdmurray: http://paste.ubuntu.com/10434743/
<stgraber> bdmurray: that also accounts for the fact that your startup niceness may not be 0
<elfy> anyone in here moderator on ubuntu-devel-announce, if so can they moderate my mail please :)
<elfy> thanks for everyone's help with this beta
<bdmurray> elfy: I am
<elfy> awesome - if you could that would be great :)
<bdmurray> elfy: done
<bdmurray> stgraber: okay, do you want to submit that to mvo upstream or shall I?
<stgraber> bdmurray: if you don't mind, go ahead
<elfy> bdmurray: thanks :)
<kamal> hi, we (the Canonical kernel team) are trying to crank out a high-priority kernel update ... our PPA build just failed on powerpc, due to "No space left on device" ...
<kamal> is there any Launchpad hero around who can help fix it?
<kamal> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/7015466
<cjwatson> kamal: We can try rescheduling it on sagari.
<cjwatson> I can't remember whether that has more disk, but we can find out.
<kamal> cjwatson, sounds like a plan, thanks!
<kamal> cjwatson, fwiw, this kernel update shouldn't be any bigger than usual, so . . .
<cjwatson> kamal: But sagari is already busy with a kernel build.
<cjwatson> kamal: I can't look at denneed* directly; only infinity can.
<kamal> cjwatson, I think he's not around today
<cjwatson> kamal: Right now the best I can offer is to reschedule it on denneed01.  They're the same configuration, but there's an outside chance that denneed02 might have a bit more ddeb junk left around on its filesystem and thus have somewhat less disk.
<kamal> cjwatson, yes, that ^^ please :-)
<cjwatson> It's building another security update right now, but should be done in five minutes or so.
<kamal> cjwatson, that's great, thanks very much
<cjwatson> kamal: Building on denneed01 now.  We'll see.
<kamal> cjwatson, thanks, I'll keep an eye on it
<balloons> stgraber, you about? it seems ubuntu-mate-release team on the tracker is lacking permissions to setup testsuites for there products. Can you double check the perms and ensure they have them?
<elfy> balloons stgraber - I have the ability to do so - whether that is because I am release team elsewhere
 * wxl sighs
<wxl> here at long last
<wxl> thanks (honestly, elfy) for releasing without waiting for us
<wxl> we don't have the release notes together anyways :)
<wxl> (unless someone else did it in my unexpected absence)
<elfy> wxl: I asked in #lubuntu
<elfy> even if you'd have had an empty page listed on the wiki - I would have assumed it was going to be filled in and used it
<elfy> nvm
<elfy> wxl: anyway - tried to chase some of you down
<wxl> it's ok, elfy. i'm honestly saying thank you for not waiting
<elfy> wxl:  perhaps it's time to think of a release team - that's more than you and gilir who wasn't on line
<wxl> elfy: i know, i know
<elfy> wxl: lol - I took the thanks at face value - just trying to make life a bit easier
<elfy> wxl: even if you had someone else who could be authorative on QA - that'd help in future probably
<wxl> elfy: i'll get to work on nominating some folks. i'm raising up some people at present.
<elfy> looking at this from where *we* are
<elfy> we being Xubuntu ofc
<elfy> anyway - not something we need to worry about now for a while - we did our bit, other flavours can do it for 15.10 :)
<wxl> yep
<elfy> and with an extra flavour now :)
<wxl> is that MATE?
<elfy> yep
<wxl> i may take you up on that offer
<elfy> welcome :)
#ubuntu-release 2015-02-27
<cjwatson> kamal: That powerpc build is just finishing now.
<kamal> cjwatson, nice, thanks again for the help with that
<Laney> elfy: well done, thanks for your help
<sil2100> Hello release team! We have an FFe for the Qt 5.4 QML-cache feature in vivid: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1418060
<ubot93> Launchpad bug 1418060 in qtdeclarative-opensource-src (Ubuntu) "[FFe] QML compilation cache patch needs adaptation for Qt 5.4" [Critical,In progress]
<sil2100> The packages are ready to be published, we just need a final ACK
<Laney> sil2100: done
<sil2100> Laney: thanks!
<sil2100> Mirv: ^ \o/
<Mirv> Laney: thanks!
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/fix-max-pup/+merge/251282
<teward> if someone wants something looked at for consideration for addition to vivid prior to release (but post-feature-freeze) where to we direct that request to?  (It arrived in #ubuntu-bugs asking for Bug Control to look at it for inclusion)
<slangasek> bdmurray: merged
<slangasek> teward: is this a new feature?
<teward> slangasek: not my bug, but i'd be glad to point you to it
<teward> slangasek: not sure where to direct the person / bug for attention
<teward> slangasek: second consideration: pkg the bug is against is Universe
<teward> slangasek: however ScottK suggested the freeze wouldn't affect the bugfix as it's not new features being added - https://bugs.launchpad.net/ubuntu/+source/gramps/+bug/1426144
<ubot93> Launchpad bug 1426144 in gramps (Ubuntu) "Python 3 database upgrade renders gramps unusable for languages other than English" [Undecided,New]
<teward> (first comment is ScottK's)
<teward> in other news, LP is timing out for me again :/
<teward> slangasek: however, it's still not bug control's choice what gets in / doesn't get in - hence asking where i should send the user.  i'm happy to proxy the reqs to here but i'm lazyish too
<slangasek> teward: correct, bugfixes are not affected by feature freeze.  normally I would say #ubuntu-motu or #ubuntu-devel for this, but as this just requires a sync of a new Debian package version I'll JFDI
<teward> slangasek: i'm not fluent in acronyms - expand JFDI for me please
 * teward is also extremely tired o.o
<slangasek> just friggin' do it :)
<teward> ah okay
<teward> yeah i'm tired, and i think i need more espresso :/
<teward> slangasek: i'll advise the user to poke -devel or -motu next time about it, since Bug Control doesn't have any true release control
<teward> and let them know you're looking at it right now
<tyhicks> Some i386 autopkg tests failed while my dbus upload was migrating from -proposed
<tyhicks> they look to be unrelated to my changes
<tyhicks> could someone here trigger the tests to run again?
#ubuntu-release 2015-02-28
<Mirv> infinity: we're wondering why mir doesn't migrate to release pocket. update_output claims the world would fall apart, while me on amd64 and rsalveti on phone upgraded everything successfully, and I'm not able to find anything conflicting in the -proposed otherwise either
<Mirv> (world = from abiword to zenity)
<cjwatson> answered on #ubuntu-ci-eng
<infinity> Was about to. :P
<bluesabre> release-team, big day for xfce (and xubuntu), we added a few more packages to our FFe, can we get an ack? https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1424887
<ubot93> Launchpad bug 1424887 in xfwm4 (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<ochosi> +1 ^
<elfy> I'll +1 that too - that's the whole of our release team
#ubuntu-release 2015-03-01
<bluesabre> if any admins are about, please release the above libxfce4util from NEW so I can trigger rebuilds of related packages and continue upload of xfce-4.12
<ochosi> mitya57: do you have a minute to release the above libxfce4util from NEW so bluesabre can trigger rebuilds of related packages and continue to upload xfce4.12?
#ubuntu-release 2016-02-29
<LocutusOfBorg> please update topic
<LocutusOfBorg> "released 14.04.4"
* LocutusOfBorg changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Wily 15.10 | Archive: open | Xenial 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
<mapreri> the joy of channel with -t, so rare in freenode
<LocutusOfBorg> I never thought I was able to do it :)
<tjaalton> so new xserver can move from ppa:canonical-x/x-staging to xenial now
<tjaalton> infinity: is this a task for you? ^
<tjaalton> bug 1547510
<ubot5> bug 1547510 in xorg-server (Ubuntu) "tracker for xorg-server 1.18 migration" [High,Triaged] https://launchpad.net/bugs/1547510
<ogra_> i think there was a mail saying that he is off today
<tjaalton> ah
<tjaalton> just today?-)
<tjaalton> tomorrow is fine
<ogra_> yeah, something about a swap day swap :)
<tjaalton> ok
<cyphermox> could someone please review the new libcxl source in the xenial NEW queue?
<flexiondotorg> infinity, How goes Xubuntu Base and Ubuntu MATE Base?
<cyphermox> flexiondotorg: infinity is off today
<cyphermox> flexiondotorg: can I help? :)
<flexiondotorg> cyphermox, OK :-)
<knome> does he do anything else than be off? :P
 * knome hides
<flexiondotorg> cyphermox, I'm slacking off in the pub.
<cyphermox> knome: hehe
<flexiondotorg> cyphermox, Well infinity has said he will review/add the Xubuntu Base and Ubuntu MATE Base change to the build system so we can each have a cut down .iso for those experienced users who've been requesting it.
<cyphermox> yeah, I'm aware of the general idea
<cyphermox> build system, you mean ubuntu-cdimage changes?
<flexiondotorg> Yes.
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-base/+merge/284435
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/ubuntu-mate-base/+merge/284432
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate-base/+merge/284433
<teward> If I need something reviewed for an FFe, do I poke here or in -devel?
<knome> teward, https://wiki.ubuntu.com/FreezeExceptionProcess
<teward> knome: right, i've done all those steps and the release team is subscribed :P
<teward> i'm stuck in the limbo of waiting for someone to look at it :)
<teward> oh great the wiki's 500-ing again for me >>>
<michi> davmor2: ping
#ubuntu-release 2016-03-01
<tjaalton> infinity: back to work? xserver + drivers from ppa:canonical-x/x-staging can be copied to xenial now, bug 1547510 is green
<ubot5> bug 1547510 in xorg-server (Ubuntu) "tracker for xorg-server 1.18 migration" [High,Triaged] https://launchpad.net/bugs/1547510
<infinity> tjaalton: Nah, it's 12:30am, not quite back to work yet. ;)
<tjaalton> infinity: ah ok, your tomorrow then :)
<tjaalton> hmm I'll add a pointer to the "remove these drivers" bug
<tjaalton> infinity: so, copying the xserver bits.. ping me if you need me :)
<tjaalton> uploading -wacom with a less silly version
<infinity> cyphermox: Whee, another SRU?  Aren't you glad you took over multipath-tools?
<cyphermox> thrilled.
<cyphermox> there's likely to be another one after that too
<cyphermox> otoh, there's SRUs because we're making it better
<cyphermox> we're bound to hit a point where it works ;)
<infinity> cyphermox: I'll believe it when I see it.
<cyphermox> heh
<cyphermox> believe me I won't mind when storage stuff will work.
<cyphermox> after all, storage is good, and I hear some noises in my desktop pc that also sounds suspiciously like a hard drive that will fail soon.
<flexiondotorg> infinity, It's all about the Base. No trouble?
#ubuntu-release 2016-03-02
<clivejo> Hi, Kubuntu have filed a FFE for KDE software we'd like to get into Xenial, to date there has been no reply/update to the request, who would I need to speak to about that?
<apw> you are at least asking in the right place i believe
<clivejo> me?
<knome> yes
<knome> sending bribes to release team postal addresses usually works
<knome> :P
<coreycb> bdmurray, arges: hi, when you get a chance can you promote packages to -updates for bugs 1544568 1460164 1531963?
<ubot5> bug 1544568 in neutron (Ubuntu Wily) "[SRU] neutron 7.0.3 and ceilometer 5.0.2 stable releases" [High,Fix committed] https://launchpad.net/bugs/1544568
<ogra_> can someone please let ubuntu-core-generic-initrd out of binary new ?
<ogra_> (well, once ubuntu-core-generic-initrd actually hits the queue :P )
<cking> can anyone devote some cycles to my FFE request for powerstat, LP#1550366
#ubuntu-release 2016-03-03
<LocutusOfBorg> ping about virtualbox-lts-wily on trusty queue
<LocutusOfBorg> feel free to reject lts-vivid :)
<clivejo> please please please will someone from the Release team have a look at our FFe - https://bugs.launchpad.net/ubuntu/+source/meta-kde/+bug/1547571
<ubot5> Launchpad bug 1547571 in meta-kde (Ubuntu) "[FFe] KDE Meta" [Critical,Confirmed]
<Laney> clivejo: do you actually expect to be able to get to all of those?
<clivejo> Laney: many of the devs are already using them and very stable
<clivejo> it just took us longer than expected to get the merges completed and we missed the deadline
<Laney> clivejo: you mean they are ready to upload already?
<clivejo> almost, they are in different PPA's but I dont think it would take long to get them ready
<Laney> It's just that it is quite disruptive when you do a KDE mass upload
<Laney> mainly because it makes autopkgtest grind to a halt
<clivejo> Im kinda new at this, but sgclark (who opened the FFe) would be able to tell you more
<clivejo> she probably wont be about until later (due to timezone)
<clivejo> can you explain that on the bug report?
<Laney> clivejo: it's ok, I commented
<clivejo> thank you
<clivejo> can you take ownship?
<Laney> no, it's up to someone to upload it now
<coreycb> hello, can an archive admin please promote python3-suds to main? this will help get some of our openstack packages out of dependency waits.
<flexiondotorg> infinity, Yo
<cyphermox> flexiondotorg: more about core?
<flexiondotorg> cyphermox, Yeah, I was wondering if infinity is totally addicted to Base ;-)
<cyphermox> oh, right, base, not core
<flocculant> :)
<flexiondotorg> I've already let infinity know that is all about the Base, no trouble.
<ogra_> treble you mean ?
<ogra_> :)
<flexiondotorg> :-)
<nacc> Hi all, we now have a successfully building & testing twig (1.23.1-1ubuntu4), but it's stuck in excuses because the old version of the package generated a binary package php5-twig, which has been removed from the new builds. Can someone help remove php5-twig from the archive?
<cjwatson> nacc: done
<nacc> cjwatson: thanks!
<nacc> cjwatson: i assume after some time, I'll now just see twig clear out of excuses?
<rbasak> nacc: unless there's a different excuse, yes :)
<nacc> rbasak: right :)
<cjwatson> yeah, hopefully
<bdmurray> rcj: to be clear the verification is done for both T and W in bug 1540965?
<ubot5> bug 1540965 in cloud-init (Ubuntu Wily) "Support Joyent lx-brand environment in smartos datasource" [High,Fix committed] https://launchpad.net/bugs/1540965
<mdeslaur> can someone please push openssl out of xenial-proposed? the linux and vsftpd autopkgtest failures are unrelated
#ubuntu-release 2016-03-04
<flexiondotorg> infinity, Yo
<flexiondotorg> infinity, When the Baseline drops?
<flexiondotorg> Yes, I am continuing to troll infinity with song titles.
<lamont> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1553176 <-- I wonder if that's worthy of an SRU in trusty (prolly)
<ubot5> Launchpad bug 1553176 in bind9 (Ubuntu) "BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload" [High,Confirmed]
<lamont> only affects instances where the DNS is updated more than once per second...
<rbasak> lamont: seems reasonable if MAAS wants it.
<lamont> fact
<lamont> I'll get back to you on that...
<xnox> mythbuntu and edubuntu will release in 16.04 LTS, right?
 * xnox is editing the release notes.
 * smb just read "eating" instead of "editing" ... and he already had lunch...
<apw> they are about as useful for eating :)
<ginggs> Hi, i have a FFe for LP: #1549763 to sync a new (to xenial) package from debian, provided I find an archive admin to review it. Should I subscribe ubuntu-archive to the bug, or do I sync the package?
<ubot5> Launchpad bug 1549763 in trilinos (Ubuntu) "FFe: Sync trilinos 12.4.2-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1549763
<xnox> ginggs, ^
<flexiondotorg> infinity, Base Things?
<ginggs> xnox: thanks!
<superm1> cjwatson: on -signed packages, is there a way for the archive to make a distinction if the efi binaries changed from one version to another and not require a new -signed package with every upload if the efi binaries are identical?
<superm1> eg an upload for 0.5-1 is there, -signed gets uploaded and they both move out of proposed.  0.5-2 gets uploaded but fixes something unrelated to EFI binaries that 0.5-1 made, so not have to upload -signed package again
<cjwatson> superm1: It has nothing to do with the archive; the -signed packages have tight dependencies.  In order to loosen the dependencies, the -signed packages would have to be clairvoyant, I think.
<superm1> yeah i suppose that makes sense when I give it more thought :/
<cjwatson> superm1: There is one possibility I can think of: instead of depending on a tight version, we could hash the EFI binaries (somehow) and use the hash to compute a Provides field; the -signed packages could then depend on that.
<cjwatson> superm1: Implementation is left as an exercise for the reader. :-)
<superm1> cjwatson: Ah I like that idea.  does anything do any filtering of custom Provides that I'd need to worry about if I tried to come up with something?
<cyphermox> ah, I like that idea
<cyphermox> superm1: one thing comes up to mind though, infinity wanted to sync the code to download the signed binaries across all the -signed packages
<cyphermox> IIRC the right source was the linux-signed package, and others should use the same scripts
<superm1> cyphermox: like have one -signed source package that generates all the -signed packages at once?
<cyphermox> no
<cyphermox> but at least use the same version of the scripts across all packages, some do things others don't
<cyphermox> (not that there is very much to do really)
<superm1> oh i see
<cyphermox> I'd really discuss this with infinity again, perhaps between the three of us we can come up with something solid
<cyphermox> (or maybe I just misunderstood completely ;)
<cyphermox> superm1: did you need a new build of some signed package now? otherwise would you have time for a hangout on monday or something?
<cjwatson> superm1: No, this is based on the approach that Haskell and Ocaml use so I know it works in theory.
<superm1> cyphermox: i just uploaded fwupdate-signed so that it could transition as part of the MIR that was just approved for fwupdate*.  i'm traveling the next 2 weeks in an opposing timezone in a country that hates google, probably wouldn't be able to hop on a hangout easily during that time, sorry
<cyphermox> ok
<cyphermox> well, IRC is just as fine though :)
<superm1> Yeah.  ping me at some point when you guys chat and if i'm around i'll comment, otherwise i'll look at what you guys decide upon and make any appropriate changes for fwupdate-signed to match what you do for grub, shim and linux -signed
<cyphermox> ok
<cyphermox> I really like the hashing idea, I'll run a few tests with shim here
<infinity> The hash dep could work indeed, assuming reproducible builds.
<infinity> Though, to be fair, the "reupload -signed" bit isn't exactly onerous for anything other than shim, which needs a turnaround step with Microsoft.  And that one's done by hand, so we could as easily be checking the hash ourselves there.
<infinity> shim's the unique snowflake because of that.
<infinity> The bigger concern isn't slow migration in the devel series, it's the inevitable bollocksing of SRUs until we get britney driving that process end-to-end.
<infinity> cjwatson: We really need to sit down and see how close we are to being able to do that.
<infinity> cjwatson: Possibly less you and more pitti, since the blocker is/was probably too many adt failures to deal with.
#ubuntu-release 2016-03-06
<flexiondotorg> infinity, Base line?
#ubuntu-release 2017-02-27
-queuebot:#ubuntu-release- New binary: rustc [i386] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: rejected gnome-recipes [source] (zesty-proposed) [0.14.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (zesty-proposed) [1.15.1+dfsg0-1~exp1ubuntu2]
-queuebot:#ubuntu-release- New sync: automat (zesty-proposed/primary) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted automat [sync] (zesty-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New binary: automat [amd64] (zesty-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted automat [amd64] (zesty-proposed) [0.5.0-1]
<cult-> https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
<ubot5> Ubuntu bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed]
<cult-> https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
<ubot5> Ubuntu bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed]
<apw> cult-, we saw it the first time ...
<cult-> :-)
<apw> xnox, that block of libodb stuff ... why are those needing to be in lockstep, if they are why does that not affect anyone consuming them
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.19 => 1.2.20] (core)
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3.4 => 1.3.5] (core)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (zesty-proposed/universe) [2.0.14+20170111-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (zesty-proposed/universe) [2.0.14+20170111-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (zesty-proposed/universe) [2.0.14+20170111-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [i386] (zesty-proposed/universe) [2.0.14+20170111-4ubuntu1] (no packageset)
<xnox> apw, so there is c++ abi change; the old libodb is compatible with everything but the -mysql is the bug we are trying to fix
<xnox> however the new libodb-* are incompatible with the old libodb
<xnox> and the new libodb is incompatible with the old libodb-[!mysql]
<apw> xnox, rigth but after we accpet this pile is any user of libodb in trouble
<xnox> thus one should release all of them as one pile.
<xnox> apw, i guess i should have had Breaks: libodb-[!mysql] << old in libodb
<apw> xnox, but what about anyone already built
<xnox> anyone who used libodb-mysql is screwed =) until one full-upgrades
<xnox> anyone who uses xenial-release compiler cannot use libodb*
<xnox> one can only use pre xenial compiler with xenial libodb stack, sans mysql.
<apw> xnox, and is the working compiler in -security
<xnox> it's very broken, as the default xenial compiler cannot compile/link anything against libodb*
<xnox> compiler from xenial-release (and updates, and security) defaults to the new abi
<xnox> libodb in release was lask built in pre-xenial
<xnox> libodb in xenial-release was lask built in pre-xenial
<cult-> currebt libodb binaries without this bugfix, are completely unusable. this bugfix is very much needed to use this library. they were broken since release.
<cult-> no one is using the original binaries because they are broken.
<xnox> apw, basically debian did binNMUs to transition them to c++11 abi; and we didn't.
<apw> xnox, ok so the accurate statement is anything using it is broken, ie not using it as it is
<xnox> API is not changed, only ABI broken via 3rd party packages.
<xnox> apw, right everything is broken in libodb* stack =)
<apw> xnox, and they are clearly heavily used in that case, being broken for so long, ugg
<cult-> the maintainer messed it up after a request to link against proper mysql dependencies, he missed the abi differences.. poor man.
<xnox> apw, well debian simply did binNMUs and we missed that.
<apw> xnox, can you pm me the list of package which must be in lock-step pls
<xnox> apw, it's all in the bug. but ok.
<xnox> (it's one bug)
-queuebot:#ubuntu-release- New binary: networking-bgpvpn [amd64] (zesty-proposed/universe) [6.0.0-0ubuntu1] (no packageset)
<cult-> apw: is the fix released happens instantly or some hours until it appears in repo?
<apw> cult-, modulo the time it takes the publisher, i would expect it to be out around now
<apw> cult-, and potentially modulo mirroring delays depending which mirror you use
<cult-> yeah i can't see it yet
<cult-> finally
<cult-> thanks a lot!
<cult-> btw, are you going to close the bug report?
<ginggs> cult-: it's marked 'Fix Released' for all series, it is closed
-queuebot:#ubuntu-release- Unapproved: backuppc (xenial-proposed/main) [3.3.1-2ubuntu3.1 => 3.3.1-2ubuntu3.2] (core)
<apw> cult-, it gets closed as the binaries publish
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-40.43~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-40.43~16.04.1]
<cult-> fine
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [powerpc] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted networking-bgpvpn [amd64] (zesty-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (zesty-proposed/universe) [1.1.0+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [powerpc] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (zesty-proposed) [1.1.0+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-65.86~14.04.1] (kernel)
#ubuntu-release 2017-02-28
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-65.86~14.04.1]
-queuebot:#ubuntu-release- Unapproved: binutils (yakkety-proposed/main) [2.27-8ubuntu2 => 2.27-8ubuntu2.1] (core)
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (zesty-proposed) [2.0.14+20170111-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (zesty-proposed) [2.0.14+20170111-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [i386] (zesty-proposed) [2.0.14+20170111-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (zesty-proposed) [2.0.14+20170111-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.4 => 1.11.8-0ubuntu0.5] (ubuntu-desktop)
<caribou> This upload ^^ is meant to fix the FTBS which is holding -ubuntu0.4 in trusty-proposed. Anything that needs to be done to the 0.4 or the new upload will just override it ?
-queuebot:#ubuntu-release- Unapproved: coreutils (xenial-proposed/main) [8.25-2ubuntu2 => 8.25-2ubuntu3~16.04] (core)
-queuebot:#ubuntu-release- Unapproved: coreutils (yakkety-proposed/main) [8.25-2ubuntu2 => 8.25-2ubuntu3~16.10] (core)
-queuebot:#ubuntu-release- Unapproved: simple-image-reducer (xenial-proposed/universe) [1.0.2-3 => 1.0.2-3ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: exiv2 (xenial-proposed/main) [0.25-2.1 => 0.25-2.1ubuntu16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-weather (xenial-proposed/universe) [3.18.1-1 => 3.18.1-1ubuntu1.16.04.1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: imagej (xenial-proposed/universe) [1.50d+dfsg-1 => 1.50d+dfsg-1ubuntu1.16.04.1] (no packageset)
<nacc> i wonder if i could get some AA help to remove two src packages from zesty? LP: #1667834 to remove src:php7.1 and LP: #1666566 to remove src:postgresql-9.6. Both are transitions we will pursue in z+1, but we don't want the former to confuse users and we don't want the latter to block transitions.
<ubot5> Launchpad bug 1667834 in php7.1 (Ubuntu) "[FFe] Please remove php7.1 from zesty" [Undecided,New] https://launchpad.net/bugs/1667834
<ubot5> Launchpad bug 1666566 in postgresql-9.6 (Ubuntu) "Please remove postgresql-9.6 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1666566
<jbicha> nacc: wouldn't it be easier to just finish the pg 9.6 transition?
<nacc> jbicha: no, it hasn't started yet
<nacc> jbicha: it's 100x easier to remove it :) already discussed with pitti as well
<jbicha> nacc: actually, it's almost done
<jbicha> if you look at https://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html
<jbicha> postgresql-plproxy's autopkgtests should be ignored since they almost always fail
<nacc> jbicha: not in the ubuntu packages afaict
<nacc> jbicha: we have to rebuild a number of packages
<nacc> jbicha: to pick up new deps
<nacc> e.g., libpq5 -> libpq6
<mapreri> considering debian stretch has pg 9.6 it seems weird to me that zesty still keeps 9.5
<nacc> mapreri: time and a transition of maintainership in Ubuntu
<mapreri> nacc: "transition of maintainership"?
<nacc> mapreri: pitti was doing the work, now cpaelzer and I are
<mapreri> ok, but stillâ¦
<jbicha> the only 2 pkgs that need more investigation are the autopkgtests for postgresql-filedump and postgresql-multicorn
<jbicha> all the pg9.6 rebuilds were done several weeks ago
<mapreri> and rebuilding packages is not so time-expensive.
<nacc> jbicha: `reverse-depends src:postgresql-9.5` implies otehrwise
<nacc> mapreri: look, i'm not arguing about it. If you want to do it, do it.
<jbicha> nacc: I think that sees all the stuff in zesty release too
<jbicha> if you look at excuses you'll see that there are a lot of packages in zesty that have already been rebuilt
<jbicha> and if you look at https://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_output_notest.txt
<jbicha> you'll see that pg9.6 is ready for transition once the few autopkgtests are taken care of
<nacc> jbicha: yes, but we also want to transition pg9.5 out
<nacc> jbicha: which takes time
<jbicha> (look for apparently successful"
<cpaelzer> and extra "benefit" less active versions in the field to maintain
<nacc> jbicha: e.g, quick glance shows zabbix-proxy-pgsql is dependent on pg9.5
<nacc> jbicha: it just means more work, to verify they all get fixed/work
<jbicha> I did most of those rebuilds
<cpaelzer> nacc: we might forward the mail that we had with pitti to ubuntu-release ML if that would help to provide some reasoning
<jbicha> it looks to me like it'll be more work to try to undo the transition when it's what 90+% done
<nacc> jbicha: why? it's not publisehd yet
<nacc> jbicha: in the release pocket
<nacc> jbicha: so nothing can have migrated in that depends explicilty on postgresql-9.6
<jbicha> nacc: while I advise against it, there are people that run zesty-proposed before release
<nacc> afaik, that's not something that needs to be supported
<nacc> inasmuch as it's a known-broken world
<nacc> things can get removed from z-p, and changed, etc.
<jbicha> I'm frustrated because I spent time doing the rebuilds and rerunning autopkgtests to get it down to maybe 3 autopkgtests that need to be ignored
<nacc> jbicha: but why aren't they ignored yet, then?
<jbicha> after talking with pitti in December
<nacc> jbicha: i'm sorry, pitti didn't mention it at all to us
<cpaelzer> yeah sorry++ ^^
<nacc> jbicha: if you're going to vouch for the ignoring of the postgresql-plproxy tests, please update that bug (I think) with that comment
<jbicha> pitti seemed to want to stay with 9.5 for zesty but autosync or whatever was causing problems so 9.6 was let on in
<nacc> cpaelzer: presuming the above --^, are you ok with the transition? it's late, but it's already in z-p, might just flow through
<cpaelzer> nacc: if we both can at least dedicate 1-2 days this week to make sure it does - I'm ok
<nacc> cpaelzer: yeah, i have the cycles, at least
<jbicha> http://autopkgtest.ubuntu.com/packages/p/postgresql-plproxy/zesty/amd64
<cpaelzer> I can shuffle around things this week, but very likely are locked up next 2
<nacc> cpaelzer: and once it does, i can start working on removing src:postgresql-9.5
<jbicha> I don't know about the other 2 pkgs though, postgresql-filedump and postgresql-multicorn
<nacc> jbicha: i'm not the one to convince :/
<nacc> jbicha: you need to get the release team to ignore it, afaict
<nacc> jbicha: this is the error?
<nacc> Error: port 5432 is already used by cluster 9.6/main
<nacc> BUG: Cluster 9.6/regress was not created by me (PGSYSCONFDIR=/etc/postgresql-common, PG_CLUSTER_CONF_ROOT=)
<nacc> https://ci.debian.net/packages/p/postgresql-plproxy/unstable/amd64/
<nacc> would be good to fix deiban
<nacc> *debian
<jbicha> nacc: that was already broken with 9.5 on yakkety: http://autopkgtest.ubuntu.com/packages/p/postgresql-plproxy/yakkety/amd64
<jbicha> good to fix but not a new regression
<nacc> never said it was -- just feels like it's not something we should just ignore, if we can fix it
<nacc> i would much rather be sure we aren't breaking plproxy
<cpaelzer> nacc: since I can't predict how far you get today, would you EOD your day leving me a breadcrumb mail where to take over analyzing tests or whatever?
<nacc> cpaelzer: ack
<cpaelzer> nacc: and I'd like to track somewhere - should we refurbish the bug to drop to the "kill remaining blockers"
<nacc> cpaelzer: yeah, i'll update that bug regardless
<cpaelzer> starting with jbicha stating why we won't drop but go on as discussed before
<nacc> sbeattie: do we want to transition src:mariadb-10.0 out eventually? is someone working on that / bug filed? it seems like it's revdeps are all to the metapackages (and are none versioned)?
<powersj> slangasek: can I get you (or tell me who should) review: https://code.launchpad.net/~powersj/ubuntu-cdimage/server-size-limit/+merge/317648
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu483.1 => 20101020ubuntu483.2] (core)
<Laney> Looks to me like postgresql-filedump is putting files in 9.5/ and not 9.6/ which is breaking things
<Laney> I should think a no-change rebuild will fix that one
<slangasek> powersj: laney, infinity, sil2100 are also good for a merge review on this kind of thing; but I can look at this
<slangasek> powersj: you intend to retroactively raise the limit for all LTS series, correct?
<powersj> slangasek: yes
<jbicha> ok, I'll try a rebuild of postgresql-filedump
<slangasek> powersj: ok.  FWIW I'm going to move this up under one of the other cases that are already sized to 2^30, for legibility
<powersj> slangasek: ok
<powersj> thanks for looking at it
<nacc> Laney: good catch
<slangasek> powersj: one thing I will note is that by raising the limit for all releases, if the image does grow in the development series, you won't get any early warning if it gets big enough that a point release w/ hwe kernel is going to put it over the new limit
<slangasek> powersj: but that's not a reason for me not to merge this, just something for you to think about
<Laney> nacc: the other ones look more difficult ;-)
<Laney> but "oh they've failed for a while, let's skip them" doesn't leave me with a good feeling
<Laney> in general I'd like to see some analysis
<nacc> Laney: right, i'm importing plproxy to try and fix it
<Laney> even if that's "this is clearly not a problem due to X Y and Z"
<Laney> something more than "that's a lot of red crosses, must just be a crappy test"
<Laney> :)
<nacc> Laney: ack, I think I will use the removal bug to help track the various affected pacakges
<powersj> slangasek: I agree, however the daily email telling me is something that is no getting ignored as no action can be done. I do think monitoring the dev release somehow makes sense so we don't get into panic mode.
<nacc> jbicha: looks like multicorn's regression is from sqlalchemy
<Laney> nacc: ack, thanks!
<infinity> slangasek: I think that could do with a dist comparison to <= xenial, for that very reason.
<infinity> slangasek: If 18.04 needs to grow for the release version, we can examine that at the time, but if it only needs to grow for the point release, the knob to twiddle at the time is obvious.
<infinity> If we let server goldfish to 1G, then the 18.04 point release (if we continue this dual-stack thing) will obviously be >> 1G, which is less than ideal.
<powersj> slangasek: if you want to tell me where to move those lines I can resubmit with the dist check. infinity proposal makes sense and solves the problem.
<slangasek> powersj: I would just do something like lines 1723-1726, but fall through all the way to line 1780 for the devel series case
<powersj> slangasek: ok will make change
<powersj> slangasek: care if I limit it only to xenial then (e.g. == xenial)?
<slangasek> powersj: fine with me, I can argue myself into thinking either way is correct
<powersj> slangasek: updated
<slangasek> powersj: I think I'm going to get a linting error for the length of the line (yep!) - ./run-tests is the pre-commit test suite; I'll fix up here and commit
<powersj> slangasek: doh... sorry
<slangasek> powersj: no worries - merged
<powersj> slangasek, infinity thanks again
<infinity> rbasak: https://lists.ubuntu.com/archives/technical-board/2017-February/002284.html
<infinity> rbasak: ^-- You can't manipulate the NEW queue without ~ubuntu-archive, so the question is somewhat moot.
<rbasak> infinity: ah. Some people thought we could when for a stable release.
<rbasak> But yeah. If we can't, then it's moot.
<infinity> You definitely can't.
<rbasak> I asked the question because it felt like we were being bogged down by talking about it instead of JFDI.
<infinity> You can certainly review, say "yeah, this is a straight backport that doesn't require AA review, please accept" and turn one of us into a monkey.  But then we still have to trust you know how debdiff works.
<jbicha> but there are SRU Team members of ~ubuntu-archive who felt they couldn't process new packages because they weren't full AAs
<infinity> (We probably trust that)
<slangasek> infinity, rbasak: procedurally, my position is that I'm happy for any member of the SRU team to do the actual review and use me as an AA button pusher to accept
<Laney> I think you can
<apw> it seems reasonable to make recomendations.
<infinity> jbicha: Yes, there are some who are AAs only for broken permissions reasons (mostly kernel updates).
<Laney> I think I tried this once when sitting with apw
<Laney> As ~ubuntu-release admittedly
<rbasak> infinity: it would still probably be useful to state "~ubuntu-archive still needs to push the button due to the technicality, but in principle yes"
<rbasak> Because then any ~ubuntu-archive then knows how to respond to a request.
<infinity> rbasak: Well, to be fair, it's less about policy and more about personal trust.  Much like I'd sign your GPG key without a passport because I know you, that's not a policy everyone will have. :P
<rbasak> OK that's fair.
<infinity> rbasak: The technicality is there for a reason.  NEW *should* have a review.  But in practice, most AAs should trust that the SRU member in question isn't a derp and isn't lying about their review.
<apw> as we should never have them, i like the second set of eyes that implies
 * rbasak notes that infinity doesn't appear to have signed his key :-)
 * tsimonq2 -> moves here
<tsimonq2> infinity: I think I might want to stand my ground on not installing recommends for now, it's part of what makes Lubuntu lightweight, but I'm open to change if you have some stats for me to look at. ;)
<infinity> tsimonq2: It wasn't done to be "lightweight", it was done because of accidentally pulling in half of ubuntu or GNOME, if I recall. :P
<infinity> tsimonq2: MATE had the same issues, but managed to fix it in packages (sadly, after xenial, but better late than never)
<tsimonq2> infinity (cc flexiondotorg): I would be interested to see how MATE fixed this issue.
<slangasek> yes, I would expect any new package going into a stable release to be reviewed against the standard of "is this package already in devel? if not why not? are there deltas from the devel version? if so, why?"
<tsimonq2> infinity: Also, why is it painful for us to do this?
<tsimonq2> infinity: Does it cause some unnecessary overhead for you archive folks?
<slangasek> tsimonq2: because the set of things that are included in recommends down the stack from you is quite extensive
 * Laney is uploading a package to NEW to test if he can reject it
<infinity> tsimonq2: There's a bunch of special-casing in image build infra and such for no-follow-recommends, and it kinda sometimes works, and kinda sometimes doesn't.
<slangasek> that too
<slangasek> both infra overhead, and the unexpected behavior
<infinity> Plus, I sometimes have to fix bugs in lubuntu found because we add a recommends that you *don't* pick up, but really should.
<infinity> (The obvious one I can think of is thermald)
<tsimonq2> infinity: That makes sense.
<infinity> But I think you also recently saw pain because of xorg-input-synaptics.
<infinity> Same reason.
<tsimonq2> And I can see why it was done in the first place too, but like I said, I'm open to change. :)
<infinity> Recommends was meant to make sure it was on installation media, but not *required* post-install, no-follow-recommends breaks that assumption.
<wxl> historically, we've had issues trying to keep the installs cd sized but i think we can all agree we've given up on that one :)
<tsimonq2> infinity, slangasek: Any way we could do some sort of testing with removing no-follow-recommends? I'd like to look into the stats on that and see if it's worth doing.
<tsimonq2> wxl: Pretty much. ;)
<infinity> tsimonq2: I can help you do that in a PPA with some special builds next week.
<infinity> tsimonq2: THough a first step would be to remove it from a local branch of your seeds, update your meta against that local branch, and see how scary the result is.
<infinity> tsimonq2: The first pass will be... Rough.  You'll probably end up with half of unity and half of GNOME, and all of it will be redundant stuff you don't want. :P
<Laney> Yeah, I rejected it from zesty NEW and it worked
<tsimonq2> infinity: So then I go through and blacklist everything? XD
<tsimonq2> infinity: No, but seriously, from there, I just blacklist some of the super high level things?
<infinity> tsimonq2: No.  Then you start proposing fixes to packaging, ie: when something needs indicator-whosit, you might need to add some alternate deps, etc.  flexiondotorg might have helpful pointers there, but no point asking him until you have an idea of the damage.
<tsimonq2> infinity: Ok, I see.
<infinity> tsimonq2: Anyhow, the ongoing pain of no-follow-recommends is something I've lived with for years, so if you don't fix it until AFTER LXQt is a thing, that's fine by me.
<infinity> tsimonq2: But I figure if you're tearing out 200 packages and replacing them with 200 different ones, that's an ideal time to also look at conforming with how other flavours do things.
<infinity> tsimonq2: Wasting time fixing something that's going to be removed from the archive in 6 months is, well, wasting time.
<tsimonq2> infinity: Alright, that makes sense. I'll think about it, and I'll want to involve lubuntu-devel etc. for sure once I have some stats to work with.
-queuebot:#ubuntu-release- Unapproved: ktp-text-ui (xenial-proposed/universe) [4:15.12.3-0ubuntu1 => 4:15.12.3-0ubuntu2] (kubuntu)
<tsimonq2> infinity: About LXQt... at the moment I have a little tiny Launchpad team with a few PPAs and some hacky tooling on a VPS that makes some images. I plan on working on Lubuntu Next more, but is there something we can set up that will get Lubuntu Next images enabling those PPAs in the tooling with the rest of the flavors and the rest of our images? The problem right now is, I need to work on some va
<tsimonq2> rious packages to get some major work done on these packages and test some things, but I don't like piling things up for patch pilots to the point of insanity, and I want to test things fairly quick.
<tsimonq2> s/some various/some/
<infinity> tsimonq2: We can make the images build using a PPA, yes.
-queuebot:#ubuntu-release- Unapproved: mimedefang (xenial-proposed/universe) [2.78-1ubuntu1 => 2.78-1ubuntu1.1] (no packageset)
<tsimonq2> infinity: Is there something I need to propose a PR against, or can I just tell you what PPA?
-queuebot:#ubuntu-release- Unapproved: debian-installer (trusty-proposed/main) [20101020ubuntu318.41 => 20101020ubuntu318.42] (core)
<infinity> tsimonq2: We can just change the definition of the lubuntu-next livefs, or mangle it in crontab, but maybe ask me again in a few days when I have time to help you test that it's working after making the change?
<tsimonq2> infinity: Sure, when are you available?
<infinity> tsimonq2: Likely later this week.  Just not today. :P
<tsimonq2> infinity: I'm available pretty much all tomorrow except for the early afternoon... :P
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-contrib (yakkety-proposed/universe) [16.20151226 => 16.20151226ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nagios-plugins-contrib (xenial-proposed/universe) [16.20151226 => 16.20151226ubuntu0.16.04.1] (no packageset)
<slangasek> I wonder if I'm the only one who cares that sha256sum should be able to spawn multiple threads in order to checksum files in parallel
<tsimonq2> slangasek: That could be useful ;)
<xnox> slangasek, yes
<slangasek> xnox: yes I'm the only one or yes you'd find it useful? :)
<xnox> i do use gnu parallel with checksums
<tsimonq2> xnox: But why not bake it in? :P
<xnox> but the output is ugly; as it effectively results in loads of not found and one correct message per spawn.
<xnox> slangasek, yes
<infinity> Surely most sha256sum calls are I/O bound, not CPU bound.
<infinity> Well, at least where I care about speed (*cough* nusakan's SAN *cough*)
<xnox> infinity, asyncio for the win; my NMVe drive has multiple I/O queues one can use
<tsimonq2> infinity: What if you're doing a whole load of them, and you're verifying like 2000 files?
<tsimonq2> I wouldn't be surprised if slangasek hits that usecase.
<tsimonq2> (not like I know much about the internals of sha256sum :P)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu483.2]
<slangasek> xnox: right, so a 'sha256sum -j' that can launch a suitable number of threads
<tsimonq2> xnox: But that doesn't work on HFS, does it? I thought that old Mac filesystem can only read OR write one file at a time? :P
<slangasek> and collate the results
<tsimonq2> slangasek: So are you making that a thing? Then figuring out a way to make it work on HFS? XD
<slangasek> tsimonq2: I don't care at all about HFS, and I'm not committing to working on this, just gathering feedback to figure out if it might be worth it
<slangasek> right now I'm doing a number of local image builds, where the checksumming is a noticeable percentage of the build time
<tsimonq2> slangasek: And I was joking (:P), but in all seriousness, I think it's a good idea to make things parallel that aren't already.
<tsimonq2> infinity: What's the story behind Nusakan's SAN?
<tsimonq2> (Nukasansan? Nuka sansan? :P)
<xnox> imho trivial parallesation like that should be the default and out of the box, even if it results higher total cpu time usage
<xnox> e.g. git and cmake do that
<infinity> Even if it results in higher real time as well, due to disk thrash?
<xnox> i'd even go for that.
<slangasek> xnox: if it's by default, then you should have a flag to disable it?
<xnox> sure.
<slangasek> I'd still rather make it opt-in with -j
<xnox> slangasek, how many times have you disabled git parallelism?
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (trusty-proposed) [20101020ubuntu318.42]
 * xnox did it once server side, because it would hit OOM kill since it used to much RAM for repacking
<infinity> My git usage doesn't grind my machine for three hours like I did to nusakan a couple of weeks ago with hashing.
<infinity> And in cases where it can (ie: dists snapshots on snakefruit), we absolutely tweak it to cope.
<slangasek> xnox: never, but my CPU thread to disk ratio is different than others'
<xnox> imho nusakan case - one should be tweaking it from -j4 -> -j0; or from -j0 -> -j4 anyway
<xnox> the sensible default imho i think should be optimised for the most likely case of nvme/ssd disks; and my current hypothesis is that parallel by default will win wall clock time most of the time.
<tsimonq2> slangasek> I'd still rather make it opt-in with -j - +1 fwiw
<infinity> Sure, but I would contend that the "normal" use-case for hashing multiple files will be slower, wall-clock-wise, in parallel than serial.
<xnox> ack
<jgrimm> slangasek, the current draft for Curtin SRU Exception is at -> https://wiki.ubuntu.com/CurtinUpdates
<infinity> xnox: I don't think nvme/ssd is the "most likely case" for hashing large sets of files, that's where we disagree. ;)
<xnox> infinity, wouldn't in-sync RAID1 have faster read speed too? cause it's meant to balance and be able to read files off either drives?
<tsimonq2> I think I have to agree with infinity, I'm still on a 1 TB HDD :P
<infinity> xnox: Yeah, but it does it in chunks, not per-file, so if you assume a reasonably unfragmented FS, you're still going to lose to thrash if you pull stripes from both disks for two files at once.
<xnox> =(
<xnox> FAKE NEWS
<infinity> Hahaha.
 * xnox giggles
<infinity> And anything involving a network (a SAN, nbd, nfs, any number of network-backed VM storage solutions) will lose horribly when you try to stream multiple files at once.
<xnox> which is all of cloud
 * tsimonq2 thinks Juju something or other
<infinity> Usually a non-issue for small files, which is why git's default parallelism is generally okay, but thrashing between several large files hurts.
<slangasek> so arguably, a good implementation would have a parent process that streams the files from disk one chunk at a time, then dispatches to a set of worker threads
<infinity> It might also just have arbitrary cutoffs for parallelism based on size of target files.
<xnox> slangasek, do we still pointlessly produce SHA1 checksums?!
<infinity> If you can slurp down 20 files quickly and then munch on them, you win, if you're abusing your I/O with 4 1G ISOs, you lose.
<slangasek> xnox: in some places, probably.
<xnox> nice that one can slurp a chunk and feed it to multiple checksum algos simultaniously; cause i guess we still need to produce multiple checksums
<xnox> http://unix.stackexchange.com/a/163797
<xnox> cause i guess not reading everything 3 times over; beats anything
<infinity> Yes, reading each stream only once would be a greater win.  Especially if one can spit out md5/sha1/sha256/sha512 in parallel.
<infinity> And that would definitely keep your CPU cores busy.
<xnox> should be easy enough to write with python3 and hashlib
<xnox> and include sha3 as well
<infinity> That sort of happens naturally (ish) if you do one file at a time, but only if you have enough RAM to keep the cache hot.
<infinity> (Well, not the parallel bit, but the "read once" bit)
<infinity> But yeah, operating on the single read with multiple hashes would be nice.
<infinity> We could also stop producing some of those hashes.
<xnox> so where is this supposed to happen? on nousakan? launchpad livebuilders? somewhere else?
<xnox> cdimage code?
<infinity> But I don't want to do that without being able to give clear instructions to users of all OSes on how to validate better hashes.
<tsimonq2> Grrrrr, we've had a new sbuild in zesty-proposed for a while now, but I think it requires a new dpkg to pass through...
<tsimonq2> And the only justification to having a new dpkg is to have a new sbuild.
<tsimonq2> I don't think an FFe is justified, is it? :/
<slangasek> xnox, infinity: the bit that's prompting me to look at it right now is entirely in livefs builds, nothing to do with nusakan
<slangasek> but obviously we create checksums there also
<infinity> tsimonq2: Filing an FFe for dpkg would get you nowhere, as I wouldn't let you upload it. :P
<tsimonq2> infinity: Why not? :P
<tsimonq2> infinity: And what's a solution to this problem then?
<infinity> tsimonq2: "Not worrying about it" would be a solution.
<infinity> Is the new sbuild somehow necessary?
 * tsimonq2 searches for conversations with lisandro about new sbuild fixes this one annoying bug...
<infinity> (I'm looking at some dpkg cherry-picks this week, and perhaps that might allow me to relax the sbuild dependency, but if not, meh?)
<tsimonq2> infinity: tl;dr: lisandro> but sbuild -sd should not try to install B-D-I
<tsimonq2> infinity: Basically I was trying to build qtxmlpatterns-opensource-src 5.8.0 for Experimental on sbuild on my Zesty system, but I kept getting a stupid dep loop.
<tsimonq2> infinity: He told me to install Debian because they have a newer sbuild, I told him no. :P
<infinity> Or don't use sbuild to build your source package.
<tsimonq2> But it's the only thing I know how to use... :P
<infinity> To build your *source* package?
<infinity> I can count the number of times I needed a clean chroot to build a source package on one hand.
<infinity> (Obviously, I use sbuild to build binaries)
<tsimonq2> If you can't do anything, then *shrug* but expect a bug report as soon as Zesty+1 opens for development ;)
<tsimonq2> infinity: Binaries
<wxl> tsimonq2: it's called [y
<infinity> tsimonq2: But "-s" builds a source package.
<tsimonq2> infinity: Ok so then yeah, I obviously need to talk to lisandro and re-look at this one more time, I can read manpages /o\
<tsimonq2> wxl: Hm?
-queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.15-0ubuntu0.16.04.2 => 7.0.15-0ubuntu0.16.04.3] (kubuntu, ubuntu-desktop, ubuntu-server)
<tsimonq2> wxl: ^ why is php7.0 in the Kubuntu packageset? :P
<wxl> tsimonq2: the next character in ascii after z is [
-queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.15-0ubuntu0.16.10.2 => 7.0.15-0ubuntu0.16.10.3] (kubuntu, ubuntu-desktop, ubuntu-server)
<wxl> tsimonq2: and regarding php, don't ask me!
<nacc> mdeslaur: --^ fyi uploaded the fix, you'll want to take that into security too, i believe
<mdeslaur> thanks nacc
<wxl> oops i'm wrong. it's {
<tsimonq2> infinity: Apologies
<tsimonq2> wxl: Hahahahahahaha
<wxl> [ is the next after *Z* not *z*
<xnox> {
<xnox> ascii is weird
<tsimonq2> wxl, xnox: Let's write a whole DE in Brainf*** :P
<xnox> brainf*** is too high level; it should run directly on z/VM CMS
<tsimonq2> xnox: Hah :P
<nacc> jbicha: finally figured out a working setup
<nacc> jbicha: it was a half-baked change by Debian
-queuebot:#ubuntu-release- Unapproved: cifs-utils (yakkety-proposed/main) [2:6.5-2ubuntu1 => 2:6.5-2ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cifs-utils (xenial-proposed/main) [2:6.4-1ubuntu1 => 2:6.4-1ubuntu1.1] (desktop-core, ubuntu-server)
<bdmurray> Do any SRU team members have an opinion on adding uploader to the pending-sru report? It occurred to me I might not remember what I sponsored / uploaded and could / should verify.
<rbasak> Sounds reasonable.
<apw> bdmurray: sounds useful for poking people to verifh
<RAOF> Trevinho: It would be helpful if you left a comment as to what exactly you tested when marking bugs as verification-done, *particularly* when there are multiple packages being verified on the bug.
<Trevinho> RAOF: well... I've just redone what it's in the SRU test case in a clean install + proposed... For all the packages..
<RAOF> ...and if you'd said that in a comment when you flipped it to verification-done, I wouldn't have pinged you :)
<Trevinho> RAOF: true... But I thought it was quite the norm :-)
<Trevinho> RAOF: but thanks for asking anyway
<RAOF> Hm, no? People usually say what/how they tested when marking verification-done.
<RAOF> And I usually ask if they didn't. :)
#ubuntu-release 2017-03-01
<xnox> Trevinho, not any more, the norm has changed.
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.1 => 3.0~a57-1ubuntu25.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.8-0ubuntu1~ubuntu14.04.2 => 2.0.9-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.9-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-backports) [2.0.7-0ubuntu1~14.04.1]
<ginggs> would an ubuntu-archive person please look at LP: #1646836 ?
<ubot5> Launchpad bug 1646836 in python-skbio (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1646836
 * apw looks
<acheronuk> apw: could you maybe look at bug 1659926 & bug 1659934 ? that old KDE4 stuff now blocks important new Qt5/KF5 parts of present and future official KDE applications.
<ubot5> bug 1659926 in soundkonverter (Ubuntu) "Soundkonvertor - port to Qt5/KF5 or remove from zesty archive (please now remove)" [Undecided,Confirmed] https://launchpad.net/bugs/1659926
<ubot5> bug 1659934 in audex (Ubuntu) "Audex - port to Qt5/KF5 or remove from zesty archive (please now remove)" [Undecided,Confirmed] https://launchpad.net/bugs/1659934
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.3.0-0ubuntu1.2 => 2:8.4.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (xenial-proposed/main) [1:6.1.3-0ubuntu1 => 1:6.1.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (xenial-proposed/main) [1:6.1.0-0ubuntu1 => 1:6.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova-lxd (xenial-proposed/main) [13.2.0-0ubuntu1.16.04.1 => 13.3.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: swift (xenial-proposed/main) [2.7.0-0ubuntu2.1 => 2.7.1-0ubuntu1] (openstack, ubuntu-server)
<ginggs> thanks, apw !
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.0-0ubuntu1 => 2:9.1.1-0ubuntu1] (openstack, ubuntu-server)
<fossfreedom_> jbicha: this bug still occurs in the zesty version of gnome-control-center - is Ubuntu GNOME going to use the additional package workaround as suggested in that bug-report? https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1631750
<ubot5> Ubuntu bug 1631750 in gnome-control-center (Ubuntu) "Language installation doesn't work in Ubuntu GNOME 16.10 Settings app" [High,Confirmed]
<jbicha> fossfreedom_: uh, no I wasn't intending to, since that's poorly integrated with GNOME
<jbicha> we used to install that
<fossfreedom_> aye: just tried it - it works - just looks and feels very odd in comparison with the other GCC applets.
<jbicha> fossfreedom_: see also bug 1662031
<ubot5> bug 1662031 in gnome-control-center (Ubuntu) "Switching language and format broken" [Undecided,New] https://launchpad.net/bugs/1662031
<fossfreedom_> jbicha: feeling confident a solution could be found for 17.04?  Reason for the query - I'm wonder whether the odd looking applet should be added to our meta package so that at least users have a means of adding languages.
<jbicha> fossfreedom_: it's been broken for 5 months so odds are it won't be fixed this month
<fossfreedom_> understand.  cheers
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [0.1.0~bzr460-0ubuntu1~16.04.1 => 0.1.0~bzr470-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr460-0ubuntu1~16.10.1 => 0.1.0~bzr470-0ubuntu1~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.2-0ubuntu2 => 2:13.1.3-0ubuntu1] (openstack, ubuntu-server)
<slangasek> rbasak: you're EOD, right?
<slangasek> it looks like an EODish kind of time over there ;)
<xnox> yeah, british are slackers to stop working by 7pm
<slangasek> crazy socialists
 * xnox EOD
<slangasek> bdmurray: would you have time today to review the live-build package in xenial-proposed queue?
<davmor2> xnox: wuss
<apw> slangasek, i can look at that for you
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.8] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.7 => 1.66.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.2]
<apw> slangasek, bdmurray ^
<acheronuk> apw: thanks for looking at those removals :)
<apw> acheronuk, hopefully you are cleared out
<acheronuk> apw: it all worked and migrated as I hoped, if that is what you mean
<slangasek> apw: that would be lovely, thanks :)
<apw> acheronuk, that indeed
<apw> slangasek, already done
<slangasek> apw: woohoo
-queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0-0ubuntu2 => 1:7.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.1.0-0ubuntu1 => 2:9.1.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.1-0ubuntu1 => 1:7.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.1-0ubuntu1 => 3:10.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0-0ubuntu1 => 2:10.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.2-0ubuntu1 => 2:14.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.8]
-queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.10.0-0ubuntu1.1 => 2.10.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.8]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.8]
<jgrimm> sru folks, could someone look at releasing resolvconf in xenial-proposed? the yellow in pending-sru is for a bug that resolvconf no longer tracks, the other is green verify-done'd.   thinking it might not be hitting radars because of the glaring yellow bug yet.
<jgrimm> rharper, ^^ fyi
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.8 => 2.02~beta2-36ubuntu3.8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.8]
<rtg> xnox, infinity - I've removed block-proposed on linux 4.10.0-9.11. Please update d-i accordingly.
#ubuntu-release 2017-03-02
-queuebot:#ubuntu-release- Unapproved: apparmor (trusty-proposed/main) [2.10.95-0ubuntu2.5~14.04.1 => 2.10.95-0ubuntu2.5~14.04.2] (core)
<ginggs> how can a new package have an autopkgtest regression? http://autopkgtest.ubuntu.com/packages/a/ariba/zesty/amd64
<ginggs> weird, it's a build failure, but builds fine locally :(
<apw> ginggs, well it is a self-test failure apparently because it is core-dumping
<apw> ginggs, differnt compiler in zesty-proposed or something
<ginggs> apw: it's been failing since October though - scratches head
<apw> ginggs, it is possible a retry thinks they should be run when they should not
<apw> Laney, any idea why we are running (and failing) ADT testing on ariba when it has no binaries
<ginggs> http://autopkgtest.ubuntu.com/packages/a/ariba/zesty/amd64 shows a pass ??? 1.0.1-1 	cd-hit/4.6.6-1 	2016-08-04 21:29:51 UTC
<ginggs> i received this email from launchpad https://paste.ubuntu.com/24094899/ - is there anything that can or should be done about it?  it is unrelated to the memory leak that this upload fixed
<Laney> apw: dunno, probably wouldn't have expected britney to request that test
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.3]
<apw> Laney: could it be one of the rerun missing jobs perhaps
<Laney> apw: nah, 2017-01-27/23:21:55.log.gz:I: [Fri Jan 27 23:37:22 2017] - Requesting ariba autopkgtest on amd64 to verify ariba/2.7.1+ds-1
<apw> that is bananas
-queuebot:#ubuntu-release- New sync: pytest-qt (zesty-proposed/primary) [2.1.0-2]
-queuebot:#ubuntu-release- New sync: pytest-xvfb (zesty-proposed/primary) [1.0.0-2]
-queuebot:#ubuntu-release- New sync: python-h5netcdf (zesty-proposed/primary) [0.3.1-1]
-queuebot:#ubuntu-release- New sync: python-xarray (zesty-proposed/primary) [0.9.1+ds1-1]
<ginggs> apw: re ariba: disabled tests, built in a PPA, downloaded and installed .deb, runs test suite locally just fine
<ginggs> apw, Laney: i want to upload ariba ignoring the build-dtime test failures, are you still looking at the autopkgtest weirdness?  do you want me to wait?
<Laney> you want to ignore a binary which appears to be crashing?
<ginggs> Laney, I built it in a PPA, downloaded the deb and it passes the autopkgtests
<Laney> so why does it crash on the builder?
<ginggs> Laney: nafc
<Laney> hmmmm
<Laney> ginggs: well I don't think it's a good idea personally, but it's your call at the end of the day
<Laney> I might have a britney fix too
<ginggs> Laney: a britney fix for?
<Laney> requesting the tests when there are no binaries
<Laney> pushed that
<Laney> I think the test request should go away soon now
<ginggs> Laney: we can test that - i can upload ariba 2.7.1+ds-1build1 with no changes
<Laney> no need
<Laney> it should just forget that one
<ginggs> Laney: oh ok
<fossfreedom_> jbicha: is there a plan to uplift the version of GTK from 3.22.7 to 3.22.9 in zesty?  Reason for the Q - 3.22.9 breaks Arc-Theme so I'm wondering if I should plan on submitting a patch to Arc Theme to fix the 3.22.9 breakage.
-queuebot:#ubuntu-release- Unapproved: fglrx-installer (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.2 => 2:15.201-0ubuntu0.14.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fglrx-installer-updates (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.2 => 2:15.201-0ubuntu0.14.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.22.6 => 2.23] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.22.6+16.10 => 2.23+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.22.6~14.04 => 2.23~14.04] (no packageset)
-queuebot:#ubuntu-release- New source: nvptx-tools (zesty-proposed/primary) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted nvptx-tools [source] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted pytest-xvfb [sync] (zesty-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted python-xarray [sync] (zesty-proposed) [0.9.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted pytest-qt [sync] (zesty-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted python-h5netcdf [sync] (zesty-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New binary: nvptx-tools [ppc64el] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-recipes [source] (zesty-proposed) [0.16.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nvptx-tools [arm64] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvptx-tools [amd64] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvptx-tools [armhf] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvptx-tools [amd64] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted nvptx-tools [armhf] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New binary: nvptx-tools [i386] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvptx-tools [arm64] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New binary: pytest-qt [amd64] (zesty-proposed/none) [2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvptx-tools [ppc64el] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New binary: nvptx-tools [powerpc] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-xvfb [amd64] (zesty-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-xarray [amd64] (zesty-proposed/none) [0.9.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvptx-tools [s390x] (zesty-proposed/none) [0.20170301-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-h5netcdf [amd64] (zesty-proposed/none) [0.3.1-1] (no packageset)
<jbicha> fossfreedom_: yes, gtk3 is temporarily stuck in proposed because ubuntu-app-launch needs to not use upstart so it can build on s390x
<fossfreedom_> jbicha: thanks for the heads up.  I'll prepare a patch for arc-theme
<xnox> jbicha, which is proving to be a lot more work thatn originally forseen.
<xnox> jbicha, can you build gtk3 without mir on s390x?
<xnox> and hence without content-hub, ubuntu-app-launch, mir.
-queuebot:#ubuntu-release- New: accepted nvptx-tools [i386] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted nvptx-tools [s390x] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted pytest-xvfb [amd64] (zesty-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted python-xarray [amd64] (zesty-proposed) [0.9.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted nvptx-tools [powerpc] (zesty-proposed) [0.20170301-2]
-queuebot:#ubuntu-release- New: accepted python-h5netcdf [amd64] (zesty-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted pytest-qt [amd64] (zesty-proposed) [2.1.0-2]
<jbicha> xnox: yes, but I'd like the Desktop team to approve that
<xnox> jbicha, i'm sure they don't support mir on s390x =)
<jbicha> xnox: could you reask in #ubuntu-desktop?
<xnox> done
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (yakkety-proposed) [2.27-8ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: giflib (trusty-proposed/main) [4.1.6-11 => 4.1.6-11ubuntu0.14.04.1] (core)
<fossfreedom_> jbicha: another heads up - something from last nights 3.23.91 updates is crashing Ubuntu Budgie from launching any apps - the whole session dies.  Currently suspect the mutter update.  Investigating.
<jbicha> fossfreedom_: nvidia drivers?
<fossfreedom_> no - crashing for me in virtualbox.  just talking with a tester who is running on a physical thinkpad - I think that is intel
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (xenial-proposed/main) [2:8.3.0-0ubuntu1 => 2:8.3.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.1.1-0ubuntu1 => 2:9.2.0-0ubuntu1] (openstack, ubuntu-server)
<fossfreedom_> jbicha: any thoughts on this? yesterday uploaded was a new version of budgie-desktop - two patches.  I've rebuilt the package without those two extra patches but it still crashes.  If I install the budgie-desktop packages BEFORE yesterday all is well.  Seems like its the recompilation against the new stuff that is causing issues.
<fossfreedom_> I've recompiled against all the packages in zesty-proposed.  no joy
<jgrimm> bdmurray, are you on SRU duty today?  resolvconf in xenial-proposed needs released (the Yellow status bug in pending-sru is false positive, as no longer affects resolvconf).
<jgrimm> or slangasek as having history with that one ^
<bdmurray> jgrimm: I am but we are in a meeting at the moment
<jgrimm> np at all
<jgrimm> and nice change to pending-sru page, i like it!
<cyphermox> can someone please review/accept the network-manager-openvpn SRU for xenial?
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.1.3+bzr5573-0ubuntu1~16.04.1 => 2.1.4+bzr5591-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.3+bzr5573-0ubuntu1~16.10.1 => 2.1.4+bzr5591-0ubuntu1~16.10.1] (ubuntu-server)
<bdmurray> sil2100: I'm inclined to accept thermald without the DEP3 headers as I think the bug reference in debian changelog is good enough for an SRU.
<bdmurray> jgrimm: Is somebody going to verify the Yakkety version of resolvconf?
<bdmurray> sil2100: s/inclined/going/
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (yakkety-proposed) [1.5.3-4ubuntu1]
<jgrimm> bdmurray, yes I believe that should happen yet (rharper?)
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (yakkety-proposed) [1:2.0.10-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (xenial-proposed) [1:2.0.10-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted coreutils [source] (yakkety-proposed) [8.25-2ubuntu3~16.10]
-queuebot:#ubuntu-release- Unapproved: accepted coreutils [source] (xenial-proposed) [8.25-2ubuntu3~16.04]
<santa_> dear release wizards,
<santa_> we have been inspecting the status of okular and calligra migration from -proposed
<santa_> calligra right now provides okular-backend-odp and okular-backend-odt
<santa_> both have
<santa_> Recommends: okular
<santa_> and
<santa_> Enhances: okular
<santa_> from the proposed migration raw output:
<santa_> trying: okular
<santa_> skipped: okular (0, 10, 6)
<santa_>     got: 66+0: a-23:a-7:a-7:i-10:p-5:s-14
<santa_>     * amd64: okular-backend-odp, okular-backend-odt, okular-mobile
<santa_> â is the recommends or the enhances what is triggering the blocking?
<santa_> or is something else that I'm missing?
<nacc> santa_: i believe that is saying if okular were to migrate, okular-backend-odb and okular-backend-odt and okular-mobile become uninstallable on amd64?
<acheronuk> santa_: a KF5 okular would break the okular plugins of KDE4 calligra.
<apw> sounds like those use libraries from okular, so need rebuilding on top, something like that
<santa_> ok
<apw> santa_, normally i would then download the source for one of those and see if it does that
<santa_> yeah I think nacc got the answer, those okular backends are built using okular-dev
<acheronuk> the calligra in proposed is now KF5 and has had it plugins rebuilt against the new KF5 okular
<santa_> yes
<acheronuk> they need to migrate together. this time anyway.
<santa_> so we got a problem with calligra, and it's that is not migrating because of gcc-6 I presume at some point this would be fixed? because okular was @ -proposed as valid candidate for a while now
<santa_> and to be more specific the problem is this https://launchpad.net/ubuntu/zesty/s390x/calligrasheets/1:3.0.0.1-0ubuntu2
<santa_> libgcc1 (>= 1:6.3.0-5ubuntu1)
<apw> yeah it is tied to gcc-6 which may or may not migrate
<santa_> that's higher than the version out of -proprosed
<santa_> so do you have any suggestion to deal with this?
<apw> well we need to get gcc-6 to migrate, someone need to look at why it is not
<acheronuk> I note that there have been a fir few gcc-6 and binutils uploads, which just fail each time on the same tests
<santa_> failing autopkgtest on linux apparently
<santa_> also note that there are other archs which doesn't have a depend so strict https://launchpad.net/ubuntu/zesty/amd64/calligrasheets/1:3.0.0.1-0ubuntu2
<nacc> i believe this is a known issue with the linux test and mismatches
<apw> if it is just those, if that is the armhf thing with 'error: not found'
<nacc> i saw some discussion of it before, at least
<nacc> "ERROR: running version does not match source package"
<santa_> so I presume the only option is to wait for gcc migration to be fixed, or is there any possible workaround?
<apw> nacc, oh that might just need rerunning with -proposed
<apw> enabled or with the kernel as trigger too
<nacc> apw: yeah, i think that's true -- not sure why it passed onthe other archs
<apw> which arch failed ?
<nacc> amd64
<nacc> ah i think i see why
<nacc> whenever the amd64 test ran, 4.10.0.11 was in proposed
<nacc> but for the other arches, it wasn't (afaict)
<acheronuk> binutils was also filing against linux for a long time. I see there is a new upload of that today, but not sure that will pass. and that holds back gcc-6 if it fails
<nacc> err, 4.10.0-11 that is
<acheronuk> *failing
<nacc> apw: are you retrying those?
<apw> nacc, that has -signed so it might take a bit longer to get to the pocket safely
<nacc> apw: ack
<apw> nacc, i am trying to sort out a snapd fire, so if you could restart them i'd appreciate not thinking about it
<nacc> apw: yep, doing it now
<santa_> thank you very much for digging into it
<santa_> while I'm here I would to ask other question
<santa_> recently I made some stuff to track the status of kde's packaging migrations
<santa_> is there a better way to get the information from the update excuses page other than parsing the html page?
<santa_> (that's what I'm doing right now, because, apparenly that's what grep-excuses from debian does)
<santa_> but suggestions are welcomed
<apw> santa_, there is .yaml version of that same page, which most sensible things parse against
<apw> well load and sift through
<nacc> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.yaml
<nacc> santa_: --^
<santa_> apw, nacc: parsing the yaml should be better, thanks, fyi what I'm working is on python code to provide things like this: http://gpul.grupos.udc.es/ka-iron-hand_reports/plasma_archive/5.9.3_zesty_proposed_migration.pdf
<santa_> or this http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.1_zesty_proposed_migration.pdf
<santa_> an edge a -> b means b build depends on any of the binary packages provided by a
<santa_> if we finally file an FFE for kdepim we hope this kind of information is useful for us and for you
<santa_> the apps one could give you a hint about new reviewing order
<nacc> santa_: the picture is nice, although i think of the arrows in the opposite direction (without changing their meaning :)
<santa_> nacc: haha, yeah that's in the eye of the beholder I guess, I think more about the meaning of the arrows as "building will go in this order"
<nacc> santa_: makes sense
<sil2100> bdmurray: ok, sure
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.23+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.23]
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (xenial-proposed/universe) [0.58.2 => 0.58.3] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.71 => 0.71.1] (ubuntugnome)
<jbicha> bdmurray: could you accept the ubuntu-gnome-meta SRUs ^ since I'd like to have them in -updates by next week?
<bdmurray> jbicha: I don't know without reviewing them. ;-)
<jbicha> :)
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (yakkety-proposed) [0.1.0~bzr470-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr470-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (yakkety-proposed) [0.71.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (xenial-proposed) [0.58.3]
-queuebot:#ubuntu-release- Unapproved: accepted mimedefang [source] (xenial-proposed) [2.78-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted exiv2 [source] (xenial-proposed) [0.25-2.1ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-weather [source] (xenial-proposed) [3.18.1-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted imagej [source] (xenial-proposed) [1.50d+dfsg-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- New binary: gnome-recipes [ppc64el] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [i386] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [armhf] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [amd64] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [arm64] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [powerpc] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-recipes [s390x] (zesty-proposed/universe) [0.18.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maas (trusty-proposed/main) [1.9.4+bzr4592-0ubuntu1~14.04.1 => 1.9.5+bzr4599-0ubuntu1~14.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.5]
-queuebot:#ubuntu-release- Unapproved: accepted giflib [source] (trusty-proposed) [4.1.6-11ubuntu0.14.04.1]
#ubuntu-release 2017-03-03
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-11.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-11.13]
-queuebot:#ubuntu-release- New source: retro-gtk (zesty-proposed/primary) [0.9.91-0ubuntu1]
-queuebot:#ubuntu-release- New source: gnome-games-app (zesty-proposed/primary) [3.23.91-0ubuntu1]
-queuebot:#ubuntu-release- New source: gnome-games-app (zesty-proposed/primary) [3.23.91-0ubuntu1]
<jibel> apw, 2.22.6 verified on trusty. It was a problem with services started as systemd services on trusty but without service files.
-queuebot:#ubuntu-release- New binary: ariba [amd64] (zesty-proposed/universe) [2.7.1+ds-1ubuntu1] (no packageset)
<apw> jbicha, two gnome-games-app uploads?
<apw> jibel, ack
<jamespage> please could a member of the release team review bug 1668934 for me; I think its a bit of a no brainer but would like an official +1
<ubot5> bug 1668934 in percona-xtradb-cluster-5.6 (Ubuntu Zesty) "percona-xtradb-cluster-5.6 5.6.34-26.19, percona-galera-3 3.19, percona-xtrabackup 2.3.7" [High,Triaged] https://launchpad.net/bugs/1668934
<jamespage> rbasak: could you give me a pre-SRU review for that as well please ^^ its a little outside the norm in terms of version bumps required.
<rbasak> ack
<Mirv> dear whoever could look at autopkgtests, me and Saviq have lots of xenial PPA tests that are claimed to be running but actually are nowhere in running page, either running or in queue for some hours: https://bileto.ubuntu.com/excuses/2523/xenial.html / https://bileto.ubuntu.com/excuses/2519/xenial.html
<Mirv> is there a known hickup in the infrastructure and/or could some mass-retry them?
<Laney> yes
<Laney> the kernel rollback yesterday borked the cloud images
<Laney> but I don't have an overview of the missing requests
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.3]
<Laney> Mirv: If you give me a few minutes I am rolling new images which should work, then you can retry things
<rbasak> jamespage: I'm not keen on this. Is backporting the security fixes not feasible?
<rbasak> Things like "Variable wsrep_dirty_reads now has Global scope as well" sound like they could change behaviour.
<jamespage> rbasak: 5.6.21->5.6.34 + oracle policy on not detailing the actual commits...
<Laney> Mirv: ok, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-2523/xenial/amd64/u/ubuntu-system-settings-online-accounts/20170303_101553_783a5@/log.gz worked
<rbasak> The Oracle originating changes I'm less bothered about.
<Laney> go ahead and retry all RUNNING xenial tests
<rbasak> It's the Percona layering on top.
<Laney> and RUNNING-ALWAYSFAIL
<rbasak> Does Percona provide any stability/no-behavioural-change statement?
<jamespage> rbasak: I'd have to dig into that to find out
<jamespage> rbasak: but I suspect so
<rbasak> eg. 5.6.34-26.19 deprecates some encryption modes.
<rbasak> As long as it's just deprecation I guess that could be OK.
<jamespage> rbasak: I agree about being uncomfortable about some of the percona overlay, but I don't think there is a practicable way forward of updating for security issues, without taking any changes in the percona overlay as well
<jamespage> rbasak: lemme ping georgelorch and see
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.23~14.04]
<Mirv> Laney: great, thanks!
<Saviq> Laney, could you do the reruns? we don't have access to snakefruit (CC Mirv)
<Saviq> as you were :)
-queuebot:#ubuntu-release- Unapproved: rejected thunar [source] (yakkety-proposed) [1.6.11-0ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.10-2ubuntu2 => 1.6.11-0ubuntu0.16.10.1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected thunar [source] (xenial-proposed) [1.6.11-0ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.10-2ubuntu1 => 1.6.11-0ubuntu0.16.04.1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (yakkety-proposed) [1.6.11-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (xenial-proposed) [1.6.11-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: nova-lxd (yakkety-proposed/main) [14.1.0-0ubuntu0.16.10.1 => 14.2.0-0ubuntu0.16.10.1] (ubuntu-server)
<jbicha> apw: please reject the older gnome-games-app
-queuebot:#ubuntu-release- New: rejected gnome-games-app [source] (zesty-proposed) [3.23.91-0ubuntu1]
<apw> jbicha, ^ done
<rbasak> jamespage: I wonder if this should actually be a security upload through the security pocket though.
<jamespage> rbasak: quite possibly
<rbasak> mdeslaur: ^ opinion on bug 1668934 please? We're discussing updating to the latest point release, which includes feature changes. It is based on MySQL, so similar policies apply. Wondering if it should actually go through the security pocket.
<ubot5> bug 1668934 in percona-xtradb-cluster-5.6 (Ubuntu Zesty) "percona-xtradb-cluster-5.6 5.6.34-26.19, percona-galera-3 3.19, percona-xtrabackup 2.3.7" [High,Triaged] https://launchpad.net/bugs/1668934
<mdeslaur> rbasak: were there substantial package changes, or pretty much just a version bump?
<mdeslaur> rbasak: ideally, it should end up in the security pocket, but whether or not it goes though the sru process first is up to you
<mdeslaur> depending on how confident you are with the changes
<jamespage> mdeslaur: I've been testing the updates for the last few days - its testing OK
<mdeslaur> jamespage: ok, if you feel they're ready, stick them in a ppa somewhere and subscribe ubuntu-security-sponsors to the bug, and someone will sponsor them next week
<jamespage> mdeslaur: great thankyou
<jamespage> mdeslaur: I'm assuming you'd like me to push the updates to zesty myself first
<mdeslaur> sure, please
<jamespage> mdeslaur: I'll get those done today
<mdeslaur> thanks
<rbasak> mdeslaur: thanks.
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-0ubuntu1~16.10.1 => 0.7.9-47-gc81ea53-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: zlib (xenial-proposed/main) [1:1.2.8.dfsg-2ubuntu4 => 1:1.2.8.dfsg-2ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: zlib (yakkety-proposed/main) [1:1.2.8.dfsg-2ubuntu5 => 1:1.2.8.dfsg-2ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-0ubuntu1~16.04.2 => 0.7.9-47-gc81ea53-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted zlib [source] (yakkety-proposed) [1:1.2.8.dfsg-2ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted zlib [source] (xenial-proposed) [1:1.2.8.dfsg-2ubuntu4.1]
<Xz_> hi there, do you use jenkins for building ubuntu?
<cjwatson> Some individual projects that feed into Ubuntu do, but not in general
<Xz_> cjwatson: is that jenkins public? can I go there and check it out?
<infinity> Xz_: I think you misread.  Ubuntu does not use jenkins to build Ubuntu.  Some of our upstream projects do, but those are many jenkins all over the place.
<wxl> Xz_: kubuntu uses jenkins, but like cjwatson said, it's for upstream stuff http://kci.pangea.pub/
<Xz_> wxl: thanks!
<Xz_> cjwatson: I understood, I wanted to see other ubuntu-related projects that use jenkins
<Xz_> cjwatson: by the way, what does ubuntu use for build & release?
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-openvpn [source] (xenial-proposed) [1.1.93-1ubuntu1.1]
<bdmurray> rbasak: At one point in time you commented in a bug about being curious about a Gnome microrelease exception.  That's a historical thing https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-September/001152.html - you can find gnome in r59 of the MRE page.
<robru> Laney: you around? do you have a minute to help me identify specific package which match all the different email cases? So far I have a bileto upload and (I think) a direct core dev upload, still need to find examples of debian manual&auto syncs, sponsored archive copies, etc
<apw> robru kerne
<apw> robru: kernel packages are copies
<infinity> robru: https://launchpad.net/ubuntu/+source/vala/0.34.5-1 <-- Manual sync.
<robru> apw: got that one, thanks. I need an example of a package that was uploaded directly to archive (not copied from PPA or debian), but sponsored. I was cruising excuses and all the ones I saw were direct unsponsored uploads
<infinity> apw: Except when they're not. ;)
<apw> infinity: true ;)
<apw> robru: grep-merges apw has packages I have uploaded and sponsored
<robru> infinity: sponsor any uploads recently?
<apw> and you can tell them apart
<robru> apw: http://paste.ubuntu.com/24104660/ uh
<infinity> https://launchpad.net/ubuntu/+source/kerneloops/0.12+git20140509-2ubuntu1
<infinity> Yes, grep-merges appears to have developed a bug. :P
<infinity> Anyhow, the bove is a sponsored direct upload.
<infinity> s/bove/above/
<infinity> https://launchpad.net/ubuntu/+source/gem2deb/0.33.1 <-- Autosync.
<infinity> robru: A manual sync and autosync should look the same, except that the copy was performed by ~katie for autosyncs, and emailing her will get you nowhere. :P
<apw> robru yeah but that is two direct uploads and a sponsored upload
<robru> infinity: apw: thanks
<apw> infinity: I think I have a fixed version of that here somewhere
<infinity> apw: If only you could commit to lp:ubuntu-dev-tools (hint: you can).
<apw> yeah I know, I am a tool
<infinity> Oh, and it's already fixed in bzr.
<infinity> Maybe I should do a Debian upload and sync. :P
<apw> heh good, who fixed it
<infinity> mitya57.
<infinity> Should probably do a pass on the bug list, see if there are any easy ones to bump off, then cut a release.
<infinity> No one's upload since last May, and that was me. :/
<nacc> we've gotten a few pings in the past few days about the linux-image-generic update for 4.4.0-65 that was deleted from updates and security
<infinity> Not sure how I became the maintainer of u-d-t...
<nacc> do we have a documented "here's how you fix your systems"?
<infinity> nacc: What's to fix?
<infinity> nacc: People who upgraded in that window are just on newer kernels, but there aren't actually any known issues with it.
<nacc> https://askubuntu.com/questions/889126/package-linux-image-4-4-0-65-generic-needs-to-be-reinstalled
<nacc> except it didn't succesfully install for more than one person
<nacc> and they can't reinstall that package as it's no longer there (afaict)
<infinity> nacc: Uhh.  The failure to install is weird and entirely unrelated to us removing it from the archive.
<nacc> infinity: just want to make sure we give a good answer in #ubuntu
<nacc> infinity: agreed, but ... it's happening :)
<infinity> Like, often?
<nacc> not sure yet
<infinity> I've literally never seen the message "package linux-image-4.4.0-65-generic needs to be reinstalled, but I can't find an archive for it"
<nacc> there were a lot of pings about it overnight, it seems (which makes sense)
<infinity> I can't even think of what would print such a message.
<nacc> yeah, me neither, so i'm not sure
<infinity> Anyhow, for people who upgraded in the window but don't otherwise have a problem, the answer is "you don't have a problem".
<nacc> right
<infinity> For the few people who have unrelated problems and are grumpy that they can't --reinstall or similar, the answer would be to purge the kernel.  Though if I knew WHAT was printing that message, I couldbe more clear.
<infinity> Maybe a "dpkg --configure -a" is all that's needed (ie: maybe that's a message from update-manager when it detects an interrupted install?)
<nacc> infinity: yep, i'm asking for details, thanks
<nacc> infinity: yeah, it's a GUI that printed that message in this particular case, but they are remotely helping someone in a different country, so not sure which one. update-manager seems likely. I'm fine with the stated purge if needed
<nacc> infinity: hrm, apparently that string is in libapt-pkg.so somewhere
<infinity> nacc: Oh.  But it means some higher level tool (or human) *asked* for "apt-get install --reinstall <package>" and then apt couldn't find <package>
<nacc> infinity: yeah, that's my understanding, and i don't know which tool did that yet :)
<nacc> infinity: in any case, you've answered my questions, and it's what i expected, thanks!
<infinity> nacc: Do I get a gold star?
<nacc> !goldstar | infinity
<nacc> infinity: sadly, ubot5 doesn't know about them
<Ukikie> !cookie
<ubot5> Wow! You're such a great helper, you deserve a cookie!
<infinity> Great, now I'll get fat(ter).
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (yakkety-proposed) [0.7.9-47-gc81ea53-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-47-gc81ea53-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.4+bzr5591-0ubuntu1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.1.4+bzr5591-0ubuntu1~16.04.1]
#ubuntu-release 2017-03-04
<rbasak> bdmurray: thanks!
<bdmurray> rbasak: no problem
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (trusty-proposed/universe) [8-2ubuntu4~ubuntu14.04.1 => 8-2ubuntu4~ubuntu14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (trusty-proposed/universe) [0.32 => 0.32.1] (ubuntugnome)
<LocutusOfBorg> apw, Laney please ignore virtualbox autopkgtestsuite and let it migrate :)
<LocutusOfBorg> thanks!
#ubuntu-release 2017-03-05
-queuebot:#ubuntu-release- New: accepted gnome-recipes [amd64] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [armhf] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [powerpc] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [s390x] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [arm64] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [ppc64el] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-recipes [i386] (zesty-proposed) [0.18.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ariba [amd64] (zesty-proposed) [2.7.1+ds-1ubuntu1]
-queuebot:#ubuntu-release- New binary: libbluray [i386] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [ppc64el] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [arm64] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [s390x] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [amd64] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [armhf] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libbluray [powerpc] (zesty-proposed/universe) [1:1.0.0-2] (kubuntu)
#ubuntu-release 2018-02-26
<tsimonq2> (Mesa should not migrate until qtbase is uploaded, and that'll be another couple of days, hopefully not longer.)
<tsimonq2> ((Core Qt bootstrapping for 5.9.4 is complete, so it just depends on how quickly I can get through the other uploads... #ubuntu-qt has more details.))
<tsimonq2> infinity: Is that glibc transition something that will collide with the Qt transition? That's close to being ready-to-land and I don't want to break things. :)
<slangasek> tsimonq2: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt shows the list of packages that need updated for glibc to get in (once tests are resolved); it's a small list and almost certainly not entangled w/ Qt, but if you want to double-check, there it is.  Also, is this Qt transition something that will collide with the curl transition?
<tsimonq2> slangasek: I'm not sure what the curl transition involves but https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3113/+packages https://pad.ubuntu.com/BhiLYwz07Y + no-change rebuilds of qtbase and qtdeclarative rdeps + sddm is what it is
<tsimonq2> slangasek: It's a bugfix Qt release.
<slangasek> tsimonq2: anything that depends on libcurl3 will need rebuilt
<slangasek> I know there are some KDE packages affected
<tsimonq2> slangasek: I'd have to check.
 * tsimonq2 does so
 * slangasek kicks off the rebuilds of the things needing rebuilt for glibc; no reason to wait
<tsimonq2> Cool
<tsimonq2> slangasek: One thing I've always relied on either Ben or Britney to tell me but I can't seem to figure out how to do is find rdeps of e.g. qt{base,declarative}-abi-5-9-3
<slangasek> grep-dctrl is your friend
<tsimonq2> Ahh, nice.
 * tsimonq2 RTFMs
<slangasek> good news, 'grep-dctrl \( -FDepends qtdeclarative-abi-5-9-3 -o -FDepends qtbase-abi-5-9-3 \) -a -FDepends libcurl3 /chroots/bionic/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_*amd64_Packages' returns no results
 * tsimonq2 notes that command for future ref, thanks
<tsimonq2> Once the monster that is qtwebengine (embedded Chromium, it's like a 200 MB source package that takes hours to compile, fun) is done building here, the rest of the Qt transition should take little to no time.
<tsimonq2> So my original estimate was two days but it might be ready by tomorrow afternoon(ish) (UTC-6)
<tsimonq2> slangasek: Is that OK from a Release Team perspective or do you think glibc needs more time (for some reason)?
<tsimonq2> ("the rest of the Qt transition" in Bileto, that is)
<slangasek> tsimonq2: glibc + qt shouldn't get in the way of each other, from what I see, so no reason to delay on account of glibc
<tsimonq2> slangasek: OK, cool. Thanks.
<tsimonq2> Tonight I'll start the Britney checks in Bileto so it has time to process while I'm asleep.
<slangasek> I see someone's been retrying colord/armhf a few times against glibc... that probably needs an updated valgrind
 * RAOF needs to do the last bits required to release a new colord in Debian and sync.
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Artful 17.10 | Archive: open | Bionic Release Coordination, 16.04.4 in progress | 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
<sil2100> Note to any SRU members around - for the time of the point release, please don't promote things from xenial-proposed to xenial-updates
<sil2100> Not sure if we have any lock for that now as I probably don't have the powers for doing it
<tsimonq2> sil2100: generate-freeze-block could be what you're looking for, although that mightt be just for devel...
<tsimonq2> Â¯\_(ã)_/Â¯
<apw> sil2100, ack
<apw> tsimonq2, as we don't gate sru's yet via britney it won't help sadly, and in fact everything is blocked
<tsimonq2> apw: Ah ok
<tsimonq2> Not just seeded stuff?
<tsimonq2> What's the reasoning there?
<tsimonq2> Also, TIL about not using Britney for that :)
<sil2100> Well, not seeded stuff can go in I guess, but since people rarely check that I just mentioned in overall
<apw> sil2100, keep it at "don't" for now, makes people think before they act
<apw> tsimonq2, yeah it is in the plan, just never seems to hit the top of the list
<tsimonq2> apw: Got something along the lines of a spec somewhere for that?
<apw> tsimonq2, heh as far as i know it is in infinity's head
<tsimonq2> :D
<mitya57> slangasek, tsimonq2: âgrep-dctrl \( -FDepends qtdeclarative-abi-5-9-3 -o -FDepends qtbase-abi-5-9-3 \) â¦ returns no resultsâ
<mitya57> That's because we did not bump the ABI version last time, and it was 5-9-2.
<tsimonq2> Ahh
<tsimonq2> Right
<mitya57> Well, for qtbase only, for qtdeclarative I think it was bumped.
<jibel> sil2100, on ubuntu desktop 20180223.1 it still says 16.04.3
<infinity> jibel: Fixed.
<infinity> sil2100: ^-- When you updated debian-cd, you missed a 'bzr pull' at nusakan:~cdimage/cdimage/debian-cd
<infinity> sil2100: So, you get to spin another set with the correct versions. :P
<infinity> sil2100: I'll leave that to you.
<jibel> infinity, thanks
<sil2100> hmmm
<sil2100> Ah, crap, I know what happened
<sil2100> Since the bzr checkout was actually from nusakan I assumed it's directly to the right branch
<sil2100> duh, still needed that bzr pull from the private bzr place to production
<sil2100> Stupid me, assuming bzr push pushes to production directly
-queuebot:#ubuntu-release- New: accepted gnome-keyring [amd64] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-keyring [armhf] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-keyring [ppc64el] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-keyring [arm64] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-keyring [s390x] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-keyring [i386] (bionic-proposed) [3.27.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [amd64] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [armhf] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [ppc64el] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [arm64] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [s390x] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted udisks2 [i386] (bionic-proposed) [2.7.6-1ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.4] has been updated (20180226)
<Laney> can someone promote for https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1749912 please? https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<ubot5`> Ubuntu bug 1749912 in libglvnd (Ubuntu) "MIR: libglvnd" [Wishlist,Fix committed]
<apw> Laney, looking
<Laney> merci!
<Laney> should make mutter become a candidate in excuses
<Laney> and gnome-session..?
<apw> Laney, done
<Laney> apw: thanks!
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.4] has been updated (20180226)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.4] (20180226.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.4] has been updated (20180226.1)
-queuebot:#ubuntu-release- New binary: curl [s390x] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: curl [i386] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: curl [ppc64el] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: curl [amd64] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: curl [arm64] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: curl [armhf] (bionic-proposed/main) [7.58.0-2ubuntu2] (core)
<coreycb> hello, can an archive admin review percona-xtradb-cluster-5.7 in the bionic NEW queue?
-queuebot:#ubuntu-release- Unapproved: apache2 (xenial-proposed/main) [2.4.18-2ubuntu3.5 => 2.4.18-2ubuntu3.6] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: corosync (artful-proposed/main) [2.4.2-3build1 => 2.4.2-3ubuntu0.17.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pacemaker (artful-proposed/main) [1.1.16-1ubuntu1 => 1.1.16-1ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: corosync (xenial-proposed/main) [2.3.5-3ubuntu2 => 2.3.5-3ubuntu2.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pacemaker (xenial-proposed/main) [1.1.14-2ubuntu1.3 => 1.1.14-2ubuntu1.4] (ubuntu-server)
<apw> Laney, you have a couple of ADT test failures still holding it back
-queuebot:#ubuntu-release- New source: ksmtp (bionic-proposed/primary) [17.12.2-0ubuntu1]
 * Laney meows at apw 
<Laney> which it?
<apw> that lib thing you had me promote
<Laney> mesa?
<Laney> oh yeah it's not going in just now anyway due to mesa I don't think
<Laney> not that I know what the issue is
<Laney> tseliot: is this fixed by the new nvidia in NEW?
<tseliot> Laney: what is "this"? I think I got disconnected
<Laney> oh right, the nvidia / mesa / libglvnd stuff going on in proposed atm
<tseliot> yes, ideally it would all land at the same time
<Laney> think the breaks are set up so that it will
<Laney> but nvidia-340 & 384 seem uninstallable
<xnox> tseliot, btw. should 304 be fixed up? there is a patch, that somebody on the forums wrote to make it compile with v4.15.
<xnox> tseliot, it does change the module license....
<tseliot> Laney: I have changes for 340, but I was waiting for the new xserver to land first. Also, 390 will replace 384
<Laney> okey
<tseliot> xnox: 304 should be dropped. tjaalton filed a bug report about it
<Laney> well mesa isn't actually trying to go in yet
<tseliot> good thing I need to fix some stuff in nvidia first
<tseliot> 390
<seb128> it's annoying that this stack is not ready, it's blocking other transitions and features in proposed now :/
<tseliot> my drivers are ready to go. I don't know what's blocking mesa, to be honest
<apw> mesa seems to be being held because of a fair number of adt regressions
<nacc> apw: i believe tjaalton is working on a transition, but i'm not 100%
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.2-0ubuntu4 => 2:9.1.2-0ubuntu5] (openstack, ubuntu-server)
<slangasek> tjaalton: fwiw processing Debian removals, s2tc is dropped because Debian bug #888430 says it's obsolete as of mesa 17.3, which we have in bionic.  I'm assuming that makes it ok to drop, but shout if I'm wrong
<ubot5`> Debian bug 888430 in ftp.debian.org "RM: s2tc -- ROM; superseded by native s3tc support in mesa" [Normal,Open] http://bugs.debian.org/888430
<jbicha> yay, removals
<slangasek> infinity: was that you retrying awesome/armhf in a loop to try to get it to pass?  looks flaky/racy here, maybe time for a badtest?
-queuebot:#ubuntu-release- Unapproved: accepted corosync [source] (artful-proposed) [2.4.2-3ubuntu0.17.10.1]
<infinity> slangasek: Dunno about "in a loop", I may have tried it a couple of times.
<slangasek> k :)
-queuebot:#ubuntu-release- Unapproved: rejected pacemaker [source] (artful-proposed) [1.1.16-1ubuntu2]
<ddstreet> sil2100 re: 16.04.4, is everything currently in the xenial upload queue waiting until march 2 before it's accepted/rejected?
<infinity> ddstreet: No.
<ddstreet> infinity ok so it'll proceed into -proposed as usual?  just wait there until after point release?
<infinity> ddstreet: Things can be reviewed and accepted into -proposed, there's just a lock on releasing from -proposed to -updates.
<ddstreet> awesome thnx!
<slangasek> tsimonq2: ^^ speaking of which, what conclusions did you reach wrt the Lubuntu-specific SRUs for 16.04.4?
<tsimonq2> slangasek: They can land after the point release .
<sil2100> ddstreet: as infinity said
<slangasek> tsimonq2: ok cool
<flocculant> sil2100: thanks - I noticed the 16.04.3 on Saturday - but you were off doing life, so couldn't ping you :p
<tsimonq2> Out of curiosity, what's the reasoning behind  blocking even non-seeded packages froo migrating to xenial-updaytes?
<tsimonq2> (grr @ mobile keyboard)
<infinity> tsimonq2: There's no reason they can't, except that migrations are a manual process, and "don't do it" is easier than "do it, but double-check all these lists and don't screw up".
<tsimonq2> infinity: Ah, makes sense.
<tsimonq2> Thanks.
<sil2100> flocculant: yeah, sorry about that!
<flocculant> sil2100: not too worried - expected at least 1 respin before Thursday - and after installing it was calling itself 16.04.4 :p
<slangasek> fpc autopkgtest fails because it succeeds. Well job
<flocculant> sil2100: shame the ubiquity change re keyboard layout choice wasn't in - I'm failing the lvm test for us - not that it stops me marking it ready
<infinity> slangasek: Having a working Pascal compiler does seem like it could be qualified as a failure.
<sil2100> flocculant: yeah, it's fixed for bionic but we didn't backport it yet indeed
<sil2100> Maybe next point-release then
<nacc> slangasek: could you review the updated removals in LP: #1749745? today? i'm uploading the reverse-recommends drops now, and after the bug is processed, we should be able to remove php7.1
<ubot5`> Launchpad bug 1749745 in zoneminder (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New] https://launchpad.net/bugs/1749745
<flocculant> ack
<slangasek> sergiusens: I'm triggering autopkgtests of the snapcraft in release against the maven in release, to hopefully confirm whether this failure is already present in that version; if so we should badtest it and let snapcraft migrate
<slangasek> sergiusens: (unless this is a new test which doesn't exist at all in the release version?)
<sergiusens> slangasek: the snapcraft that is released might not work in 18.04 as this is the release that has all the bits; I can manually check with an older version of maven on my side
-queuebot:#ubuntu-release- Unapproved: pacemaker (artful-proposed/main) [1.1.16-1ubuntu1 => 1.1.17+really1.1.16-1ubuntu2] (ubuntu-server)
<slashd> sil2100, ^
<sil2100> slashd: thanks!
<slangasek> sergiusens: well, the point of my test is to establish whether this is already broken in the release pocket, and if so allow the snapcraft to migrate because it's not a regression; your bit sounds more useful for fixing the broken autopkgtest, which is something I would leave to you
-queuebot:#ubuntu-release- New: accepted okular [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [amd64] (bionic-proposed) [4:17.12.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted okular [armhf] (bionic-proposed) [4:17.12.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted okular [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted okular [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [i386] (bionic-proposed) [4:17.12.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted okular [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted okular [s390x] (bionic-proposed) [4:17.12.2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted okular [arm64] (bionic-proposed) [4:17.12.2-0ubuntu2]
<sergiusens> slangasek: http://autopkgtest.ubuntu.com/packages/s/snapcraft/bionic/amd64 ... "snapcraft/2.39.2+18.04" was green and "snapcraft/2.39.2+18.04.2" failed and my local debdiff between those two show no relevant affecting changes http://paste.ubuntu.com/p/CM7DfghzK4/
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (artful-proposed) [1.1.17+really1.1.16-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted corosync [source] (xenial-proposed) [2.3.5-3ubuntu2.1]
<tjaalton> slangasek: they're right, s2tc can be dropped. the recommends on libtxc-* were left over after a merge, and I have dropped them from git
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (xenial-proposed) [1.1.14-2ubuntu1.4]
<tjaalton> hrm, the kde autopkgtests tend to be less useful, they just say "fail" and nothing to debug other than blindly retry until they pass
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [amd64] (bionic-proposed) [390.25-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [i386] (bionic-proposed) [390.25-0ubuntu1]
<slashd> davecore, ^^
<davecore> slashd: ack
<slangasek> nacc: huh, cakephp-scripts shows up as a revdep of cakephp now, but didn't get flagged previously on LP: #1749745.  Remove also?
<ubot5`> Launchpad bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New] https://launchpad.net/bugs/1749745
<nacc> slangasek: oh sorry, i meant to add it, yes, i'll add a task
<nacc> slangasek: oh wait, yes, but it's from src:cakephp
<slangasek> nacc: oh oops I typed the wrong command - ack
<tsimonq2> slangasek: Since Bileto seems to bypass the usual queue checks, I think it's a good idea to ask for a review; could you please do a prelim review of https://bileto.ubuntu.com/#/ticket/3113 to make sure it looks good?
<tsimonq2> (with your AA hat on)
<nacc> slangasek: thanks for the removals, i believe c-m also has a list of binaries that can move to universe now (it should be everything in php7.1, but i think it won't until the NBS php-mcrypt is removed. Do you want me to add tasks for that in that bug?
<slangasek> nacc: absolutely not, c-m is its own todo list :)
<nacc> slangasek: ok :)
<slangasek> nacc: and fwiw I haven't removed gosa yet, I need to still decide what makes sense with its revdeps... zoneminder had a sourceful RC bug in its own right, but the gosa plugins might be releasable again if someone fixes gosa - so those might be demote-to-proposed in the near term
<nacc> slangasek: ack, that's fine with me
<nacc> slangasek: keeping in mind gosa-plugins-* is from src:gosa
<nacc> slangasek: so i guess you mean just demote the whole source package?
<slangasek> nacc: gosa-plugin-mailaddress is its own src package; etc
<slangasek> nacc: these'ns: https://bugs.launchpad.net/ubuntu/+source/gosa/+bug/1749745/comments/9
<ubot5`> Ubuntu bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New]
<nacc> slangasek: ah ok, sorry, i had checked several of that list and they wer in src:gosa, so i must have missed some
<nacc> (e.g., gosa-plugin-webdav is from src:gosa)
<slangasek> oh
<slangasek> well hang on then, do we have some source packages that need nuked?
-queuebot:#ubuntu-release- Unapproved: nplan (artful-proposed/main) [0.32~17.10.1 => 0.32~17.10.2] (core)
<slangasek> nacc: yeah, definitely some weirdness in the reverse-depends output here, some of these binaries are definitely from src:gosa and always have been so shouldn't show up in the output against src:gosa
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (bionic-proposed/multiverse) [9.1.85-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (bionic-proposed/multiverse) [9.1.85-1] (no packageset)
<slangasek> sergiusens: the snapcraft autopkgtest failed in the release pocket of course, but the maven test case that failed in the -proposed version *passed* in the release version
<slangasek> sergiusens: how do you want to play this?  I can justify letting this package into the release pocket with a skiptest hint on the grounds that so much else has changed around it that the version currently in release pocket is unreleasable anyway - but I'll only do that if you agree that regressing the maven plugin (as the test regression implies) is ok
<sergiusens> slangasek: I played with the test locally and it all works, the only environmental differences we have are that autopkgtests use a proxy. I'll keep looking into it.
<slangasek> sergiusens: I'm glad you'll keep looking into it - in the meantime, do you think this package should be allowed through the gauntlet?
<sergiusens> slangasek: personally, yes; this is the one where we add all that elf work to make things actually do things after built
<slangasek> e.g. if the test passes locally, do you think it's a bad test, and maybe it's not a regression for users?
<sergiusens> slangasek: whatever is in bionic now produces things that do not work
<slangasek> heh
<slangasek> sergiusens: fyi that's a trump card you can always play to get me to skip autopkgtests
<sergiusens> I am not faking anthing here fwiw ;-)
<slangasek> sergiusens: when you test it locally, are you using bionic-proposed as a source?  Do the snapcraft tests inherit the apt pinning autopkgtest does for -proposed, or does it try to pull all packages from -proposed?
<sergiusens> slangasek: I do not have -proposed enabled at all; so no to everything; it was a light test in between the things I was doing. I don't mind waiting a week for this to get in (it has already been 3 months ;-) )
<nacc> slangasek: yeah, it feels like something chnaged, but i don't know what
<slangasek> sergiusens: I do mind it waiting another week if that results in further decay (especially as e.g. we're waiting on a working snapcraft for subiquity).  But if you're testing without -proposed, and the autopkgtest is testing with full -proposed, and it fails in -proposed, there's a chance something is about to regress in release that impacts snapcraft
<slangasek> tsimonq2: sorry, effectively the answer is no, I can't do a prelim review
<tsimonq2> slangasek: No problem
<tsimonq2> Thanks
-queuebot:#ubuntu-release- New: accepted curl [amd64] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl [armhf] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl [ppc64el] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl [arm64] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl [s390x] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl [i386] (bionic-proposed) [7.58.0-2ubuntu2]
<tgm4883> Could someone take a look as to why mythtv isn't being promoted out of bionic-proposed? http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#mythtv
<infinity> tgm4883: Because upgrading libvpx causes a bazillion things to become uninstallable.
<infinity> (ie: you're in the middle of a transition)
<tgm4883> ah, so it should clear itself up then eventually?
<infinity> Seems plausible.  Not sure who, if anyone, is actively working on that particular transition right now.
<tgm4883> ok
<tgm4883> I just got the email that it's been in proposed for 5+ days so was worried
<acheronuk> tjaalton: kde tests on mesa should be passed now, or about to
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.3 => 0.32~16.04.4] (no packageset)
-queuebot:#ubuntu-release- New: rejected latte-dock [source] (bionic-proposed) [0.7.3-0ubuntu1]
<slangasek> xnox: I am confused by your followups on LP: #1748000, Timo filed a bug requesting the package's removal and you assigned it to the kernel team
<ubot5`> Launchpad bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Critical,Triaged] https://launchpad.net/bugs/1748000
<xnox> slangasek, there is a ftbfs in the wild, but it's best to remove the package.
<xnox> slangasek, i was not sure what was going to happe quicker
<xnox> slangasek, please remove it.
#ubuntu-release 2018-02-27
<tsimonq2> slangasek: FTR: src:qtwebengine-opensource-src is building in Bileto ticket 3113 now; if/when the build passes, it should be ready to publish.
<tsimonq2> I unfortunately don't have the rights to do that quite yet though, so unless you'd like to press the button for me, I'll be waiting on either Dmitry or Gi'anfranco.
<tsimonq2> *Gianfranco
<slangasek> tsimonq2: did the discussion yesterday about abis being bumped or not yield a different answer wrt entangling with curl?
<tsimonq2> slangasek: Oh, good point, let me double-check that now that you mention it...
<tsimonq2> $ grep-dctrl \( -FDepends qtdeclarative-abi-5-9-3 -o -FDepends qtbase-abi-5-9-3 \) -a -FDepends libcurl3 /chroots/bionic/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_*amd64_Packages
<tsimonq2> That returns nothing.
<tsimonq2> er
<tsimonq2> $ grep-dctrl \( -FDepends qtdeclarative-abi-5-9-2 -o -FDepends qtbase-abi-5-9-2 \) -a -FDepends libcurl3 /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_bionic_*amd64_Packages
<tsimonq2> THAT command returns nothing (well, they both do, but the last one is more accurate ;) )
<tsimonq2> slangasek: So we're good.
<slangasek> ok
<tsimonq2> slangasek: ukui-power-manager is in Bionic source NEW
-queuebot:#ubuntu-release- New source: ukui-power-manager (bionic-proposed/primary) [1.1.1-0ubuntu1]
<tjaalton> acheronuk: yes, thanks.. and now it's clutter left
<tsimonq2> tjaalton: I'm thinking Qt will land in -proposed within the next 12 hours or so, and at that point I'll take the block-proposed tag off of that mesa bug.
<tjaalton> tsimonq2: ok, good
-queuebot:#ubuntu-release- New binary: lxc [amd64] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [s390x] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [i386] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [ppc64el] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [arm64] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [armhf] (bionic-proposed/main) [2.1.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New source: pyxs (bionic-proposed/primary) [0.4.1+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pocket-lint [amd64] (bionic-proposed) [0.5.31-0ubuntu2]
<dgadomski> RAOF: hi, could you please release fixes for LP: #1644662 to -updates?
<ubot5`> Launchpad bug 1644662 in gnome-themes-standard (Ubuntu Artful) "Icons missing when appearance setting is "high contrast"" [High,Fix committed] https://launchpad.net/bugs/1644662
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.19 => 1.3.1-1ubuntu10.20] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (artful-proposed/main) [3.6.0-1ubuntu6.3 => 3.6.0-1ubuntu6.4] (ubuntu-server, virt)
<tsimonq2> Qt 5.9.4 transition incoming
<tseliot> tjaalton: why is the new X11 still in -proposed? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1752053
<ubot5`> Ubuntu bug 1752053 in nvidia-graphics-drivers-390 (Ubuntu) "nvidia-390 fails to boot graphical display" [Undecided,Confirmed]
<tjaalton> tseliot: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gdbm
<tjaalton> why did -390 migrate without libglvnd?
<tjaalton> or didn't it depend on the new xserver?
<coreycb> hi all, can someone from the release team take a look at percona-xtradb-cluster-5.7 in the bionic NEW queue? we're moving OpenStack to 5.7 in bionic.
<tseliot> tjaalton: I think the packages pull in libglvnd, but I didn't add a dependency on the new X
<tjaalton> ok, that's too bad
<tjaalton> and bionic did have the old libglvnd..
<tseliot> oh
<tseliot> tjaalton: does the new libglvnd break things or what?
<tjaalton> no, the old one was useless
<tseliot> how do we fix this?
<tjaalton> get xserver migrated
<tjaalton> by ignoring the remaining failures
<tseliot> slangasek: ^^
<tjaalton> virtualbox hasn't been updated to build against 4.15, for one
<tjaalton> hmm, nvidia could be demoted back to proposed
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.4] (20101020ubuntu451.22) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.4] (20101020ubuntu451.22) has been added
<tsimonq2> tjaalton: block-proposed removed from mesa, should process on the next Britney run
<tjaalton> tsimonq2: except clutter tests are still failing
<tsimonq2> tjaalton: OK; but at least there's not a block-proposed tag now :)
<tjaalton> right, thanks
<Laney> tjaalton: did you look into the clutter failures?
<tjaalton> Laney: nothing in them
<tjaalton> tried to hint together with libglvnd, didn't help on ppc64el at leaste
<tjaalton> -e
<Laney> what do you mean?
<tjaalton> but ruby-gnome2 got green after hinting xorg-server + mesa + libglvnd
<tjaalton> to pull those from -proposed
<tjaalton> saying that the errors are same as on the gtk+3.0 update
<Laney> yes that one pulled the new mesa too
<tjaalton> ah
<tjaalton> ok then :)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-11.12]
<Laney> just tried locally with all of proposed (--apt-pocket=proposed), still fails :(
<tjaalton> I'll check with upstream
<tjaalton> Laney: can you modify the installation? add this in /etc/drirc: https://pastebin.com/xVndMjWM
<tjaalton> err
<tjaalton> no
<tjaalton> it's only for gnome-shell :)
<tjaalton> hum
<tjaalton> could be that adding a patch or two to xserver would fix these
<tjaalton> if it's related to 30bit support
<tjaalton> as it looks like
<tjaalton> Clutter-Conform:ERROR:texture.c:62:texture_pick_with_alpha: assertion failed: (actor == CLUTTER_ACTOR (tex))
<Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test <- if you do that stuff you should be able to make it fail for you
<tjaalton> the commits are on the stable tree anyway, we'd get them eventually via 1.19.7 but it's not out yet
<tjaalton> thanks, I'll try that
<tsimonq2> How long after I start a transition should Ben pick things up?
<tsimonq2> (I technically started two but) qtbase-abi-5-9-2 -> qtbase-abi-5-9-4 and qtdeclarative-abi-5-9-2 -> qtdeclarative-abi-5-9-4 aren't showing up.
<tjaalton> Laney: this should help https://gitlab.gnome.org/GNOME/mutter/merge_requests/36
<tjaalton> or just skip the tests
<tjaalton> that's what daniels said
 * apw has a look seen when ben last updated
<tjaalton> so there are some arm tests on xserver that most likely failed due to the new mesa
<tsimonq2> apw: It's weird, because the footer says it's been updated but the transition isn't showing up
<tsimonq2> If anything I'm making sure it's not PEBKAC on my part :)
<seb128> tsimonq2, those are new? they are not going to get in the way or current ones that need migrating right?
<tsimonq2> seb128: Right; I cleared it with slangasek yesterday (and the day before at that)
<tsimonq2> seb128: mesa was also waiting on Qt to show up in -proposed because mesa breaks Qt and the uploaded Qt has the patch
<seb128> ah ok
<tsimonq2> (wtbase, to be specific)
<tsimonq2> *qtbase
<seb128> so that transition is a new one that needs to clear off as well now?
<seb128> is it an easy one?
<tsimonq2> It should be fairly easy, it's just a bugfix Qt release
<tsimonq2> I already did direct rdeps and fixed e.g. gammaray
<tsimonq2> ("did" meaning no-change rebuilt)
<seb128> k, good then
<seb128> we really need those transitions to clear, we have other ones waiting to be upload and ff coming
<apw> tsimonq2, i am not sure i can see any new trackers in the config ?
<seb128> or the other option is to stack the ones which are waiting but that would makes it difficult to sort out then
<tsimonq2> flocculant: Poke, what was that one problematic Xfce package that needed a no-change rebuild for the last Qt transition?
<tsimonq2> seb128: Right; the *last* think I think we all want is what we had at the beginning of the cycle except last minute :)
<tsimonq2> apw: Hm... maybe it won't show up then
<apw> tsimonq2, where did you add them ?
<tsimonq2> apw: I'm not sure what you mean; I didn't add things anywhere manually, I just started the transition
<apw> not sure we have any autotrackers
<tsimonq2> OK, so how do I add it?
<tsimonq2> (I'd like to learn how for this time and the following times)
<apw> you'd need to make up the .ben and add it to the transition-tracker-config if you have access
<tsimonq2> How do I know if I have access? :)
 * tsimonq2 is just in ~motu
 * apw pasts long urls into PM for tsimonq2
<tsimonq2> Ah yes, so I do have commit access here.
<tsimonq2> As acheronuk says, qool.
<tsimonq2> :P
-queuebot:#ubuntu-release- Unapproved: cockpit (artful-backports/universe) [161-1~ubuntu17.10.1 => 162-1~ubuntu17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [161-1~ubuntu16.04.1 => 162-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (artful-backports) [162-1~ubuntu17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [162-1~ubuntu16.04.1]
<tsimonq2> Can a Core Developer please no-change rebuild qtubuntu for qtbase-abi-5-9-4? I don't have upload access.
<tsimonq2> LocutusOfBorg, apw: ^^^^
<tjaalton> awesome/armhf should be hinted as ignored.. seems to be quite failure prone in the past too
<tjaalton> also, clutter & virtualbox should not be blocking xorg-server
<sil2100> tsimonq2: just a no-change direct-upload rebuild into bionic?
<tsimonq2> sil2100: Yes.
<sil2100> tsimonq2: done o/
<tsimonq2> sil2100: Thank you!
<sil2100> yw!
<tjaalton> tseliot, slangasek: xorg-server would migrate if awesome/armhf would not time out(?), clutter has known issues with new mesa, and virtualbox dkms doesn't build with 4.15
<tjaalton> as a recap
<tjaalton> and with that, I'm afk
<tseliot> "clutter has known issues with new mesa" sigh...
<tjaalton> well not clutter, but cogl and mutter
<tjaalton> it won't affect xserver
<tseliot> ok
<tjaalton> just that the blocking autopkgtest pulled new mesa
<tjaalton> and fails
<tseliot> what about libglvnd?
<tseliot> would that work with the current mesa?
<tjaalton> I hinted some tests to pull mesa & libglvnd too, and they passed
<tjaalton> for instance awesome/arm64 passed now, but armhf seems to time out or something
<tjaalton> no
<tseliot> do you have a bug report for mesa/mutter?
<tjaalton> no, Laney might create one?-)
<tjaalton> bah, I'll do it
<tjaalton> Laney, tseliot: bug 1752123
<ubot5`> bug 1752123 in mutter (Ubuntu) "Force 8bit RGB config" [Undecided,New] https://launchpad.net/bugs/1752123
<tseliot> thanks
<Laney> tjaalton: thx
<Laney> I found https://src.fedoraproject.org/rpms/cogl/blob/master/f/0001-egl-Use-eglGetPlatformDisplay-not-eglGetDisplay.patch too, is it related?
<tjaalton> Laney: it might be
<Laney> well I did try the patch, but we're not that lucky :-)
<tjaalton> sounds like it's useful with libglvnd in any case
<tseliot> so, it's picking the wrong EGL config. I haven't seen the cogl code, but it should be easy to fix
<LocutusOfBorg> tsimonq2, .
<tsimonq2> LocutusOfBorg: \o/
<LocutusOfBorg> me and sil2100 raced at the same time
<LocutusOfBorg> he win
<tsimonq2> :D
<tjaalton> tseliot: mutter merged cogl, the mutter patch should fit back to cogl without too much trouble
<tseliot> tjaalton: yes, and cogl seems to use GBM_FORMAT_XRGB8888 in _cogl_winsys_egl_context_created(), so things should just work
<tseliot> tjaalton: we only need to fix the leak in the patch for mutter then
-queuebot:#ubuntu-release- New source: rax-nova-agent (bionic-proposed/primary) [2.1.12-0ubuntu1]
<tseliot> tjaalton: on a second thought, the leak mentioned in the bug report doesn't seem to be there any more
<tseliot> g_free (egl_configs) is there at the end of the call
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (artful-proposed) [4.3.5-3ubuntu2.1]
<tseliot> Laney: do commits e4e4f9acfc63d0e7e097b4276b37ffe7320dc0fd 00b45444df8ed6bf17eaae6532db0bc86b471912 91e04666093ae0cc976159e1aa466cf2e2184138 solve your problem in mutter?
<Laney> tseliot: I don't (atm) have a problem in mutter, just the clutter/cogl one
<Laney> maybe the cogl bits from the mutter copy need to be ported over
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.8]
-queuebot:#ubuntu-release- New: accepted lxc [amd64] (bionic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lxc [armhf] (bionic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lxc [ppc64el] (bionic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lxc [arm64] (bionic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lxc [s390x] (bionic-proposed) [2.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lxc [i386] (bionic-proposed) [2.1.1-0ubuntu2]
<tseliot> Laney: yes, I think so. Cogl should already do the right thing, picking GBM_FORMAT_XRGB8888
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.11]
<Laney> tseliot: alright, well you should be able to reproduce the failure and test any ports ;-)
<tseliot> Laney: how do I reproduce the problem? Use intel + the new mesa + X11 in Bionic?
<Laney> tseliot: you can use xvfb even
<Laney> something like autopkgtest --apt-upgrade --apt-pocket=proposed=src:mesa clutter-1.0 ~/temp/*1.22.2-3ubuntu1*.deb --shell-fail -- qemu autopkgtest-bionic-amd64.img
<Laney> umm without the ~/temp/bit
<tseliot> Laney: I'm not familiar with autopkgtest. Where can I find the documentation, please?
<Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<tseliot> thanks
<Laney> but maybe also installing clutter-1.0-tests and running those with xvfb-run gnome-desktop-testing-runner would work -- I didn't check that though
<Laney> with the -proposed mesa ofc
<tseliot> ok, let's see what I can do
<flocculant> tsimonq2: not sure - don't generally know about packaging
<tsimonq2> flocculant: ack
<flocculant> sorry :) might possibly have been not xfce - might well have been something local to me
<flocculant> s/xfce/Xubuntu
<tsimonq2> OK, well let me know :)
<flocculant> tsimonq2: I use a couple of apps that qt - cantata and clementine - though I build from git
<flocculant> anyway - if something blows up in Xubuntu I will be sure to let you know
<tsimonq2> Sure/
<LocutusOfBorg> does anybody have clues about abi-compliance-checker regressed in release?
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/abi-compliance-checker/bionic/arm64
<LocutusOfBorg> I blame maybe gcc/binutils, seems reproducible with the old glibc
<LocutusOfBorg> infinity, ^^
<LocutusOfBorg> (blocking perl migration)
<slangasek> tsimonq2: ok, I see qtbase-opensource-src in and lots of failing autopkgtests.  What needs to happen to get passing results there?
<tsimonq2> slangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/a/akonadi/20180227_135433_a2e38@/log.gz is interesting
<tsimonq2> slangasek: Otherwise I haven't looked deeply yet; I've mostly been dealing with no-change rebuilding rdeps this far
<tsimonq2> slangasek: Aaaand I think that's why there's a bunch of failures, uninstallable deps :)
<tsimonq2> slangasek: So I'll hit retry on these once Ben says it's good, and some of the failures should go away.
<tsimonq2> slangasek: But I do have the day off today, so I'll work on getting these done should there be any real failures as soon as I can.
<tsimonq2> s/some of the failures should go away/a lot of the failures should go away/
<tsimonq2> But I have been working on it :)
<slangasek> tsimonq2: they need to be retries that pull multiple sources from -proposed, I'm sure, so it's not just hitting the retry button; are you triggering with --all-proposed, or with a trigger list?
<tsimonq2> slangasek: I have yet to get that far
<tsimonq2> slangasek: But probably with --all-proposed
<tsimonq2> slangasek: So qtdeclarative tests are retried, but I just realized I can't retry *any* of the qtbase tests because I don't have upload access...
<slangasek> tsimonq2: if you give me a retry-autopkgtest-failures pipeline that you think will DTRT, I'll push buttons
<tsimonq2> slangasek: I would even go so far as to do a ./retry-autopkgtest-regressions --all-proposed --blocks qtbase-opensource-src | vipe | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O-
<tsimonq2> slangasek: I'd say after looking at all these failures, the vast majority are depwait packages that should be fixed now
<slangasek> ok
<slangasek> minus the 'vipe', I hope? :)
<tsimonq2> idk, I copy/pasted from ./retry-autopkgtest-regressions -h
<tsimonq2> XD
<tsimonq2> But yea, I guess so
<acheronuk> I can poke sensible test retries test tomorrow while USA people are sleeping, if that helps
<tsimonq2> Sure
<infinity> LocutusOfBorg: Not the most helpful of logs.  I assume running the test locally and looking at the referenced build-log.txt might be more illuminating.
<LocutusOfBorg> infinity, I can't setup an arm64 pbuilder environment anymore :/
<LocutusOfBorg> I hit this bug https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1725333
<ubot5`> Ubuntu bug 1725333 in glibc (Ubuntu) "do-release-upgrade broke WSL" [Undecided,Confirmed]
<infinity> LocutusOfBorg: Oh, didn't notice it's only regressed on arm64.  Fun.
<LocutusOfBorg> :/
<LocutusOfBorg> this is why I pinged you :)
<slangasek> tjaalton: badtesting awesome/armhf; haven't looked at the others yet; do you know why nvidia-graphics-drivers-340 is unhappy with the new libglvnd? seems libglvnd is rather critical, nvidia is currently broken in bionic because it needs the new libglvnd
<tjaalton> slangasek: new 340 isn't uploaded yet because xorg-server hasn't migrated
<tjaalton> though it could/should depend on the new version
<tjaalton> like 390 should've
<slangasek> tjaalton: I don't follow.  why should xorg-server migrate before the new 340 is uploaded?
<tjaalton> should migrate together, because 340/390 use the new more automated configuration
<slangasek> well they can't migrate together if nvidia-graphics-drivers-340 hasn't been uploaded
<tjaalton> true
<tjaalton> tseliot will upload it and add the dep
<tseliot> yes
<slangasek> tseliot: ^^ any eta on nvidia-graphics-drivers-340 then?  since it's in the critical path for un-breaking -390 in bionic release
<tseliot> a few minutes, I think
<tseliot> slangasek: I need to add the dependency on the new X
<slangasek> ok
<elopio> hello. Can we please get snapcraft 2.39.2 into xenial-updates? I've marked the sru as verified: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1745488
<ubot5`> Ubuntu bug 1745488 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.39.2" [Undecided,Confirmed]
<tseliot> slangasek: I've just uploaded 340
<slangasek> tseliot: cheers
<tseliot> :)
<tjaalton> slangasek: btw, the blocker still remains that cogl needs fixing so all clutter tests work with the new mesa..
<slangasek> tjaalton: well, yuck
<elopio> RAOF: ping. Can you help us releasing snapcraft 2.39.2?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-143.192] (core, kernel)
-queuebot:#ubuntu-release- New source: s2tc (bionic-proposed/primary) [1.0+git20151227-2ubuntu1]
<nacc> slangasek: fyi, afaict, php7.1 can now be removed from the archive
<nacc> (src:php7.1, that is)
<xnox> https://bugs.launchpad.net/ubuntu/+source/php7.1/+bug/1752177
<ubot5`> Ubuntu bug 1752177 in php7.1 (Ubuntu) "RM superseeded by php7.2" [High,Triaged]
<nacc> xnox: ah thanks
<nacc> was just going to file the same :)
<RAOF> dgadomski:
<RAOF> dgadomski: You want #1644662 released to xenial-updates? We're in the process of spinning the 16.04.4 release - do you have approval from the release team?
<dannf> looks like linux-firmware didn't make it out of xenial-proposed before the 16.04.4 freeze - which breaks server ISO installs on servers with QED nics - any chance that can get pushed in?
<tsimonq2> slangasek: I'm scratching my head at why a lot of these autopkgtests are still showing failures
<tsimonq2> slangasek: I mean, some of them seem fine...
<tsimonq2> slangasek: It could also be that I jumped the gun in asking you to retry them
<tsimonq2> slangasek: I mean, I can install most of these in an LXD container with -proposed enabled...
 * tsimonq2 wishes I had upload access so I could confirm with just one or two of these that it was indeed depwait and not some hidden, complex dependency mess
<xnox> dannf, you need to highlight e.g. slangasek sil2100 (who is not here?!) cyphermox who can i believe release linux-firmware, and can trigger the respin of the world.
<nacc> tsimonq2: have you tried them locally?
<mwhudson> tsimonq2: being able to install with -proposed enabled is not quite the same as being ok per britney, because you need to be able to install with the packages currently in release not there as well
<tsimonq2> nacc: Yes, in LXD
<tsimonq2> mwhudson: ohh, good point
<mwhudson> tsimonq2: which is extremely confusing
<tsimonq2> nacc: Oh, the autopkgtest... that's also a good point
<tsimonq2> mwhudson: It is
<xnox> tsimonq2, you mention autopkgtests, and proposed migration. do you see install failure in autopkgtests? or when britney considers packages for migration (update output)?
<nacc> tsimonq2: yeah, i meant the dep8 test
<tsimonq2> xnox: In the autopkgtest itselfd
<mwhudson> tsimonq2: which packages are you fighting with?
<tsimonq2> *itself
<tsimonq2> mwhudson: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<tsimonq2> mwhudson: A really good chunk of those are dep problems
<mwhudson> oh that package name doesn't make me think of tentacles at all
 * tsimonq2 pulls a few locally and throws it at autopkgtest-virt-schroot
<mwhudson> tsimonq2: ok yes so the one failure i looked at there is pretty opaque indeed
<tsimonq2> mwhudson: That's why I'm like "OK, retrying these *probably* fixes them..."
<mwhudson> tsimonq2: i clicked retry on this one http://autopkgtest.ubuntu.com/packages/k/kde-cli-tools/bionic/amd64
<tsimonq2> mwhudson: Alright, let's see
<xnox> tsimonq2, the way i see things, is that a lot of your builds still have not been published, despite completing on launchpad 7h ago.
<tsimonq2> xnox: All of the builds for everything I've uploaded today have been published
<tsimonq2> Unless you can prove me wrong there
<tsimonq2> But I did indeed manually vet rdeps to make sure they published
<xnox> tsimonq2, true. i was looking at old cached edition of excuses.
<tsimonq2> Ahh, so indeed there's still some stuff in the queue from ~vorlon
<tsimonq2> I really really wish it would show on update_excuses.html if a test is queued...
<tsimonq2> That would have saved me lots of time here
<nacc> tsimonq2: yeah, there's been some on and off discussion of that
<nacc> tsimonq2: didn't you offer to fix it? :)
<tsimonq2> nacc: I offered to fix the duplicate tests in the queue; similar but not the same :)
<nacc> lol
<tsimonq2> Do we have a bug for that state in update_output.html or should I file one now?
<nacc>  tsimonq2: i'm not sure
<tsimonq2> Aha: https://bugs.launchpad.net/auto-package-testing/+bug/1654761
<ubot5`> Ubuntu bug 1654761 in Auto Package Testing "Use another status for retried but queued items" [Undecided,New]
 * tsimonq2 will do work on this post-feature freeze ;)
<RAOF> robert_ancell: I notice the snapd-glib upload wanting to go into artful-proposed isn't bugfix-only.
<RAOF> robert_ancell: But many of the packages around snapd have standing SRU exceptions; should snapd-glib have one, too?
<robert_ancell> RAOF, it should do but I haven't done the paperwork for it. I've been doing a SRU for each upload under the category of "new upstream microreleases"
<RAOF> Which, I suspect, is why I'm now processing the artful upload from November last year :)
<robert_ancell> RAOF, what version was that one?
<RAOF> robert_ancell: 1.24
<RAOF> Fixing https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1723874 and https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1721762
<ubot5`> Ubuntu bug 1723874 in snapd-glib (Ubuntu Artful) "First installation of a snap reports an error "Connection reset by peer"" [High,Fix committed]
<ubot5`> Ubuntu bug 1721762 in snapd-glib (Ubuntu Artful) "Cancelled installation of snap continues" [High,Fix committed]
<RAOF> And also adding a bunch of features and an API break(!)
<elopio> RAOF: ping. Can you help us releasing snapcraft 2.39.2?
<RAOF> elopio: Sure!
<elopio> thank you :) This is the bug: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1745488
<ubot5`> Ubuntu bug 1745488 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.39.2" [Undecided,Confirmed]
<RAOF> Hm, or maybe?
<RAOF> What's going on with snapcraftâ½
<RAOF> elopio: Why is the version in xenial-proposed greater than the version in artful-proposed?
<RAOF> elopio: Also, 16.04.4 is being prepared.
<RAOF> elopio: Also, have you investigated the autopkgtest failure?
<robert_ancell> RAOF, yeah, the API break is a tricky one. We had to move an enum in the Qt bindings. The good news is probably nothing is using them in that release and it's not an ABI break. It's also fairly trivial to fix an app that would use the enum.
<RAOF> robert_ancell: Anything in the archive which *might* use them?
<robert_ancell> RAOF, the only thing in the archive is plasma-discover and that didn't start using them until bionic. And the change was recommended by the author of that.
<robert_ancell> I got to bypass the issue in xenial because we never shipped the Qt bindings.
#ubuntu-release 2018-02-28
-queuebot:#ubuntu-release- Unapproved: accepted pymacaroons [source] (artful-proposed) [0.12.0-1~ubuntu17.10.1]
<nacc_> slangasek: please reject s2tc from the new queue (LP: #1752198)
<ubot5`> Launchpad bug 1752198 in steam (Ubuntu) "Steam is not installable on Ubuntu 18.04" [Critical,Fix committed] https://launchpad.net/bugs/1752198
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-143.192]
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (artful-proposed) [0.32~17.10.2]
<slangasek> nacc_: oh, this was about a steam package that's in the Ubuntu archive even? hrm, reverse-depends didn't show this at all when I did the removal
-queuebot:#ubuntu-release- New: rejected s2tc [source] (bionic-proposed) [1.0+git20151227-2ubuntu1]
<nacc_> slangasek: yeah :(
<nacc_> slangasek: perhaps because it's a provides, etc?
<nacc_> i'm not sure, really
<tgm4883> I don't mean to be a pest, but this has been sitting in -proposed for over a week and feature freeze is tomorrow. Is there anything I need to be doing about this? http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#mythtv
<mwhudson> tgm4883: things in -proposed before freeze are ok :)
<tgm4883> mwhudson: ok good news, thanks
<slangasek> tgm4883: well, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linphone says that helping to analyze the autopkgtest failures which block glibc would be useful
<slangasek> the exercise here is "what else depends on the thing which mythtv depends on, and is blocked for some reason"
<jbicha> tgm4883: you need everything on that page that Depends on libvpx to be green (or yellow)
<jbicha> "Valid candidate" is good, "Not considered" is bad
<tsimonq2> slangasek: Did you get a chance to look at ukui* and ukwm in Bionic NEW? If the UKWM stack is going to get in, we're sort of running low on time, heh
<slangasek> tsimonq2: ukwm is just complicated enough that I keep swapping out context and not making any progress on it. :P  Let me see if I can make some headway now
<tsimonq2> slangasek: Sure.
<slangasek> tsimonq2: good news, critical bug in ukwm debian/copyright ;)
<tsimonq2> slangasek: drat
<tsimonq2> Of COURSE there is.
<slangasek> tsimonq2: 'Files: * License: GPL-2+ or LGPL-2+ or MIT~OldStyle+LegalDisclaimer or Expat or SGI-B-2.0' is incorrect, as this syntax claims that the work can be distributed under any of these licenses
<slangasek> it can't, the aggregate license is GPL-2+
<slangasek> s/aggregate/effective/
<tsimonq2> So that should just be GPL-2+?
<slangasek> tsimonq2: I think the terms of the SGI-B-2.0 and Expat licenses also must be reproduced verbatim; best to do that by listing separate Files: stanzas for each license
<tsimonq2> slangasek: s2tc and steam> Someone just told me via PM that apparently the dep chain wasn't followed far enough. libgl1-mesa-dri recommends libtxc-dxtn-s2tc | libtxc-dxtn-s2tc0 | libtxc-dxtn0 and none of those are present in the archive now.
<tsimonq2> slangasek: ukwm> Sure.
<slangasek> tsimonq2: "recommends", not "depends".  Also the next mesa drops this recommends.
<slangasek> the mesa recommends was seen and discussed before removing s2tc
<tsimonq2> slangasek: next mesa drops this recommends> Are you sure about that? I don't think it does.
<tsimonq2> Hm.
<slangasek> tsimonq2: no, I'm not sure about it, I'm just a messenger
<tsimonq2> slangasek: OK ;)
<slangasek> tsimonq2: (and a poor one)
<slangasek> tsimonq2: what was actually said, as of yesterday, is that the Recommends has been dropped in git
<tsimonq2> slangasek: So could that be uploaded please? :)
<tsimonq2> (E: not in ~core-dev)
<slangasek> tsimonq2: by tjaalton perhaps.  But also, I believe we want the one currently in -proposed to migrate ASAP
<tsimonq2> slangasek: Sure.
-queuebot:#ubuntu-release- New: rejected ukwm [source] (bionic-proposed) [1.1.6-0ubuntu1]
<tsimonq2> slangasek: I'll work on ukwm (and latte-dock, for that matter), but what about the rest of the ukui* packages?
<tsimonq2> slangasek: latte-dock uploaded
<tsimonq2> Laney: Hi! I'd like to use the minimal install option in Lubuntu, but I noticed that it's sort of dependent on the usage of a desktop.minimal-remove. In Lubuntu, our seeds are sort of split in two, into desktop-qt and desktop-gtk; will this naming scheme still work when adding this to the seed, or will the recently merged tooling for this need to be changed?
<tsimonq2> (So e.g. desktop-qt.minimal-remove and desktop-gtk.minimal-remove.)
<tsimonq2> Also, I think we'll need a new ISO QA test for the minimal option should it be enabled in a particular image.
<tsimonq2> I can take care of that, as soon as Lubuntu can use it. ;)
<tsimonq2> slangasek: No update on qtbase it seems, tests are still running... I'll take a look tomorrow
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- New binary: php7.1 [ppc64el] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: php7.1 [s390x] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> xnox: there are some autopkgtests now failing because of the libcurl3 vs libcurl4 conflicts, so I'm starting the uploads now
-queuebot:#ubuntu-release- New binary: php7.1 [amd64] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> hmm how was no one screaming about cmake being uninstallable in -proposed for the past 24+h?
-queuebot:#ubuntu-release- New binary: php7.1 [arm64] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: php7.1 [armhf] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: php7.1 [i386] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
<acheronuk> tsimonq2> slangasek: latte-dock uploaded
<acheronuk> tsimonq2: ^^^ the queue doesn't agree?
-queuebot:#ubuntu-release- New: accepted ksmtp [source] (bionic-proposed) [17.12.2-0ubuntu1]
<LocutusOfBorg> slangasek, I got a bug report about cmake being uninstallable
<LocutusOfBorg> and I closed it :)
<Laney> tsimonq2: check the code in livecd-rootfs for how it finds that file
<Laney> you probably just want to fix/change live-build/auto/config:670
-queuebot:#ubuntu-release- New binary: kmime [s390x] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [ppc64el] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<tkamppeter> Hi, I want to sync cups-filters 1.20.1-1 from Debian and I get "syncpackage: Error: Debian version 1.20.1-1 has not been picked up by LP yet. Please try again later." now already for 2 days. What is happening and what should I do?
<Laney> don't remove anything that's a dependency though or you'll have quite a bad time
-queuebot:#ubuntu-release- New binary: kmime [i386] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<ginggs> tkamppeter: importer not importing
<ginggs> tkamppeter: c.j.watson is aware of it
<tkamppeter> ginggs, how long will it take to get fixed?
-queuebot:#ubuntu-release- New binary: kmime [armhf] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [amd64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [arm64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<ginggs> tkamppeter: no idea - progress might be reported in #launchpad
-queuebot:#ubuntu-release- New: accepted kmime [amd64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [armhf] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [ppc64el] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [arm64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [s390x] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [i386] (bionic-proposed) [17.12.2-0ubuntu1]
<cjwatson> tkamppeter: we're working on it right now, almost done
<cjwatson> tkamppeter: you won't need to sync it manually - auto-sync will pick it up once it's fixed
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.4] has been marked as ready
<jamespage> ok so I think i got this right - https://code.launchpad.net/~james-page/britney/openvswitch-2.9.0-0ubuntu1/+merge/340081
<jamespage> if a release team member could review +1 thanks!
 * apw has a look
<xnox> slangasek, i was hoping to catch curl4 & ruby2.5-as-default in the archive rebuild, instead of manual builds.
<xnox> slangasek, but i guess you want to autopkgtest the hell out of bionic
<tkamppeter> cjwatson, it is working now. Thanks. cups-filters is synced now.
<cjwatson> tkamppeter: oh, you couldn't wait for auto-sync?  OK.
<cjwatson> the importer looks sufficiently finished now, so running auto-sync (it'd run in an hour anyway, but we'll want to allow as much catch-up time as possible)
<jamespage> apw: ta
-queuebot:#ubuntu-release- New binary: kcalcore [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalcore [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalcore [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalcore [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<cjwatson> auto-sync done
-queuebot:#ubuntu-release- New binary: ksmtp [s390x] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcalcore [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [s390x] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kcalcore [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: qpdf [s390x] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [ppc64el] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [amd64] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ksmtp [amd64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ksmtp [ppc64el] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ksmtp [i386] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qpdf [arm64] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ksmtp [arm64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [s390x] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: ksmtp [armhf] (bionic-proposed/universe) [17.12.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lcgdm [s390x] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qpdf [i386] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [armhf] (bionic-proposed/main) [8.0.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: kronosnet [amd64] (bionic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [ppc64el] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [ppc64el] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [amd64] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-google-auth [amd64] (bionic-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [i386] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lcgdm [ppc64el] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [amd64] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lcgdm [amd64] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lcgdm [i386] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pluggy [amd64] (bionic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [s390x] (bionic-proposed/universe) [0.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [i386] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: core-specs-alpha-clojure [amd64] (bionic-proposed/universe) [0.1.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-dcso-fluxline [amd64] (bionic-proposed/universe) [0.0~git20180222.25ae683-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-armon-go-socks5 [amd64] (bionic-proposed/universe) [0.0~git20160902.e753329-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-debos-fakemachine [i386] (bionic-proposed/universe) [0.0~git20180126.e307c2f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-debos-fakemachine [amd64] (bionic-proposed/universe) [0.0~git20180126.e307c2f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [i386] (bionic-proposed/universe) [0.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-safchain-ethtool [amd64] (bionic-proposed/universe) [0.0~git20170622.7ff1ba2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtest-postgresql-perl [amd64] (bionic-proposed/universe) [1.23-2] (no packageset)
-queuebot:#ubuntu-release- New binary: smalr [amd64] (bionic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-valyala-fasthttp [amd64] (bionic-proposed/universe) [20160617-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trac-wikiprint [amd64] (bionic-proposed/universe) [2.0.0+r16816-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cloudflare [amd64] (bionic-proposed/universe) [2.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-ipsec-mb [amd64] (bionic-proposed/universe) [0.48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [amd64] (bionic-proposed/universe) [0.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [ppc64el] (bionic-proposed/universe) [0.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: anosql [amd64] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pipsi [amd64] (bionic-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-crh-tur [amd64] (bionic-proposed/universe) [0.3.0~r83159-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apertium-ukr [amd64] (bionic-proposed/universe) [0.1.0~r82563-1] (no packageset)
-queuebot:#ubuntu-release- New binary: proxmoxer [amd64] (bionic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [armhf] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [armhf] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgwenhywfar [arm64] (bionic-proposed/universe) [4.20.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: eiskaltdcpp [arm64] (bionic-proposed/universe) [2.2.10+186+g1c0173ec-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [s390x] (bionic-proposed/universe) [82-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [amd64] (bionic-proposed/universe) [82-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [i386] (bionic-proposed/universe) [82-2] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [s390x] (bionic-proposed/universe) [3.2r2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lcgdm [arm64] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New sync: fonts-ubuntu (bionic-proposed/primary) [0.83-1]
-queuebot:#ubuntu-release- New binary: lcgdm [armhf] (bionic-proposed/universe) [1.10.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [ppc64el] (bionic-proposed/universe) [82-2] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [i386] (bionic-proposed/universe) [3.2r2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
<jbicha> fonts-ubuntu ^ will need special handling. It should go in main (it's the new name for ubuntu-font-family-sources). And the transitional pkgs should go to oldlibs
-queuebot:#ubuntu-release- New binary: polymake [ppc64el] (bionic-proposed/universe) [3.2r2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted anosql [amd64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted apertium-ukr [amd64] (bionic-proposed) [0.1.0~r82563-1]
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [amd64] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [armhf] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [ppc64el] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New: accepted golang-github-armon-go-socks5 [amd64] (bionic-proposed) [0.0~git20160902.e753329-1]
-queuebot:#ubuntu-release- New binary: php7.1 [s390x] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New source: rax-nova-agent (bionic-proposed/primary) [2.1.12-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted apertium-crh-tur [amd64] (bionic-proposed) [0.3.0~r83159-1]
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [arm64] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [s390x] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New source: pyxs (bionic-proposed/primary) [0.4.1+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted core-specs-alpha-clojure [amd64] (bionic-proposed) [0.1.24-1]
-queuebot:#ubuntu-release- New binary: php7.1 [ppc64el] (bionic-proposed/main) [7.1.13-1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted eiskaltdcpp [i386] (bionic-proposed) [2.2.10+186+g1c0173ec-2]
-queuebot:#ubuntu-release- New: accepted golang-github-dcso-fluxline [amd64] (bionic-proposed) [0.0~git20180222.25ae683-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-debos-fakemachine [i386] (bionic-proposed) [0.0~git20180126.e307c2f-1]
-queuebot:#ubuntu-release- New: accepted golang-github-valyala-fasthttp [amd64] (bionic-proposed) [20160617-1]
-queuebot:#ubuntu-release- New: accepted kronosnet [amd64] (bionic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted lcgdm [arm64] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New: accepted lcgdm [i386] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New: accepted lcgdm [s390x] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [arm64] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [i386] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [s390x] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-go-debos-fakemachine [amd64] (bionic-proposed) [0.0~git20180126.e307c2f-1]
-queuebot:#ubuntu-release- New: accepted intel-ipsec-mb [amd64] (bionic-proposed) [0.48-1]
-queuebot:#ubuntu-release- New: accepted lcgdm [armhf] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [amd64] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [ppc64el] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New source: ippsample (bionic-proposed/primary) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New source: ukui-settings-daemon (bionic-proposed/primary) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-safchain-ethtool [amd64] (bionic-proposed) [0.0~git20170622.7ff1ba2-1]
-queuebot:#ubuntu-release- New: accepted lcgdm [ppc64el] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New source: dptfxtract (bionic-proposed/primary) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lcgdm [amd64] (bionic-proposed) [1.10.0-2]
-queuebot:#ubuntu-release- New source: ukui-media (bionic-proposed/primary) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgwenhywfar [armhf] (bionic-proposed) [4.20.0-1]
-queuebot:#ubuntu-release- New: accepted libtest-postgresql-perl [amd64] (bionic-proposed) [1.23-2]
-queuebot:#ubuntu-release- New: accepted proxmoxer [amd64] (bionic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted python-google-auth [amd64] (bionic-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted pipsi [amd64] (bionic-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted python-pluggy [amd64] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted python-cloudflare [amd64] (bionic-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted qpdf [amd64] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted qpdf [armhf] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted qpdf [ppc64el] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted qpdf [arm64] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted qpdf [s390x] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted qpdf [i386] (bionic-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted smalr [amd64] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted trac-wikiprint [amd64] (bionic-proposed) [2.0.0+r16816-1]
-queuebot:#ubuntu-release- New: accepted php7.1 [amd64] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New: accepted php7.1 [armhf] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New: accepted php7.1 [ppc64el] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New binary: libmstoolkit [s390x] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted php7.1 [arm64] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New: accepted php7.1 [s390x] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New: accepted php7.1 [i386] (bionic-proposed) [7.1.13-1]
-queuebot:#ubuntu-release- New binary: libmstoolkit [i386] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [ppc64el] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [amd64] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-debos-fakemachine [arm64] (bionic-proposed/universe) [0.0~git20180126.e307c2f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [armhf] (bionic-proposed/universe) [0.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: irtt [arm64] (bionic-proposed/universe) [0.9.0-2] (no packageset)
<xnox> nacc_, slangasek - is it an autosync mistake that php7.1 is back in bionic?
-queuebot:#ubuntu-release- New: accepted golang-github-go-debos-fakemachine [arm64] (bionic-proposed) [0.0~git20180126.e307c2f-1]
-queuebot:#ubuntu-release- New: accepted irtt [arm64] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New: accepted irtt [i386] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New: accepted irtt [s390x] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New: accepted irtt [amd64] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New: accepted irtt [ppc64el] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New: accepted irtt [armhf] (bionic-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- New binary: polymake [amd64] (bionic-proposed/universe) [3.2r2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
<LocutusOfBorg> can anybody please accept libmstoolkit? it is now built everywhere, and will unblock comet-ms
-queuebot:#ubuntu-release- New binary: libmstoolkit [armhf] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ksmtp [amd64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ksmtp [armhf] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ksmtp [ppc64el] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [amd64] (bionic-proposed) [82-2]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [ppc64el] (bionic-proposed) [82-2]
-queuebot:#ubuntu-release- New binary: libmstoolkit [arm64] (bionic-proposed/universe) [82-2.1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ksmtp [arm64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ksmtp [s390x] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [s390x] (bionic-proposed) [82-2]
-queuebot:#ubuntu-release- New: accepted ksmtp [i386] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [i386] (bionic-proposed) [82-2]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [amd64] (bionic-proposed) [82-2.1~build1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [armhf] (bionic-proposed) [82-2.1~build1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [ppc64el] (bionic-proposed) [82-2.1~build1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [arm64] (bionic-proposed) [82-2.1~build1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [s390x] (bionic-proposed) [82-2.1~build1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [i386] (bionic-proposed) [82-2.1~build1]
<smb> apw, because of my iproute2 upload I was watching its ADT progress. Beside of heartbeat which seems to be a slightly unreliable test, I also see virtualbox (the dkms drivers) showing up as regressions. But those are clearly the "kernel already got the same version" problem. Is there a way that this could be made expected failure on the Britney side?
<apw> smb, we actually already fixed those so this would never happen (in the normal case) where these are in ubuntu, but they have just pulled one of the drivers into the kernel staging
<apw> smb, and actually it does not have the same version, it has no version, so it should not be the same, i am debugging dkms atm
<apw> smb, and i have hinted that version
<smb> apw, ah ok. did not know
-queuebot:#ubuntu-release- New binary: qgis [arm64] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: debos [amd64] (bionic-proposed/universe) [1.0.0+git20180112.6e577d4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: debos [i386] (bionic-proposed/universe) [1.0.0+git20180112.6e577d4-1] (no packageset)
<tsimonq2> Laney, xnox: One of the recent ubiquity uploads regressed, Kubuntu is facing a Ubiquity bug affecting Bionic, bug 1752323...
<ubot5`> bug 1752323 in ubiquity (Ubuntu) "Ubiquity crashes at startup on Kubuntu daily iso - 2018/02/28" [Critical,New] https://launchpad.net/bugs/1752323
<acheronuk> ubiquity 18.04.2 regresses it. if I force downgrade to 18.04.1, it works
<acheronuk> tsimonq2: ^
<acheronuk> so we have the ultimate minimal install right now. zero - nothing!
<tsimonq2> Laney: So then it's somewhat related to the changes made when adding the minimal mode.
<coreycb> hi, can someone from the release team help get percona-xtradb-cluster-5.7 accepted from the NEW queue? we're moving to 5.7 for OpenStack in Bionic.
-queuebot:#ubuntu-release- New binary: qgis [armhf] (bionic-proposed/universe) [2.18.17+dfsg-1] (no packageset)
<coreycb> or perhaps an archive admin :) ^
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.22 => 20101020ubuntu451.23] (core)
<xnox> sil2100, haha, i also uploaded d-i
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.22 => 20101020ubuntu451.23] (core)
<xnox> as well.
<xnox> accepting either is fine; i did push mine in bzr.
<xnox> but that can be fixed if you accept your own.
<Laney> tsimonq2: Can you debug please?
-queuebot:#ubuntu-release- Unapproved: rejected debian-installer [source] (xenial-proposed) [20101020ubuntu451.23]
<tsimonq2> Laney: acheronuk got somewhere, share your notes?
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.23]
<acheronuk> I got nowhere really.
<tsimonq2> Alright then, I can debug
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.20]
<Laney> merci
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (artful-proposed) [3.6.0-1ubuntu6.4]
-queuebot:#ubuntu-release- New binary: polymake [armhf] (bionic-proposed/universe) [3.2r2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.23]
<Laney> tsimonq2: do you have a /var/log/installer/debug file?
<tsimonq2> Laney: No, but I can grab an ISO and get you one if you'd like
 * tsimonq2 didn't report the bug
<Laney> ok, I thought you would be there since you said you were debugging
<tsimonq2> I'm getting to it, people keep throwing things at me ;)
<acheronuk> Laney: https://paste.ubuntu.com/p/sBQVpsK3ff/
<acheronuk> hope that is what you meant
<Laney> yeah
<Laney> Could not create prepare page: 'QWidget' object has no attribute 'minimal_install_vbox'
<Laney> I know what's happening I think :-)
<acheronuk> Laney: have you built that branch anywhere? I can just try allying the changes in situ if not
<acheronuk> *applying
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.4] has been updated (20101020ubuntu451.23)
<tsimonq2> Laney: Would it collide with Feature Freeze if I decided to wait on that livecd-rootfs fix until this weekend (pre Beta 1 ISOs)?
<tsimonq2> (Meaning, would it need an FFE?)
<Laney> tsimonq2: I wouldn't worry about it if it only affects your flavour
<Laney> acheronuk: if you trust some random guy's debs you can have mine
<tsimonq2> Laney: OK.
<Laney> (soon)
<acheronuk> random. right
-queuebot:#ubuntu-release- New binary: debos [arm64] (bionic-proposed/universe) [1.0.0+git20180112.6e577d4-1] (no packageset)
<Laney> don't look at the postinst O:)
<nacc_> xnox: i assume so? it probably needs adding to the blacklist
<Laney> acheronuk: https://people.canonical.com/~laney/lp1752323/
<Laney> let's move to #ubuntu-installer for this please
<elopio> sorry for the late reply RAOF. Sergio has commented about artful on the bug: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1745488/comments/9
<ubot5`> Ubuntu bug 1745488 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.39.2" [Undecided,Confirmed]
<slangasek> xnox: no, we want to get the transitions out of the way /before/ the archive rebuild when migratability resets
<slangasek> xnox: php7.1 back in bionic - I did not blacklist this package for syncing, that wasn't part of the request in the bug
<nacc> slangasek: my fault
<slangasek> nacc: but I should remove it again, right?
<nacc> slangasek: yes please
-queuebot:#ubuntu-release- New source: falkon (bionic-proposed/primary) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted falkon [source] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio-gdrive [source] (bionic-proposed) [1.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalcore [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: falkon [amd64] (bionic-proposed/none) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: falkon [i386] (bionic-proposed/none) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kio-gdrive [amd64] (bionic-proposed/none) [1.2.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kio-gdrive [i386] (bionic-proposed/none) [1.2.1-0ubuntu1] (no packageset)
<tsimonq2> yay @ Riddell doing some AA reviews for Kubuntu :)
-queuebot:#ubuntu-release- New binary: kio-gdrive [arm64] (bionic-proposed/universe) [1.2.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: latte-dock (bionic-proposed/primary) [0.7.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kio-gdrive [armhf] (bionic-proposed/universe) [1.2.1-0ubuntu1] (no packageset)
<sil2100> flexiondotorg: poke poke, looking for ubuntu-mate testers o/
<sil2100> flexiondotorg: could you poke around to get the .4 images tested?
<tsimonq2> Oh, speaking of that, let's see how far along Lubuntu is...
<sil2100> Lubuntu's doing pretty good I guess
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
<tsimonq2> The rest of the Lubuntu testing should be pretty easy
-queuebot:#ubuntu-release- New binary: falkon [arm64] (bionic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: falkon [armhf] (bionic-proposed/universe) [3.0.0-0ubuntu1] (no packageset)
<elopio> arges: rbasak: can you help us with the release of snapcraft 2.39.2? https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1745488
<ubot5`> Ubuntu bug 1745488 in snapcraft (Ubuntu Artful) "[SRU] New stable micro release 2.39.2" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New: accepted kio-gdrive [amd64] (bionic-proposed) [1.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio-gdrive [armhf] (bionic-proposed) [1.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio-gdrive [arm64] (bionic-proposed) [1.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kio-gdrive [i386] (bionic-proposed) [1.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected falkon [amd64] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected falkon [armhf] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected falkon [arm64] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected falkon [i386] (bionic-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: polymake [arm64] (bionic-proposed/universe) [3.2r2-2] (no packageset)
<sil2100>  flexiondotorg: ok, nvm the testing request, I'll be re-spinnning the images anyway
-queuebot:#ubuntu-release- New binary: leatherman [s390x] (bionic-proposed/none) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: falkon [amd64] (bionic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [ppc64el] (bionic-proposed/none) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-funcsigs [amd64] (bionic-proposed/main) [1.0.2-4] (ubuntu-server)
<blackboxsw> RAOF  you processing the cloud-init pending-sru for xenial/artful. rmadison says artful updates has the latest 17.2.35 but xenial-updates not quite yet. Though the bug says publishing is done
<blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1747059
<ubot5`> Ubuntu bug 1747059 in cloud-init (Ubuntu Xenial) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2-35-gf576b2a2-0ubuntu1~16.04.1" [Medium,Fix committed]
-queuebot:#ubuntu-release- New: accepted fonts-ubuntu [sync] (bionic-proposed) [0.83-1]
-queuebot:#ubuntu-release- New binary: leatherman [i386] (bionic-proposed/universe) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-ubuntu [amd64] (bionic-proposed/none) [0.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puredata [amd64] (bionic-proposed/universe) [0.48.1-3] (ubuntustudio)
<blackboxsw> it's definitely not an ideal time to talk to RAOF, rbasak  if you have a chance today can you peek at cloud-init xenial SRU status? artful looks in
-queuebot:#ubuntu-release- New binary: falkon [i386] (bionic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [amd64] (bionic-proposed/universe) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: falkon [arm64] (bionic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-monoid [amd64] (bionic-proposed/universe) [0.61-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kalarmcal [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: leatherman [arm64] (bionic-proposed/universe) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kalarmcal [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kalarmcal [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: falkon [armhf] (bionic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [armhf] (bionic-proposed/universe) [1.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kalarmcal [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kalarmcal [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kalarmcal [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kalarmcal [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kalarmcal [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kalarmcal [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kcalutils [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kalarmcal [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kalarmcal [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kalarmcal [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted falkon [amd64] (bionic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted falkon [armhf] (bionic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted falkon [arm64] (bionic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted falkon [i386] (bionic-proposed) [3.0.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kcalutils [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-ubuntu [amd64] (bionic-proposed) [0.83-1]
-queuebot:#ubuntu-release- New binary: kcalutils [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-calendar [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-calendar [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-calendar [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-calendar [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: akonadi-calendar [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<Laney> I just phat phingered something on the autopkgtest lxd machines and it made a bunch of jobs falsely fail
<Laney> sozzles, will try to put them back in the queue
<Laney> done I think, but if you see anything failed with a weird error about a remote not existing that's not requeued then please click the nice big button
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.4] has been updated (20180228)
<tsimonq2> Why the respin?
<tsimonq2> :/
<nacc> tsimonq2: https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004301.html
<sil2100> tsimonq2: ...don't ask
<sil2100> ;)
<flocculant> sil2100: why the respin :D
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.4] has been updated (20180228)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.4] has been updated (20180228)
<jbicha> slangasek: please promote fonts-ubuntu to main, and move the binaries ttf-ubuntu-font-family and fonts-ubuntu-font-family-console to oldlibs
<slangasek> jbicha: uh is this related to the debootstrap failures I *just* saw in autopkgtest logs? http://autopkgtest.ubuntu.com/packages/p/pbuilder/bionic/ppc64el
<slangasek> jbicha: do you know why fonts-ubuntu source is in multiverse?
<jbicha> slangasek: oops, missing Breaks/Replaces indeed. How do you want me to fix this
<jbicha> yes, Debian considers it to be non-free. Ubuntu disagrees
<slangasek> jbicha: hmm, add them? :)
<jbicha> sorry, I was overthinking, uploading in a minuteâ¦
<slangasek> it's a bit strange to have the Ubuntu fonts packages maintained via Debian sync, though.  I wonder if we should blacklist
<slangasek> the package rename to be consistent with font naming policy makes sense
<slangasek> "the Debian project considers" it to be non-free, that's interesting, I wonder where that discussion happened
<slangasek> jbicha: oh, but you're the maintainer, so that's a bit better than some random DD being the "upstream" for our fonts :)
<jbicha> yes
<jbicha> the license issue was a big reason why it took 7 years to finally reach Debian (non-free)
<jbicha> https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/copyright
<jbicha> Debian bug 603157
<ubot5`> Debian bug 603157 in wnpp "ITP: fonts-ubuntu -- sans-serif font set from Ubuntu" [Wishlist,Fixed] http://bugs.debian.org/603157
<tsimonq2> slangasek: There WAS an Ubuntu Developers team in Aliothh...
<tsimonq2> I'm pondering reserving the namespace iin Salsaf it hasn't been allready
<tsimonq2> (grr mobile keyboard)
<jbicha> the Ubuntu Font License was supposed to be a temporary license so maybe it's time to reconsider what license is used, but that's not my job ;)
<slangasek> jbicha: is fonts-ubuntu's Ubuntu*.ttf glob equivalent to ttf-ubuntu-font-family's Ubuntu-[LRMBC]*.ttf + UbuntuMono-*.ttf, or does the new package pull in more fonts?
<slangasek> jbicha: the new source also appears to drop debian/ttf-ubuntu-font-family.maintscript which seems to still be relevant on upgrades to bionic
<jbicha> the package should not be including any additional fonts
<jbicha> the maintscript should be obsolete since the package hasn't been modified since xenial
<slangasek> jbicha: ah, sure enough - I had failed to check that
<sergiusens> slangasek: while you are here, is there any chance we can get snapcraft into xenial-updates today?
<slangasek> sergiusens: is the SRU vanguard unavailable?
<slangasek> I'm in the middle of these overrides for jbicha
<sergiusens> slangasek: no worries, sorry for not checking (I usually check) while it is outside sil2100's timezone, I guess bdmurray could look into it
<tsimonq2> slangasek: There, added the vorlon user to ubuntu-dev-teeam, we can mifgrate things over frlom Alioth eventtually I guess
<tsimonq2> (this HAS to be connectbot... wtf)
<tsimonq2> slangasek: It also might be for the sake of reserving the namespace
<tsimonq2> Â¯\_(ã)_/Â¯
<sil2100> What's up?
<sil2100> I'm available, but doing testing generally
<sil2100> sergiusens: since snapcraft is universe and not seeded, I can publish it in a bit, sure
<sergiusens> sil2100: thanks! I wasn't aware you were still around
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
<mwhudson> hi can docker-libkv/0.2.1-1 be hinted as a bad test? it's broked in release too
<mwhudson> oh wait what i just did didn't prove that
<mwhudson> (but i'm pretty sure it's broken anyway)
<manjo> sil2100, the download information link from http://iso.qa.ubuntu.com/qatracker/milestones/386/builds/167237/testcases is broken
<manjo> sil2100, hereis the broken link http://iso.qa.ubuntu.com/qatracker/milestones/386/builds/167237/downloads
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (artful-proposed/main) [0.2.36 => 0.2.36ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (xenial-proposed/main) [0.2.31 => 0.2.31ubuntu1] (core)
<sil2100> manjo: is is a regression? Or was it always broken? I'll fix that, thanks!
<manjo> sil2100, not sure .. I just noticed it .. thanks for fixing
<manjo> sil2100, last time I noticed ARM64 had similar broken links
<sil2100> Yeah, arm64 I fixed
<manjo> yes is fixed for arm64 now
<slangasek> fonts-ubuntu 0.83-1ubuntu1 now publishing to release
<tjaalton> slangasek: fyi, latest mesa should unbreak clutter tests
<tjaalton> once the font mess is sorted :)
<slangasek> \o/
-queuebot:#ubuntu-release- Unapproved: flatpak (artful-proposed/universe) [0.8.7-5 => 0.8.9-0ubuntu0.1] (ubuntugnome)
<slangasek> is ruby-all-dev currently broken?  References to ruby2.3 without depending on it? https://launchpad.net/ubuntu/+source/uwsgi/2.0.15-10.2build1/+build/14404152
<jbicha> slangasek: looks like fonts-ubuntu has migrated
<slangasek> jbicha: yes; I was waiting to confirm I see it in apt output before retriggering tests
<slangasek> archive.u.c is being coy
<jbicha> rmadison and https://autopkgtest.ubuntu.com/packages/adduser/bionic/ppc64el says we're good
<slangasek> ok cool
-queuebot:#ubuntu-release- New sync: granite (bionic-proposed/primary) [0.5+ds-1]
<mwhudson> slangasek: will you be retrying all failures from the last hour or whatever or just the ones showing on excuses?
<slangasek> mwhudson: the retrying is based on excuses, so if you have failures you care about that are *not* listed there, they wouldn't get retried
<mwhudson> slangasek: ok
<slangasek> uwsgi> not a ruby-defaults problem, just needed uwsgi itself to change package names
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-cliff (artful-proposed/main) [2.8.0-0ubuntu1 => 2.8.0-0ubuntu1.1] (ubuntu-desktop, ubuntu-server)
<mwhudson> slangasek: poking at fpc vs glibc while i wait for other things
<slangasek> xnox: xmltooling looks unsolvable, xml-security-c requires openssl-1.0 with no upstream solution (https://lists.alioth.debian.org/pipermail/pkg-shibboleth-devel/2016-October/004315.html), and it also uses curl_easy_setopt(SSL_CTX)
<mwhudson> (i think it might be very silly)
<sil2100> sergiusens: done
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [i386] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [armhf] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
<mwhudson> huh huh no it's not _completely_ silly
<mwhudson> a test that used to segfault now fails to compile
<mwhudson> /usr/bin/ld.bfd: output/x86_64-linux/webtbs/chunk000020000webtbs/tw0876: hidden symbol `__dso_handle' isn't defined
<mwhudson> /usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexit.oS): In function `atexit':
 * mwhudson scratches head
<sil2100> flexiondotorg: hey! Once you're up, the testing request of .4 ubuntu-mate is valid again
-queuebot:#ubuntu-release- New binary: uwsgi [arm64] (bionic-proposed/universe) [2.0.15-10.2ubuntu1] (no packageset)
<flexiondotorg> sil2100: We're on it. Thanks :-)
<sil2100> flexiondotorg: thanks! I'll be picking up the some of the i386 tests to speed things up :)
<sil2100> manjo: fixed the link to ppc64el, thanks for noticing it!
<mwhudson> pfffffffffffffffff two instances of __dso_handle have changed from WEAK to GLOBAL in libc_nonshared
<mwhudson> slangasek: halp
<mwhudson> well i guess this explains that: http://paste.ubuntu.com/p/Dp29kBbT9t/
<mwhudson> lalala https://sourceware.org/git/?p=glibc.git;a=commit;h=825adeeed1e95990fd1efb70d9ac3eb7f1ea802a i guess somehow should tell fpc about this
<mwhudson> *someone
<slangasek> mdeslaur: do you want to sanity-check a change I'm considering for xmltooling to un-break it wrt openssl 1.1 transition?
<mdeslaur> slangasek: sure
<slangasek> mdeslaur: so xmltooling depends on both curl, and xml-security-c; xml-security-c is openssl 1.0 only upstream and not straightforward to port; and it uses the bits of the curl API that are bound to the ABI of the underlying TLS implementation.
<slangasek> mdeslaur: but it only uses SSL_CTX in order to override the protocol negotiation - to disable SSLv2 and TLSv2 by default
<slangasek> mdeslaur: so if I switched it to use the gnutls build of curl, and continue to build with openssl1.0, and dropped the calls to override protocol flags, it would build
<slangasek> mdeslaur: our gnutls is !SSLv2 !SSLv3 by default, right?
<slangasek> mdeslaur: and are you comfortable with the idea of patching out this override?
<mdeslaur> slangasek: I believe so, yes
<mdeslaur> slangasek: yes, it's sounds fine to me
<slangasek> mdeslaur: k thanks, I'll put together a patch and run it past the Debian maintainers as well
<slangasek> mdeslaur: would you like a cc: also?
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [ppc64el] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [s390x] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
#ubuntu-release 2018-03-01
<sil2100> valorie: hey! Do you remember if you saw LP: #1752453 in previous point-release testing?
<ubot5`> Launchpad bug 1752453 in ubiquity (Ubuntu) "on a test of xenial .4 release, selecting "connect to wireless" freezes the process" [Undecided,New] https://launchpad.net/bugs/1752453
<sil2100> valorie: is it reproducible?
<valorie> over and over
<valorie> however, I've given up because I get no logs of the failures
<valorie> on to 64 bit
<valorie> I don't recall ever seeing it before
<valorie> that said, I've not tested point releases much
<valorie> nor do I recall the choice of "connect to wireless" being available
<valorie> once ubiquity freezes, I can't drop to the terminal to get logs
<valorie> overwriting that daily right now, so no more from me
<valorie> :(
-queuebot:#ubuntu-release- New source: lxc-templates (bionic-proposed/primary) [3.0.0~beta1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<valorie> sil2100: you can be sure I will test the 64 for the same bug
-queuebot:#ubuntu-release- New: accepted lxc-templates [source] (bionic-proposed) [3.0.0~beta1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<sil2100> valorie: thanks
<sil2100> valorie: as said, on the VM it all works as intended - at best I'd like someone else with real hardware trying to reproduce the issue
<valorie> which is what I'm using
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.4] has been marked as ready
<sil2100> jbicha: thanks for re-testing!
<mwhudson> slangasek: can you mark docker-libkv/0.2.1-1 as a badtest? http://autopkgtest.ubuntu.com/packages/d/docker-libkv/bionic/amd64 <- broken in release
<jbicha> final scheduled Ubuntu GNOME iso release, right?
<infinity> jbicha: Nope, there's still .5
<jbicha> oh ok, I was looking at http://old-releases.ubuntu.com/releases/trusty/ which is why I got confused
<slangasek> mwhudson: done
<mwhudson> slangasek: thanks
<mwhudson> slangasek: did you see my wibble about fpc above?
<slangasek> mwhudson: reading now
<slangasek> mwhudson: so the test is broken and needs fixing (possibly in the neutering sense)?
<mwhudson> slangasek: well the test with glibc release segfaults, the test with glibc fails to compile, which apparently results in different enough log output to break the autopkgtest
<mwhudson> slangasek: the reason for the failure to compile does suggest that fpc might be slightly incompatible with glibc 2.27
<mwhudson> but no other tests fail to compile because of this so...
 * sil2100 EODs now
<sil2100> o/
<mwhudson> slangasek: i also have to run now ttyl
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.39.2 => 2.39.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.39.3]
-queuebot:#ubuntu-release- New source: python3-lxc (bionic-proposed/primary) [3.0.0~beta1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python3-lxc [source] (bionic-proposed) [3.0.0~beta1-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
 * tsimonq2 crosses fingers for no more respins...
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
<MichaelTunnell> slangasek and/or infinity: I know the feature freeze is coming up. I am curious if this would count as a feature. I want to make a change to Kubuntu for editing default shortcuts for some KWin stuff. What that be blocked by the feature freeze?
<MichaelTunnell> infinity: ^
-queuebot:#ubuntu-release- New binary: polymake [s390x] (bionic-proposed/universe) [3.2r2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [amd64] (bionic-proposed/universe) [3.2r2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [ppc64el] (bionic-proposed/universe) [3.2r2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [i386] (bionic-proposed/universe) [3.2r2-3] (no packageset)
<tjaalton> acheronuk: what's wrong with all the kde autopkgtests failing, again?
<tjaalton> doing a trivial mesa upload always results in hand-helding all these racy/buggy tests
<tjaalton> *holding
<acheronuk> tjaalton: the PIM ones, only half of new PIM stack is built yet. issues should go away mostly when that is done.
<tjaalton> ok then
<tjaalton> they've really taken the unix philosophy to the limit..
<tjaalton> 50+ pkgs, seriously
<tjaalton> acheronuk: shouldn't there be more strict dependencies if the tests fail every time the versions don't match?
<acheronuk> it's usually not such an issue. but there are library version bumps here, so like always with those, things have to build against the new one to remain installable.
<acheronuk> but yeah, PIM really ticks me off sometimes. used to be just several large source packages, then was split, and split again, and split again..... grrr
<acheronuk> tjaalton: http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/17.12.2_bionic_retry_builds.pdf
<acheronuk> ^^^ one giant flying spaghetti monster of build deps
<tjaalton> think I've seen that before ;)
<acheronuk> I've seen it too much!
<tjaalton> ok, so I'll just wait to see it sort itself
<acheronuk> tjaalton: hopefully if AAs are kind today and let the new binaries through as they appear for PIM, then later once all built most tests should re-run ok.
<acheronuk> if any don't, I will try to sort
<tjaalton> new binaries too? ok
<acheronuk> tjaalton: just library bumps
<acheronuk> but they still end up in the new queue
<acheronuk> like libkf5pimcommon in there at the moment
<acheronuk> PIM devs really went to town breaking their ABI on this release :(
-queuebot:#ubuntu-release- New binary: polymake [armhf] (bionic-proposed/universe) [3.2r2-3] (no packageset)
<tjaalton> so it seems
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.4] has been marked as ready
<acheronuk> hi. could we force badtest plasma-framework/5.43.0-0ubuntu1 against mesa for amd64 please?
<acheronuk> that seems to consistently fail on ubuntu's tests, but passes fine here in a lxd autopkgtest run
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- New: accepted leatherman [amd64] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted leatherman [armhf] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted leatherman [ppc64el] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted leatherman [arm64] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted leatherman [s390x] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted leatherman [i386] (bionic-proposed) [1.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted polymake [amd64] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New: accepted polymake [armhf] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New: accepted polymake [ppc64el] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New: accepted polymake [arm64] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New: accepted polymake [s390x] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New: accepted polymake [i386] (bionic-proposed) [3.2r2-2]
-queuebot:#ubuntu-release- New binary: polymake [arm64] (bionic-proposed/universe) [3.2r2-3] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
<Laney> acheronuk: fails for me on my machine (qemu not lxd, that's more like what the autopkgtet machines are running for amd64)
<Laney> 4 retries might have been a bit much
<Laney> and tjaalton has a fair point, it's not very good to have a half broken stack be installable - I think you should try to find something to depend on that prevents things moving forward until everything is consisitent
<Laney> it creates problems for other people trying to do work in the dev release as you can see here :(
<xnox> Laney, weird request -> could you please, re-kick, bionic ubuntu-base, for all arches? I know it was built today, but it was 3 hours too early =)
<xnox> i.e. http://cdimage.ubuntu.com/ubuntu-base/daily/pending/ these things
<acheronuk> it's not installable. that's why tests are failing. if I made it less installable still, they would still fail
<acheronuk> It is a problem we are thinking about. just solutions move the problem somewhere else. :/
<Laney> xnox: okey dokey
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [i386] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kbuild (xenial-proposed/universe) [1:0.1.9998svn2813+dfsg-1 => 1:0.1.9998svn2814+dfsg-2~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.30-dfsg-1 => 5.1.34-dfsg-0ubuntu1.17.10.1~17.10.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (artful-proposed/multiverse) [5.1.30-2 => 5.1.34-0ubuntu1.17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.40-dfsg-0ubuntu1.16.04.2 => 5.1.34-dfsg-0ubuntu1.16.04.1~16.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.40-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.0.40-0ubuntu1.16.04.1 => 5.1.34-0ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.0.40-dfsg-0ubuntu1.16.04.1~16.04.4 => 5.1.34-dfsg-0ubuntu1.16.04.1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (artful-proposed/multiverse) [5.1.30-1 => 5.1.34-0ubuntu1.17.10.1] (no packageset)
<acheronuk> apw or another AA. would someone be kind enough to remove blogilo from bionic?
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/blogilo/+bug/1752544
<ubot5`> Ubuntu bug 1752544 in blogilo (Ubuntu) "Please remove blogilo from Bionic 18.04" [Undecided,New]
<acheronuk> ^^^ that is also a test fail against mesa that I can't fix
<apw> acheronuk, having a look
<acheronuk> ty
<LocutusOfBorg> sil2100, the virtualbox* stack has been uploaded for xenial/artful, it is needed if you want to test the new xenial kernel 4.13...
<LocutusOfBorg> I gave all my time to this, and I finally managed to fix it, so maybe accepting them would be nice
<LocutusOfBorg> kbuild needs a minor update fox xenial, I have uploaded it too
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5calendarsupport [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<sil2100> LocutusOfBorg: hey! I'll look into those in a few minutes, thanks!
<LocutusOfBorg> <3
<LocutusOfBorg> sil2100, I think we will need to close our eyes for vbox 5.0 -> 5.1 jump, and wait for community testing, It is unfortunate, but 5.0 is dead beyond repair (and even completely broken wrt new kernels), 5.2 can't build because of old qt, so 5.1 is the way to go, even if... it changed a lot
-queuebot:#ubuntu-release- New: accepted polymake [amd64] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted polymake [armhf] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted polymake [ppc64el] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted polymake [arm64] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted polymake [s390x] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted polymake [i386] (bionic-proposed) [3.2r2-3]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: uwsgi [armhf] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [arm64] (bionic-proposed/universe) [2.0.15-10.2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bolt [source] (bionic-proposed) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: bolt [s390x] (bionic-proposed/none) [0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bolt [armhf] (bionic-proposed/none) [0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bolt [ppc64el] (bionic-proposed/none) [0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bolt [i386] (bionic-proposed/none) [0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bolt [arm64] (bionic-proposed/none) [0.1-0ubuntu1] (no packageset)
<apw> seb128, bolt failed its tests on amd64
<apw> (and therefore ftbfs there)
-queuebot:#ubuntu-release- New: accepted bolt [arm64] (bionic-proposed) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bolt [i386] (bionic-proposed) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bolt [s390x] (bionic-proposed) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bolt [armhf] (bionic-proposed) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bolt [ppc64el] (bionic-proposed) [0.1-0ubuntu1]
<apw> ^ that is lacking the amd64 bits .... which failed to build
-queuebot:#ubuntu-release- New binary: python-diskimage-builder [amd64] (bionic-proposed/universe) [2.11.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bolt [amd64] (bionic-proposed/universe) [0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [i386] (bionic-proposed) [2.0.15-10.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New: accepted uwsgi [i386] (bionic-proposed) [2.0.15-10.2ubuntu2]
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<seb128> apw, thx
<apw> seb128, though i now see it has built, so i am assuming someone stabbed it in retry
<seb128> apw, seems it worked now?
<apw> so i assume you have a nice racy test, yay for poo tests
<seb128> apw, do you remember what was the failure? I don't have the log now
<apw> it was an assertion failure
<apw> but i didn't record what it was, something which was compared != "" which was ""
<apw> and it was in the first test if that helps
<seb128> k, thanks
<apw> 1/3 test-common
<apw> seb128, ^ yeah it was definatly that test which cried
<seb128> apw, ok, I'm going to do some loop testing here see if I hit it
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<seb128> is anyone looking at unblocking the glibc transition from bionic-proposed?
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<seb128> so, we have some extra desktop transitions to land, unsure what to do
<seb128> it would be annoying to pile them on the currently non sorted out ones
<seb128> but if we wait for those to clear out we miss ff and then we have extra paperwork to do
<seb128> what are the chances that glibc and libglvnd clears out of proposed this afternoon?
<tjaalton> seb128: depends on the kde pim stuff to get sorted first..
<seb128> shrug
<seb128> that's new ?
<tjaalton> yes
<seb128> :-(
<seb128> *uck
<seb128> we should lock down new transitions to be accepted when current ones are being sorted out
<jbicha> seb128: I was theone that retried bolt, log excerpt at https://paste.debian.net/1012554/
<acheronuk> could an AA accept binaries for libkf5mailcommon please
<seb128> jbicha, thx
<tjaalton> acheronuk: here's an idea; put the pim tarballs in one big source package which builds them all? :)
<seb128> "ERROR: ld.so: object 'libumockdev-preload.so.0' from LD_PRELOAD cannot be
<seb128> preloaded (cannot open shared object file): ignored."
<seb128> weird error, doesn't seem to be due to the code tested itself then
<jbicha> tjaalton: you could call it something like â I dunno â kdepim ;)
<acheronuk> lol
<seb128> we should delete that new transition from proposed
<seb128> clear out the ones that were ready to migrate
<seb128> and add it back
<tkamppeter> Can someone sponsor an upload of the brlaser (printer driver) package? It seems not to be in my main upload package list (by the way, how can I see this list?).
<tkamppeter> Needs to be done before FF as it introduces a new upstream versions.
<jbicha> tkamppeter: did you file a LP bug and subscribe ubuntu-sponsors? I recommend doing that first and then ask in #ubuntu-devel
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [i386] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [amd64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [armhf] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [arm64] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [i386] (bionic-proposed) [4:17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [amd64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<apw> seb128, what all are these transitions you would like to start on the day of FF :)
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [arm64] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<seb128> apw, it's not "on the day of FF", we have just been waiting for the current ones to clear out for a while
<seb128> apw, but mostly GNOME 3.28 ones
<seb128> evolution-data-server then gnome-settings-daemon
<seb128> but we wanted to migrate gnome-desktop3 first
<seb128> which got stucked due to libglvnd
<apw> well logic would dictate with the system as it is you should just dump them in -proposed and make
<apw> the transitions a total mess, or we could somehow record that you
<apw> did want to do them beforehand and are only holding them to be nice a
<apw> and not make you do FFe's for everytyhing, because you are doing it to be nice
<seb128> yeah, which is basically what I'm asking
<apw> well i would be down with that, but i would like someone else to agree
<seb128> I would be fine with a written IRC agreement than we are fine to upload e-d-s and g-s-d after ff due to other transitions blocking us
<seb128> k
<seb128> would that be slangasek?
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [armhf] (bionic-proposed/universe) [17.12.2-0ubuntu1] (kubuntu)
<seb128> let's see if somebody else steps up or if Steve has an opinion when he wakes up
<seb128> apw, thanks
<apw> slangasek or infinity sort of thing yeah, someone who has dones actaul release side of it
<apw> and can explain to me why this would be a bad plan should it be such a thing
<apw> seb128, did you see that pastebin, that has the actual error i saw indeed for bolt
<seb128> apw, yeah, I did thanks, that has a weird umockdev warning, wonder if that has been an issue with it ... but I'm going to keep an eye to see if I can reproduce
<apw> it seems like an odd one for sure
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [amd64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [armhf] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [arm64] (bionic-proposed) [17.12.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [i386] (bionic-proposed) [17.12.2-0ubuntu1]
<tkamppeter> jbicha, thanks. I have done it now: bug 1752579
<ubot5`> bug 1752579 in brlaser (Ubuntu) "Needs sponsoring: Upload brlaser 4" [High,New] https://launchpad.net/bugs/1752579
<apw> it sounds like this kde mess is close to done
<tkamppeter> jbicha, I hope the subscription to ubuntu-sponsors worked, as the subscribers to the bug do not get displayed currently.
<jbicha> apw: I think you're speaking a bit soon :(
<jbicha> apw: can you approve bolt/amd64 NEW too now?
<apw> jbicha, only repeating what i was told, accuracy may be lacking :)
-queuebot:#ubuntu-release- New: accepted bolt [amd64] (bionic-proposed) [0.1-0ubuntu1]
<jbicha> tkamppeter: to see you upload rights: bzr branch lp:ubuntu-archive-tools
<jbicha> cd ubuntu-archive-tools
<jbicha> ./edit-acl query -p till-kamppeter
<tjaalton> sigh, there are several python modules that need a MIR to unblock pyasn1 et al
<tjaalton> how much paperwork do these need?
<tjaalton> at least pycryptodome and pysmi needed to unblock pysnmp4, which then should unblock pyasn1 et al
<tjaalton> oh, already filed weeks ago
<tkamppeter> jbicha, thanks.
<sforshee> Laney: do you know if we're having general networking problems in adt on ppc64el?
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (artful-proposed) [0.2.36ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.4] has been marked as ready
<flexiondotorg> sil2100: ^
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (xenial-proposed) [0.2.31ubuntu1]
<sil2100> flexiondotorg: \o/ Thanks!
<tsimonq2> sil2100: Lubuntu got done last night ;)
<tsimonq2> stgraber: Hi! I proposed an MP to lp:queuebot a few weeks back, can I please get a review?
<tseliot> are we going to release 16.04.4 today?
<tsimonq2> tseliot: Hopefully, yes.
<tseliot> tsimonq2: ok, thanks
<xnox> sil2100, netboot s390x is good, both GA & hwe kernels.
<xnox> sil2100, i still want to test-boot LPAR and a VM, but these should be good, given that d-i booted.
<sil2100> xnox: \o.
<sil2100> Excellent
<tseliot> xnox: have you had the chance to test that issue with logind not letting go of fds?
<sil2100> valorie: hey! Could you give me a ping once you're up?
<sil2100> valorie: could you test .3 i386 kubuntu on your hardware?
<xnox> tseliot, nope, sorry, been busy =/
<tseliot> xnox: ok, np
<xnox> sil2100, frank tested lpar/kvm. so s390x can be marked as ready, both d-i/netboot & server.iso
<sil2100> xnox: excellent, thanks o/
<slangasek> seb128, apw: yes, I won't penalize for the transitions starting late due to -proposed being a jumble.  help getting the current transitions through is of course always appreciated
<seb128> slangasek, right, we have been doing that until the kde/qt piled up today
<seb128> slangasek, but thanks for confirming
<seb128> slangasek, apw, anyway bug #1752578 which is sort of ffe request if you want to +1 it already
<ubot5`> bug 1752578 in evolution-ews (Ubuntu) "Evolution 3.27/3.28 transition" [Wishlist,New] https://launchpad.net/bugs/1752578
<slangasek> seb128: what is the kde/qt pile-up today?
<blackboxsw> sil2100: if there is time today it looks like the cloud-init SRU only got half uploaded. rmadison sees 17.2.35 in artful-updates but not in xenial-updates
<blackboxsw> bug in question https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1747059
<ubot5`> Ubuntu bug 1747059 in cloud-init (Ubuntu Xenial) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2-35-gf576b2a2-0ubuntu1~16.04.1" [Medium,Fix committed]
<sil2100> blackboxsw: we're generally not publishing things to xenial-updates now because of the point-release
<sil2100> But I can see if we can actually publish cloud-init or not
<jbicha> so mesa depends on https://launchpad.net/ubuntu/+source/mir/0.30.0.1-0ubuntu1 on s390x :(
<blackboxsw> ohhh interesting, ok i wasn't aware of that being an issue. post a point release does that open up again?
<seb128> slangasek, https://launchpad.net/ubuntu/+source/libkf5pimcommon/4:17.12.2-0ubuntu1
<slangasek> hmm
<seb128> slangasek, that hit mesa and others
<jbicha> should we remove mir from proposed and then rebuild mesa and the 2 qt libraries that depend on mir too?
<seb128> alan_g, ^ what's the deal with mir 0.30 failing to build and sitting in bionic-proposed?
<acheronuk> slangasek: PIM stack taking much longer to build than was anticipated
<jbicha> acheronuk: next time, consider finishing the qt transition before starting a kde transition
<jbicha> acheronuk: Qt is blocked by lots of red autopkgtests and y'all said you needed Qt updated to let mesa through :(
<xnox> jbicha, i love it -> built nowhere, but on s390x =)
<jbicha> acheronuk: qt 5.9.4 was released over a month ago, so it's not clear why it wasn't done earlier
<acheronuk> ^^ tsimonq2
<acheronuk> Qt or mesa would not migrate even if all the tests passed
<apw> seb128, i've put some words in there ...
<seb128> apw, thx
<tsimonq2> jbicha: Things got busy, plus Meltdown/Spectre. Why, is there a problem?
<alan_g> seb128, I knew nothing about it
<alan_g> Where's the failed build?
<jbicha> alan_g: https://launchpad.net/ubuntu/+source/mir/0.30.0.1-0ubuntu1
<tjaalton> jbicha: why would mesa need a rebuild for mir? there's nothing there requiring 0.30
<jbicha> tjaalton: on s390x, libegl-mesa0 depends on libmirclient9 (>= 0.30.0.1)
<jbicha> it's mir's fault, not mesa's
<tjaalton> ah
<tjaalton> oh right, built on s390x
<alan_g> It doesn't help but libmirclient9 ABI is unchanged in 0.30, so (>= 0.30.0.1) isn't actually needed
<Laney> I'd prefer it if we could fix mir rather than going round on mesa again
<tjaalton> :)
<tjaalton> yes
<alan_g> The failures I've checked look spurious (mostly tests that ran so slowly that timeouts kicked in before they finished). But there are so many this time around.
<Laney> alan_g: you run dh_makeshlibs -V in mir, that causes this kind of dependency
<Laney> If -V is specified with no dependency
<Laney>            information, the current upstream version of the package is plugged into a dependency that looks
<Laney>            like "packagename (>= packageversion)".
<alan_g> Laney, it's all "magic" to me. I just repeat the incantation and it works.
<Laney> just saying, you're getting what you ask for :-)
<alan_g> Ack. I know that
<alan_g> Can we try rebuilding? I see no pattern to the failures and this has all built fine in our PPAs and COPRs
<jbicha> sure, let's give rebuilding a tryâ¦
<jbicha> (amd64 had already been retried once last night)
<Laney> I just looked and it had been tried 6 hours ago ...
<alan_g> :(
<Laney> So even if it works this time it's very flaky
<Laney> maybe we get lucky though
<Laney> got to get a train, back in a bit o/
<slangasek> acheronuk: "Qt or mesa would not migrate even if all the tests passed" - that is not a reason to pile on more transitions, quite the contrary
 * alan_g had hoped the build infrastructure was unusually heavily loaded at the time.
<acheronuk> slangasek: I take that point, just blaming me for all ills when when other people's ships are not in order either, seems a bit unfair
<acheronuk> not you I hasten to add
<acheronuk> and I'm still sitting here trying to sort this
<slangasek> tjaalton: hmmm freeipa-client has a hard-coded dep on libcurl3, and libcurl4 doesn't show up at all in shlibs:Depends.  I'll switch this from libcurl3 to libcurl4 but maybe it should be dropped altogether?
<LocutusOfBorg> damn is auto-import not disabled?
<tjaalton> slangasek: from proposed? I'll check
<tjaalton> freeipa still needs libnsspem to pass tests (server install..)
<tjaalton> :/
<LocutusOfBorg> I did sync something based on the fact that freeze was today
<tjaalton> I'm thinking of filing a tech-ctte bug about nss
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
<acheronuk> LocutusOfBorg: freeze is usually about 9pm UTC is it not?
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
<slangasek> tjaalton: yes, understood; but I'll fix the bug in front of me first
<tjaalton> slangasek: ok
<LocutusOfBorg> anyhow, they weren't new packages, so I didn't cause any extra work for AA folks
<LocutusOfBorg> FYI ^^ libplacebo is needed for vlc 3.0.1, I plan to merge it as soon as MoM is happy
<tjaalton> slangasek: and I had a look at memcached which still fails tests on armhf even after a new merge, so I'll just override running tests on armhf so it can migrate
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: dumb-jump-el [amd64] (bionic-proposed/universe) [0.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-muesli-smartcrop [amd64] (bionic-proposed/none) [0.2.0+git20180228.f6ebaa7+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (bionic-proposed/universe) [0.4.0-2] (kubuntu)
<xnox> slangasek, somehow it seems to me that python is busted on arm64 & s390x and that vim is possibly busted on arm64. Can we remove subversion/arm64 subversion/s390x vim/arm64 from bionic release?
<xnox> nobody uses vim on arm64, right dannf ?
<jbicha> alan_g: retry didn't really help https://launchpad.net/ubuntu/+source/mir/0.30.0.1-0ubuntu1
<slangasek> xnox: you're going to have to provide some context, and then the answer is probably still no wrt removing vim
<dannf> xnox: heh... well, i don't :)
<dannf> xnox: but i'd expect a lot of screams if it went away
<xnox> slangasek, no change rebuilds for ruby2.5-only failing =( http://people.canonical.com/~ubuntu-archive/transitions/html/html/ruby2.5-only.html
<slangasek> xnox: are you avoiding scheduling those for other things currently in -proposed?
<xnox> slangasek, there are no more rebuilds left to do.
<xnox> just fixing failures and autopkgtest regressions
<slangasek> k
<slangasek> make: execvp: /bin/sh: Argument list too long
<slangasek> fun autopkgtest failure
<slangasek> tyhicks: libseccomp autopkgtests fail with glibc 2.27; looks like a real test regression, can you investigate?
<xnox> slangasek, please process http://people.canonical.com/~ubuntu-archive/priority-mismatches.html
<xnox> slangasek, but do lint them
<sil2100> valorie: cyphermox just tested the i386 kubuntu install on his machine and it went fine
<tyhicks> slangasek: hi - how quickly does it need to be fixed?
<bdmurray> sil2100: should I not be releasing xenial SRUs?
<slangasek> tyhicks: glibc 2.27 should get into bionic release pocket this week.  If you can tell me it's ok to have this test regress because it's a test incompatibility and not a runtime incompatibility, that would unblock
<slangasek> xnox: wow, yes, linting them which I think is more than someone did when promoting them the other direction :)
<tyhicks> slangasek: ack - I'm tied up for the next couple hours but will be able to make that determination after
<slangasek> tyhicks: or if there's someone else on the security team you can delegate to/ :)
<xnox> slangasek, then publisher run, then rebuilding ubuntu-base should become better again.
<tyhicks> slangasek: yeah but they're in the same situation :)
<tyhicks> I'll try to take a quick look now
<slangasek> tyhicks: pff ;)
<slangasek> xnox: yep, thanks :)
<sil2100> bdmurray: we're almost ready, but just to be safe for now release only unseeded thingies
<xnox> i've checked everything, and then i'm like, there is no trace as to why it is still minimal after keyring fix.... unless priority-mismatches...
<slangasek> xnox: yes, minbase is precisely based on priorities
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.4] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.4] has been marked as ready
<slangasek> xnox: I don't see why priority-mismatches wants to promote libharfbuzz0b to important
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [s390x] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
 * tsimonq2 wonders how 16.04.4 is coming along...
<slangasek> xnox: libxml2 -> libicu60 -> libharfbuzz0b -> {libgraphite2-3, libfreetype6}.  Looks like icu needs fixing
 * acheronuk cries as new VLC breaks KDE tests for slower arches
<xnox> slangasek, it's trying to promote libicu-le-hb0 and... that
<slangasek> xnox: do you agree with fixing icu to not pull these deps in?
<xnox> slangasek, if i were you, i would only demote things =)
 * xnox looks
<xnox> slangasek, that's not libicu60 fault there.
<xnox> slangasek, libicu-le-hb0 is from icu-le-hb
<slangasek> ok
<xnox> slangasek, maybe libxml2 should use libicu60?
<slangasek> it does
<slangasek> and libicu60 depends libicu-le-hb0
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [amd64] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
<slangasek> sorry, I missed a link in the chain
<xnox> sigh
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [ppc64el] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
<xnox> yes it does
<xnox> wtf
<slangasek> + cc -o tools/generate_nlmsg tools/generate_nlmsg.c -I ../include/ ../lib/libnetlink.a ../lib/libutil.a /usr/lib/x86_64-linux-gnu/libmnl.a
<slangasek> cc: error: /usr/lib/x86_64-linux-gnu/libmnl.a: No such file or directory
<slangasek> ok seriously, now. in an arm64 autopkgtest?
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879820
<ubot5`> Debian bug 879820 in src:icu "configure icu with --enable-layoutex" [Important,Fixed]
<xnox>   32  * Build with ICU Layout Engine API (closes: #879820):
<xnox>   33    - add libicu-le-hb-dev build dependency,
<xnox>   34    - add libicu-le-hb-dev dependency to libicu-dev package,
<xnox>   35    - update layout extension tests,
<xnox>   36    - add libiculx to shlibs.
 * xnox ponders if that can be a separate package
<slangasek> oh, it's not icu-little-endian, ok
<xnox> i think /usr/lib/x86_64-linux-gnu/libiculx.so.60 needs to go into a separate package
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [i386] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
<slangasek> xnox: +1. will you make that change? should I?
<slangasek> mwhudson: I've come back around to where fpc and glibc/s390x itself are the last test failures to look at
<xnox> slangasek, it needs thought. because spliting that into separate package is easy, but we need to declare breaks on everything that depends on the layout engine by now, and rebuild things such that layout dependant things declare new dependency.....
<slangasek> xnox: if anything at all actually does depend on the layout engine
<slangasek> xnox: yes it needs thought - but do you have time to do that, or should I put it on my stack? :)
<xnox> > OpenTTD that is failing due to the layoutex component.
<xnox> yes, I didn't find any others.
<xnox> possibly just the one.
<xnox> slangasek, i am end of day, i can look at this tomorrow.
<slangasek> xnox: ok. before you go, have you seen the glibc/s390x autopkgtest regression?  Does this look ignorable?
-queuebot:#ubuntu-release- Unapproved: accepted python-cliff [source] (artful-proposed) [2.8.0-0ubuntu1.1]
<xnox> slangasek, if the log.gz will ever load
<xnox> i might see it
<slangasek> xnox: FAIL: malloc/tst-malloc-tcache-leak
<slangasek> original exit status 1
<slangasek> INFO: 624 (bytes) are in use before starting threads.
<slangasek> error: xpthread_check_return.c:32: pthread_create: Resource temporarily unavailable
<slangasek> error: 1 test failures
<xnox> found it.
<slangasek> xnox: with a different set of tests failing in the preceding run
<xnox> our canonistack overcommitted with memory?
<slangasek> this is scalingstack, not canonistack
<xnox> i meant scalingstack
<xnox> infinity, you did ask me for s390x before for glibc rebuild; did you rebuild glibc, and did all the tests pass?
<slangasek> and s390x is almost never near capacity on units
<xnox> slangasek, well.....
<slangasek> xnox: a memory overcommit problem would be showing up all over the place, not just in a glibc testsuite
<xnox> slangasek, it's the one mainframe, with a single pool, of overcommitted ram, on HMC level...
<xnox> slangasek, i do not believe we segregated RAM for scalingstack.
<xnox>  19/* The point of this test is to start and exit a large number of
<xnox>  20   threads, while at the same time looking to see if the used
<xnox>  21   memory grows with each round of threads run.  If the memory
<xnox>  22   grows above some linear bound we declare the test failed and
<xnox>  23   that the malloc implementation is leaking memory with each
<xnox>  24   thread.  This is a good indicator that the thread local cache
<xnox>  25   is leaking chunks.  */
<xnox> sounds like it is racy on purpose, and shouldn't be reliable in kvm
<slangasek> xnox: my biggest concern is that the run with that failure finished in half the time of the previous 2 runs which had a different set of (matching) failures
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [arm64] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
<xnox> slangasek, well, right now launchpad queue is empty & autopkgtest queue is empty
<xnox> slangasek, maybe it is a good time, to rerun it again, without much load.
<xnox> slangasek, and infinity did suspeciously ask for an s390x on the weekend on a weird channel.
<xnox> suspiciously
<xnox> slangasek, the error "Resource temporarily unavailable" in normal conditions, is a retryable error, no? one should not fail on unavailable?
<slangasek> mdeslaur: fwiw xmltooling got Complicatedâ¢; I have to disable xmlsec to get it to build at all, and if I do that there's actually no longer a library conflict.... otoh it causes the testsuite to fail because no one ever builds without xmlsec, and that's probably a serious regression in functionality
<slangasek> xnox: yes, I have already requeued
<mdeslaur> slangasek: :(
<tyhicks> slangasek: it was an issue with one of the libseccomp autopkgtests and I've just uploaded a fix
<bdmurray> LocutusOfBorg: Could you explain this version number to me? 5.1.34-dfsg-0ubuntu1.17.10.1~17.10.1
<xnox> slangasek, the test code looks wrong to me, at least upstart testsuite for memory allocations like that did handle EAGAIN
<tyhicks> slangasek: however, you are safe to proceed without waiting on the new libseccomp upload
<xnox> slangasek, i am asserting, that the test code does not handle pthread_create returning EAGAIN correctly; and thus the result of the test case should not be FAIL, but SKIPPED couldn't test.
-queuebot:#ubuntu-release- New binary: kopanocore [s390x] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
<slangasek> tyhicks: cheers
-queuebot:#ubuntu-release- New binary: kopanocore [ppc64el] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apt-xapian-index [source] (xenial-proposed) [0.47ubuntu8.4]
-queuebot:#ubuntu-release- New binary: gst-plugins-base1.0 [armhf] (bionic-proposed/main) [1.13.1-1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: kopanocore [i386] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kopanocore [amd64] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
<LocutusOfBorg> bdmurray, sure, it is mostly in sync with the previous SRU we used
-queuebot:#ubuntu-release- New binary: kopanocore [armhf] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
<acheronuk> was this meant to autosync? https://launchpad.net/ubuntu/+source/blogilo/4:17.08.3-1
<LocutusOfBorg> reason was: have a version that has *always* been lower than Ubuntu+1 and for sure higher than Ubuntu-1
<acheronuk> considering I had the ubuntu version removed earlier today
<LocutusOfBorg> and doing this, like a "backport of a future release that has been probably in Debian and Ubuntu" was a good versioning
<LocutusOfBorg> I did mostly the same in Debian, and I keep the same packaging to avoid more headaches
-queuebot:#ubuntu-release- New binary: kopanocore [arm64] (bionic-proposed/universe) [8.5.2-1ubuntu1] (no packageset)
<LocutusOfBorg> we discussed the versioning probably in the previous xenial SRU, in the bug template (I did use a wrong one, and somebody from Release Team suggested that one IIRC)
<LocutusOfBorg> can an AA accept libplacebo from new queue? this is an internal vlc transition, so I don't have to upload a new vlc after it gets accepted
<bdmurray> the previous one has .16.04.2 no ~release.number
<LocutusOfBorg> ok, so you can probably drop the ~foo at the end
<LocutusOfBorg> it was because I did a *lot* of uploads in my ppa, and I wanted to have people upgrading with the Ubuntu official one after the upload
<LocutusOfBorg> so, I used that versioning, and forgot to drop it :(
<LocutusOfBorg> it affect virtualbox/xenial virtualbox/artful virtualbox-hwe/xenial
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [amd64] (bionic-proposed/restricted) [390.25-0ubuntu2] (no packageset)
<nacc> slangasek: fyi, the kopnaocore uploads (now in new) should resolve the missing dependencies in bionic-proposed
<bdmurray> LocutusOfBorg: I think you own the work of dropping ~foo from the uploads.
<LocutusOfBorg> already doing it :)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.40-dfsg-0ubuntu1.16.04.2 => 5.1.34-dfsg-0ubuntu1.16.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox (artful-proposed/multiverse) [5.1.30-dfsg-1 => 5.1.34-dfsg-0ubuntu1.17.10.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.0.40-dfsg-0ubuntu1.16.04.1~16.04.4 => 5.1.34-dfsg-0ubuntu1.16.04.1] (no packageset)
<LocutusOfBorg> we should be good now, wrt versionig :)
<LocutusOfBorg> sorry again!
<slangasek> acheronuk: is it an accident that libkf5libkdepim again builds on ppc64el+s390x?
<slangasek> and who broke the yaml that retry-autopkgtest-regressions needs to parse >_<
-queuebot:#ubuntu-release- New: accepted debos [amd64] (bionic-proposed) [1.0.0+git20180112.6e577d4-1]
-queuebot:#ubuntu-release- New: accepted debos [i386] (bionic-proposed) [1.0.0+git20180112.6e577d4-1]
-queuebot:#ubuntu-release- New: accepted fonts-monoid [amd64] (bionic-proposed) [0.61-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [amd64] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [armhf] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [ppc64el] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (bionic-proposed) [9.1.85-1]
-queuebot:#ubuntu-release- New: accepted debos [arm64] (bionic-proposed) [1.0.0+git20180112.6e577d4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-muesli-smartcrop [amd64] (bionic-proposed) [0.2.0+git20180228.f6ebaa7+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [i386] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted puredata [amd64] (bionic-proposed) [0.48.1-3]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (bionic-proposed) [2.18.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (bionic-proposed) [2.18.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (bionic-proposed) [2.18.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted dumb-jump-el [amd64] (bionic-proposed) [0.5.2-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [s390x] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (bionic-proposed) [9.1.85-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (bionic-proposed) [2.18.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (bionic-proposed) [2.18.17+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-base1.0 [arm64] (bionic-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted python-funcsigs [amd64] (bionic-proposed) [1.0.2-4]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (bionic-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (bionic-proposed) [2.18.17+dfsg-1]
<slangasek> LocutusOfBorg: libplacebo accepted, but I don't see how this doesn't still require a vlc reupload; vlc-plugin-video-output depends on libplacebo3
<LocutusOfBorg> slangasek, https://release.debian.org/transitions/html/auto-libplacebo.html
<LocutusOfBorg> don't know, it is listed here
<slangasek> LocutusOfBorg: I don't see how a Debian transition tracker is supposed to tell you anything about whether Ubuntu binaries need rebuilt
<slangasek> LocutusOfBorg: all that seems to tell *me* is that the vlc binaries in Debian were built against the new libplacebo
<LocutusOfBorg> I use britney for that, I didn't check Ubuntu, I don't upload if not needed :)
<acheronuk> slangasek: not an accident. but just a consequence of it's build-dep akonadi-contacts removing it's requirement to build itself against qtwebengine
<slangasek> LocutusOfBorg: ok; that's fine, it's just that you earlier asserted that a reupload wasn't needed
<slangasek> acheronuk: ok.  I've stabbed some more autopkgtest retries
<acheronuk> sadly same can't be sais for the rest
<acheronuk> *said
<LocutusOfBorg> slangasek, I have to leave for ~3h, I wanted to avoid a "possible" and useless rebuild, sorry if in my words it seemed to be "necessary" :)
<slangasek> xnox: glibc s390x retest completed, and we're back to the original 4 failures instead of the racy one.  So I guess we need some analysis of those
<LocutusOfBorg> anyhow, tonight I'll learn something new in case :P
<slangasek> turned off the Debian importer
<sil2100> ...point release publishing
<slangasek> re-queued --all-proposed for ruby-related failures
 * sil2100 types in random publish-release commands and hides
<mwhudson> slangasek: hi
<slangasek> mwhudson: good morning!
<mwhudson> slangasek: so fpc did you say?
<slangasek> mwhudson: ayup
<mwhudson> huh it actually has revdeps so there goes idea #1 /s
<slangasek> :)
<mwhudson> slangasek: so it seems to me that it is slightly incompatible in that glibc 2.27 now expects the compiler's crt0.o (or whatever it's called) to define __dso_handle and fpc's doesn't
<mwhudson> slangasek: but it's obviously not very incompatible because the only effect this has is to transform one test that currently segfaults in release to one that fails to compile in proposed
<mwhudson> slangasek: so uh, shrug?
<slangasek> mwhudson: would it be worth sanity-checking that conclusion by doing a rebuild test of the things using fpc in the archive, against latest glibc?
<slangasek> mwhudson: or does it even need a rebuild, vs. testing the existing binaries?
<mwhudson> slangasek: hm yes that probably would make sense
<mwhudson> slangasek: rebuilding i think, it's a link against libc_nonshared.a that fails...
<mwhudson> i don't understand at all how the fpc test suite works i think
<mwhudson> what are the chances that a packge name matching golang.*ratecounter.* is going to have flaky tests?
<mwhudson> slangasek: so i've copied-with-binaries glibc to ppa:mwhudson/devirt
<mwhudson> slangasek: i'll copy-without-binaries rev-build-deps of fpc when that's published
<slangasek> mwhudson: you could also just configure the ppa to build against -proposed, without needing to copy glibc
<slangasek> faster than waiting for a publication run
<mwhudson> slangasek: is http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20171220-bionic.html new enough for comparison? i guess i hope so
<mwhudson> slangasek: true but less hygenic i guess? as in that will get other bits of -proposed
<mwhudson> mind you for a rebuild test that's ok i guess given builds build against proposed anyway
<slangasek> yeah
<mwhudson> oh heh this ppa was configured against proposed anyway :)
<sil2100> bdmurray: hey! Can you update http://changelogs.ubuntu.com/meta-release xenial to 16.04.4?
<bdmurray> sil2100: sure
<sil2100> bdmurray: thanks
<bdmurray> you'd think my now I'd sort out the server name change
<bdmurray> s/my/by/
<bdmurray> sil2100: all done
-queuebot:#ubuntu-release- Packageset: 397 entries have been added or removed
<sil2100> \o/
<stgraber> FYI, LXD is going to miss the feature freeze by a couple of hours, sorting out some autopkgtest failures locally before uploading.
<slangasek> anyone looked at why retry-autopkgtest-regressions scales so poorly?
<nacc> slangasek: i have not, but i did notice it too (when php was particularly bad)
<tsimonq2> Feature Freeze /o/ \o\ /o/ \o\ /o/
<nacc> slangasek: since you have context, could you ack LP: #1752713 ?
<ubot5`> Launchpad bug 1752713 in gosa (Ubuntu) "Please sync gosa 2.7.4+reloaded3-2 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1752713
<slangasek> nacc: ack and this doesn't need an FFe
<nacc> slangasek: oh ok, i wasn't sure -- since it's a 'feature' in the sense of a new package
<slangasek> nacc: looks like it's the yaml parsing itself that's slow
<nacc> slangasek: i could see that
<slangasek> nacc: we don't auto-sync such packages anymore, but individual Ubuntu devs can exercise judgement on new packages that are "safe" to sync
<nacc> slangasek: ok, thanks for clarifying and sorry for the noise
<sil2100> 16.04.4 officially released, sending out the announcement now
<sil2100> (sorry for the noise)
<flocculant> sil2100: thanks for doing the stuffs :)
<nacc> sil2100: nice work!
<tsimonq2> sil2100: Thanks!
<tsimonq2> slangasek: Latin like last cycle's FF topic change? :D
<mwhudson> slangasek: no new failures
<slangasek> nacc: wow ok, so it's actually not the yaml parse time, it's the download time of update_excuses.yaml <_> <_< >_<
<sil2100> slangasek: do you know who I should poke about ubuntu-announce/ubuntu-release moderation?
<slangasek> we need proper download caching in the ubuntu archive tools
<nacc> slangasek: has it exploded again? or is it just 'slow'?
<slangasek> sil2100: ubuntu-announce moderation done
<sil2100> slangasek: thanks! :)
<slangasek> nacc: 52s here to stream the file to /dev/null.  I don't *think* it's my network that's to blame
<slangasek> nacc: 39MB of yaml, tho
<sil2100> slangasek: I guess someone needs to approve the ubuntu-release@ one as well, I guess because I sent it out from an unsubscribed e-mail
<sil2100> Big thanks for your help everyone o/
<nacc> slangasek: took almost 2 minutes here
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.4] has been marked as ready
<slangasek> sil2100: yeah turns out I don't have mod bits on ubuntu-release :)
<slangasek> tsimonq2: which bit was (needs to be) latin?
<valorie> sil2100: cyphermox, thanks! i've marked it as ready
<tsimonq2> slangasek: My terminology is off (I don't study specifics of any languages besides English and Spanish (which isn't my strong suit to say the least!)) but to jog your memory: https://irclogs.ubuntu.com/2017/08/26/%23ubuntu-release.html
<slangasek> tsimonq2: oh. the latin is still there, the other stuff is just IPA :)
<tsimonq2> slangasek: ahhhhh, that's the right terminology
<wxl> i'm hoping someone can provide me some advice, as i'm pulling my hair our here trying to figure something out with lubuntu seeds (always a wonderful source of confusion). it looks like on our desktop image (not the alternate), xiterm+thai is showing up and ending up as x-terminal-emualtor. looking at the logs it looks like it's installed as a depend of apport-gtk (line 3859). perhaps this is because
<wxl> lxterminal isn't installed first (doesn't happen until #3958) and apport-gtk requires some x-terminal-emulator?
<wxl> however, i'd expect whichever terminal is installed last to be x-terminal-emulator, but maybe that's foolish of me.
<LocutusOfBorg> slangasek, trying: libplacebo gives -->  * amd64: browser-plugin-vlc, forensics-extra-gui, forensics-full, freeplayer, freetuxtv, hdhomerun-config-gui, kaffeine, libplacebo-dev, libplacebo4, phonon-backend-vlc, phonon4qt5-backend-vlc, vlc, vlc-plugin-video-output, vlc-plugin-vlsub
<LocutusOfBorg> so, vlc needs rebuild?
<slangasek> LocutusOfBorg: yes it does
<LocutusOfBorg> thanks!
<nacc> wxl: funny, i think FurretUber in #ubuntu+1 reported that issue this AM :)
<tsimonq2> nacc: He popped into #lubuntu-devel and this is a result of that debugging :)
<nacc> ah cool
<nacc> tsimonq2: thanks for the context
<wxl> nacc: yeah i thought it was crazy at first, but there it is :/
<wxl> it's only lubuntu, too, at least from a spot check of 3 other flavors (no surprise there)
<nacc> wxl: i think the germinate output would confirm your suspicion
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [amd64] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [s390x] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [ppc64el] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
<blackboxsw> sil2100: per trying to fast-track cloud-init SRU into xenial let's hold. regression on GCE w/ user-data not being observed
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [i386] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
<blackboxsw> regression only affects artful/gce
<wxl> nacc: to be clear, that's what exactly?
<nacc> wxl: germinate is what ends up processing the seeds
<nacc> wxl: it's at http://people.canonical.com/~ubuntu-archive/germinate-output/
<wxl> that's what i needed. thanks nacc
<nacc> wxl: but neither package is preinstalled, so it's coming from the task at install time, right?
<wxl> nacc: right. and i have NO idea why xiterm+thai is even getting int here at all.
<nacc> wxl: yeah it's seeded in 'daily-live' `seeded-in-ubuntu` says
<wxl> nacc: i explored the possibility of language-pack-th requiring it but that's not the case
<nacc> wxl: whereas lxterminal is in daily and daily-live
<wxl> nacc: which of these many files do you see that in?
<nacc> wxl: i'm going off `seeded-in-ubuntu`'s output
<wxl> oh!
<nacc> wxl: https://wiki.ubuntu.com/SeedManagement may help too
<nacc> (the debugging seed problems part)
<nacc> wxl: i do see libthai0 and libthai-data in http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/bionic/daily-live-20180301.log
<nacc> wxl: so i guess i'd need to grab your seeds ot be sure
<wxl> nacc: neither of those seem like they require xiterm+thai tho
<nacc> wxl: agreed
<nacc> wxl: i think your original assessment (x-terminal-emulator being needed) is accurate, the question is why xiterm+thai is vailable at all probably
<nacc> wxl: if they are both avialable, i'm not sure how apt picks
<wxl> nacc: well, right, there's the question of if there are more than one how does it choose, but the other factor is i don't know how xiterm got there at all!
<nacc> wxl: yeah, double bogeys :)
<nacc> wxl: reading, seeing if i can help
<nacc> slangasek: is often my goto for this, but i think he's pretty busy right now
<wxl> well, thanks for the help. i'll keep poking at it, but if you get any ideas, please ping me or tsimonq2
<nacc> wxl: will do
<nacc> http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.bionic/rdepends/
<nacc> wxl: --^ that is a useful directory, and is what i was looking for
<nacc> you can see why packages get pulled in
<wxl> great! thanks
<wxl> nacc: except xiterm isn't there *cries*
<nacc> wxl: yeah and i don't know why
<nacc> wxl: i'm assuming you've grepped your verbatim seeds etc
<wxl> nacc: yep
<wxl> nacc: we do have (fonts-thai-tlwg) but that's not it
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [arm64] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
<wxl> nothing in germinate_output, nothing in all+extra. ugh i'm going to be bald soon
<nacc> wxl: just to be 100% you've d/l the lubuntu iso and you see the package on the iso, right?
<wxl> nacc: i've grabbed both the alternate and desktop images from today and installed them. alternate doesn't have xiterm+thai. desktop does, and it's x-terminal-emulator. it's also in the manifest, fwiw.
<nacc> wxl: ok
<wxl> and just for grins
<wxl> strings bionic-desktop-amd64.iso | grep xitermxiterm+thai     1.10-2
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Artful 17.10 | Archive: open | Bionic 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
<wxl> ah well you get the idea :)
<nacc> wxl: by any chance did you check any older isos?
<nacc> wxl: i wonder if you might need to run germinate locally ... or you'd need someone with access to cdimage
<wxl> nacc: i checked as far back as is available on cdimage for bionic, but there's no problem with artful and before
<wxl> nacc: if anyone's tried to run germinate locally it's tsimonq2 so i'll leave that to him :)
<nacc> wxl: hrm
<slangasek> python datetime tz handling is a special kind of hell
<nacc> slangasek: yes it is
<wxl> nacc: that said, somewhere betwen october and now there's a problem. i could bisect it, but it looks like that would be extremely time consuming because the images would need to be produced. it seems that the germinate-output isn't very telling..
<nacc> wxl: yeah i thought there was a 'better' output page, i'm sorry -- i know i've seen it
<blackboxsw> regression filed sil2100 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1752729
<ubot5`> Ubuntu bug 1752729 in cloud-init (Ubuntu) "GCE: cloud-init 17.2.35 no longer processes user data" [Undecided,New]
<wxl> nacc: what really gets me is the cd-build-logs don't show anything there either.
<nacc> wxl: yeah i'm finding that quite confusing too
<nacc> well they show a relative diff, but not the file contents
<wxl> nacc: however there they are in the ubuntu-cdimage logs
<nacc> wxl: where are those logs?
<wxl> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/lubuntu
<wxl> ^ nacc
<nacc> wxl: very strange; i would assume that would only be a possible satisifier if they were already avilable on the seeds
<wxl> nacc: yes but clearly logic here doesn't apply XD
<nacc> wxl: heh
<jbicha> wxl: virtual packages aren't always handled that well, my initial thinking is that you need to change apport-gtk's Depends from simply "x-terminal-emulator" to something like
<wxl> nacc: do you know how these two cd logs are related?
<nacc> wxl: i have no clue :/
<jbicha> "gnome-terminal | mate-terminal | tilix | lxterminal | x-terminal-emulator" or whatever
<jbicha> wxl: do you have a LP bug for this issue yet?
<wxl> the ubuntu-cdimage one appears to start around 16:38:49 while the cd-build-logs one begins at 16:38:26
<wxl> so they seem to be covering the same info to some degree
<wxl> my assumption would be that the ubuntu-cdimage logs are part of the cd-build-logs, but without the verbosity
<nacc> jbicha: i think that is a 'fix', but it doesn't explain why this alternative package is on the ISO in the firs tplace
<wxl> last time on ubuntu-cdimage is 16:56:49 but cd-build-logs 17:09:01
<jbicha> wxl: you could also try a ! trick thing like I used at https://bazaar.launchpad.net/~ubuntu-gnome-dev/ubuntu-seeds/ubuntu-gnome.bionic/view/head:/live#L74
<wxl> jbicha: apport-gtk requires x-terminal-emulator, which includes lxterminal (and xiterm+thai)
<nacc> jbicha: ah an explicit unseed?
<jbicha> nacc: my guess is that germinate or whatever just makes things up when it finds a virtual package like that
<wxl> and i don't think that's a bad thing. i don't want to make it harder for thai folks to get what they need
<wxl> also, again, this wasn't an issue before so thta's just.. weird
<jbicha> I had trouble getting xterm out of main because of weird virtual package issues
<nacc> jbicha: ah i guess i could see that
<wxl> i don't see any unseeds in that link fwiw :)
<nacc> wxl: line 74
<wxl> oh hah missed it
<nacc> wxl: it's hard to read :)
<jbicha> wxl: xiterm+thai has no rdepends and as long as you don't literally add "Conflicts: xiterm+libthai", you won't be hurting any one that wants to use that package
<wxl> i guess that might be a possible solution, but it seems like an annoying band aid
<jbicha> wxl: the band aid might be a lot easier than going down the rabbit hole to try to teach these tools to handle virtual packages smarter
<wxl> i hear you jbicha :(
<wxl> here's the bug https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1752733
<ubot5`> Ubuntu bug 1752733 in lubuntu-meta (Ubuntu) "Default terminal emulator is set to txiterm, which causes problems with certain characters" [Undecided,New]
-queuebot:#ubuntu-release- New sync: gosa (bionic-proposed/primary) [2.7.4+reloaded3-2]
<jbicha> I don't know how terminals work, but it feels to me like there are 2 problems here: 1. xiterm+thai shouldn't be installed. 2. When it is installed, why is it default?
<wxl> jbicha: like you said, #1 is a rabbit hole, but re: #2, i think it may have something to do with timing, like which is installed first/last.
<wxl> jbicha: though logically i would expect the last one to be the default terminal and that's not the case here. lxterminal is last.
<jbicha> wxl: #2 that doesn't sound right to me. How do you set the default app for other apps?
<wxl> jbicha: a lot of packages have post-inst scripts to make them default, or at least that's been my experience
<jbicha> installing chromium-browser shouldn't change the default browser from firefox for instance
<jbicha> wxl: btw, lxterminal 0.3.1-1 (this release cycle) lowered its x-terminal-emulator update-alternatives priority to be the same as xiterm+libthai
<nacc> ah could that be why?
<wxl> the postinst script in both sets priority to 20
<wxl> oh hah
<wxl> gmta
<jbicha> what do you mean by "default terminal"?
<wxl> what ultimately is symlinked as x-terminal-emulator
<wxl> so here's my thinking:
<wxl> 1. xiterm+thai is installed, and set to to 20 and since it's the first terminal, it's x-terminal-emulator by default
<wxl> 2. lxterminal is installed, and set to 20 which is no greater than xiterm+thai, so it does not change the value of x-terminal-emulator
<wxl> whereas before that, lxterminal would have taken precedence
<nacc> that would answer 2)
<wxl> that still does NOT explain why xiterm is on there tho XD
<jbicha> ok, I'll accept that explanation
<nacc> still no answer for 1), afaict? :)
<wxl> but i think the unseed is not a terrible idea
<nacc> it would at least unbreak it for now
<wxl> yepp
<nacc> and you can always change it back if you figure out what's going on
<wxl> who did you say would be the goto person for seed issues, nacc ?
<nacc> slangasek is who i've asked in the past
<nacc> i think any release team member or AA would know something about them, though :)
<wxl> ok great. i'll bug him when he's awake again. thanks for the help to you and jbicha
<jbicha> wxl: also try specifically seeding lxterminal in 'live' ?
<slangasek> I'd point to any of cjwatson, infinity, or stgraber as deeper seed experts than myself
<jbicha> it may take several days to try out different seed fixes, good luck! :)
<nacc> slangasek: thanks :)
<slangasek> nacc: meanwhile, I've just spent 1.5h hacking retry-autopkgtest-regressions, to save 1 minute off its running time :P
<jbicha> wxl: because of the nature of the bug, you may have to add a lof of ! rules
<jbicha> wxl: see apt-cache showpkg x-terminal-emulator for a list of all the packages that provide that virtual package
<slangasek> cyphermox: I've just landed some improved cache handling for update_excuses.yaml to retry-autopkgtest-regressions which I think you'll want to factor out and include in migration-assistant
<wxl> i'll bug everyone in the morning when the usual parties are more awake then. thx slangasek
<wxl> jbicha: i hope it doesn't come to that.
<jbicha> wxl: you could also email the ubuntu-release list
<slangasek> typically the way you work around "I'm getting the wrong implementation of $foo in my seeds" is to seed an alternative implementation "before"
<nacc> slangasek: nicely done :)
<slangasek> the trouble is I never remember what "before" means in seedland
<wxl> slangasek: i had that thought but i wouldn't expect that in lieu of no terminal emulator that xiterm+thai would be the goto XD
<cjwatson> It'd be random
<cjwatson> Essentially
<wxl> oh
<wxl> well maybe that's it then
<wxl> ok, so now i just need to figure out the "before" thing
<cjwatson> Should be sufficient to seed an alternative implementation in the seed that (indirectly) contains the dependency, or in an "inner seed" (i.e. one that that seed inherits from)
<jbicha> wxl: just try adding lxterminal to desktop-gtk then
<cjwatson> germinate tries to follow roughly what apt would do if it were asked to install each seed in turn: that is, for each seed, it marks all the packages that are explicitly seeded for installation, and then it tries to unbreak any resulting broken dependencies
<jbicha> wxl: maybe sort of like https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/commit/?id=6d424570
<wxl> how exactly do i determine the sequence of installation outside of going through all the seeds one at a time?
<cjwatson> It prefers to pick packages that are seeded somewhere relevant (for some value of relevant ...) where it can, but failing that it'll be arbitrary
<cjwatson> It's usually best to run germinate locally
<wxl> i'm pretty sure tsimonq2 has germinate laying around on his machine
<cjwatson> It's packaged, and its list of options is not impossibly long so it should be reasonably straightforward to duplicate what it does
<cjwatson> Try to reproduce the bug first: come up with an invocation that shows the offending package being included in the output for some relevant seed
<cjwatson> ... against a local but unmodified copy of the seeds
<cjwatson> Then modify your local seeds until you get something that produces the desired output
<cjwatson> Make sure to run germinate in an empty directory, as it'll spit out its many many output files all over it
<cjwatson> And for a local run you probably want --no-rdepends or it'll take forever to emit all the gazilliojnn tiny little files
<cjwatson> *gazillion
<slangasek> E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/d/debconf/debconf-i18n_1.5.66_all.deb  Could not connect to ftpmaster.internal:80 (91.189.89.99), connection timed out
<slangasek> aha, so the armhf autopkgtest problem isn't strictly a DNS problem, sometimes it randomly fails on other traffic too. :P
<wxl> the one thing that's confusing is we haven't changed the location of apport-gtk or lxterminal in our seeds since 2016
<mwhudson> it's spectre's fault because we finally rebooted the machine germinate runs on!
<mwhudson> (joking...)
<tsimonq2> hahahaha
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (artful-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~17.10.1 => 17.2-35-gf576b2a2-0ubuntu1~17.10.2] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> thx ^
<slangasek> juliank: fyi, apt 1.6~beta1 fails its tests in bionic
#ubuntu-release 2018-03-02
 * tsimonq2 wonders why cdimage.ubuntu.com isn't HTTPS
<xnox> tsimonq2, $$$$$ most of cdimage.ubuntu.com, is a shop-front for a CDN
<tsimonq2> xnox: Ah ok, and the CDN doesn't support HTTPS?
<xnox> tsimonq2, well, it breaks things, as one would strain things via cdimage, rather than redirect connect people to the cdn.
<tsimonq2> xnox: Ah ok, thanks.
<xnox> vim build.... probably somebody did something in the archive
<xnox> so we are now down to subversion on arm64 & s390x to be in shape for ruby2.5-only migration
 * tsimonq2 wonders why we don't have Ubuntu archive CDNs as wel..
<tsimonq2> *well...
<xnox> tsimonq2, we have extensive archive mirror network; e.g. in every cloud region out there, more or less.
<tsimonq2> xnox: Right, but something like deb.debian.org I mean
<xnox> tsimonq2, and archive, is no nearly as much strain as cdimage. cdimage is very large single file.
<tsimonq2> xnox: Right
<xnox> tsimonq2, i keep pondering to setup deb.debian.org for ubuntu, and check how much it would actually cost to run.
<xnox> tsimonq2, debian gets it sponsored to them, for free.
<tsimonq2> xnox: If you've been pondering it meaning to do it and it's a reasonable thing to calculate, please, do it, I've been wondering about this for a while now :)
<xnox> tsimonq2, storage cost at S3 is ok, looks like $30 a month; push to cloudfront is free; but then it's like $0.085 a GB a month cost.
<xnox> download a gig of updates over a month, for a single machine is trivial.
<xnox> thus even 10,000 installs hitting cloudfront will cost $850 a month, which is not sustainable.
<tsimonq2> Right
<tsimonq2> OK
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
<blackboxsw> bdmurray: thanks for the xenial-verification-failed tag on the SRU bug. Fix is queued for cloud-init
-queuebot:#ubuntu-release- New sync: libmanette (bionic-proposed/primary) [0.2.0-1]
-queuebot:#ubuntu-release- New sync: materia-gtk-theme (bionic-proposed/primary) [20180110-1]
<blackboxsw> tjaalton if you get a chance today, cloud-init 17.2.35 regression fix upload is queued (currently only affects artful). If there is time to get that published to proposed I'll be able to validate the SRU-cherry pick tomorrow morn my time.
<blackboxsw> xenial is queued too (but xenial wasn't published to updates yet)
<blackboxsw> I've gotta head out for the night, but will look in early tomorrow
<slangasek> xnox: a bunch of ruby autopkgtests were failing because ruby-typhoeus was uninstallable (depends ruby-ethon -> libcurl3).  I've uploaded ruby-ethon, so any of those tests are retriable against -proposed once it publishes
-queuebot:#ubuntu-release- New: accepted kopanocore [amd64] (bionic-proposed) [8.5.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kopanocore [armhf] (bionic-proposed) [8.5.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kopanocore [ppc64el] (bionic-proposed) [8.5.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kopanocore [arm64] (bionic-proposed) [8.5.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kopanocore [s390x] (bionic-proposed) [8.5.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted kopanocore [i386] (bionic-proposed) [8.5.2-1ubuntu1]
* slangasek changed the topic of #ubuntu-release to: Released: Xenial 16.04.4, Artful 17.10 | Archive: feature freeze | Bionic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<slangasek> ok, I think most of the test regressions on update_excuses are now 'interesting' (very few that are going to pass by changing the combination of triggers)
<tjaalton> blackboxsw: sure thing
<tjaalton> acheronuk: are you handling the remaining mesa tests? kdepim-addons tests take ~4h to timeout.. so retrying needs to be coordinated
<slangasek> looks to me that kdepim-addons is going to need something other than a retry
<acheronuk> tjaalton slangasek: I have been looking this morning. that kdepim-addons test has been timing out on KDE's own CI autotests since at least beginning of December
<tjaalton> quality.
<slangasek> tjaalton: also, I've added a skiptest hint for mesa; now it's only blocked on glibc
<tjaalton> slangasek: ok
<acheronuk> was going to suggest ignoring for now. as I'll have to report it and action may not be quick. even if I ignore it somehow, taht will take time to re-run
<acheronuk> *that
<slangasek> the autopkgtest runners are pretty idle right now; don't hesitate to throw any tests at them that are needed
<acheronuk> I don't see mesa etc in what would migrate in update_output_notest.txt, so are there issues more than just test fails still?
-queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
<tjaalton> infinity: looks like glibc tests need updating? see the s390x failure
<tjaalton>     /usr/lib/gcc/s390x-linux-gnu/7/include/varargs.h:4:2: error: #error "GCC no longer implements <varargs.h>."
<tjaalton>      #error "GCC no longer implements <varargs.h>."
<tjaalton>       ^~~~~
<tjaalton>     /usr/lib/gcc/s390x-linux-gnu/7/include/varargs.h:5:2: error: #error "Revise your code to use <stdarg.h>."
<tjaalton>      #error "Revise your code to use <stdarg.h>."
<LocutusOfBorg> apw, slangasek, please update vbox hint "force-badtest virtualbox/5.2.8-dfsg-2"
<apw> LocutusOfBorg, britney hasn't even tested that version yet
<LocutusOfBorg> but it will fail exactly the same way, I didn't fix it
<LocutusOfBorg> I fixed an issue that was throwing a lot of errors during installation
<apw> but as it is changed it might fail an altogether new way too, so till we see the log to confirm it is the old way, it isn't safe to change the hint
<tseliot> apw: hi, can you approve libnvidia-common-390 (nvidia-graphics-drivers-390), please? It's the only binary that is still in NEW
<apw> tseliot, looking
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [amd64] (bionic-proposed) [390.25-0ubuntu2]
<tjaalton> apw: we need glibc migrated, but the remaining tests don't pass
<tjaalton> fpc and glibc itself (on s390x)
<tjaalton> packages built against libglvnd in proposed migrate happily because bionic has an old version of it which doesn't pull in the mesa bits
<tjaalton> which "breaks" the system
<tjaalton> since the updates pull in libegl1
<tjaalton> that'll replace the lib from mesa
<tseliot> apw: thanks!
<tseliot> oh no. apw ^^
<tjaalton> the result is no acceleration
<tjaalton> there was bug 1714451
<ubot5`> bug 1714451 in libglvnd (Ubuntu) "please remove libglvnd from the archive" [Undecided,Invalid] https://launchpad.net/bugs/1714451
<tjaalton> and when I noticed it was still open when the migration was about to start, I closed it
<tjaalton> didn't think it would bite this way
<apw> glibc's own tests not passing on an arch seems pretty worrying
<tjaalton> look a few lines up
<tjaalton> it's just a buggy test with current gcc
<tjaalton> so a tradeoff of a possibly buggy fpc versus crippled desktops is a simple one to me
<LocutusOfBorg> apw, http://autopkgtest.ubuntu.com/packages/v/virtualbox/bionic/amd64
<apw> tjaalton, i am struggling to even understand the attempt fcp is making at telling me what it thinks is wrong with its tests
<tjaalton> apw: yes, so just badtest it
<tjaalton> at least for now
<tjaalton> I couldn't figure it out either
<apw> tjaalton, so i think you miss-read the failure for s390x, that gcc thing is XFAIL for the previos test
<apw> tjaalton, backtrace4 and 5 are complaining that the trace is short
<tjaalton> indeed, varargs test is skipped anyway
<apw> tjaalton, the other two, who can say as they tell you next to nothing, ass-hattery for a test-suite output
<apw> the backtrace ones you could argue are not likely to be highly exercised except in debugging
<apw> but the other two, i have next to no idea what they are even testing, the names are opaque
<tjaalton> right
<tjaalton> apw: so, what's the verdict?
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.7 => 3.168.8] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.2-35-gf576b2a2-0ubuntu1~17.10.2]
<stikonas> xnox: hi. Will Ubuntu 18.04 ship with util-linux 2.31.1?
<xnox> stikonas, it is possible. it has not migrated yet. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
<xnox> i am trying to upgrade it to 2.31.1
<tsimonq2> slangasek: topic> aww, you're no fun :P
<xnox> stikonas, are you aware of any bugs? or require any outstanding patches?
<stikonas> xnox: well, I have one patch: https://github.com/karelzak/util-linux/commit/8175ed3d74adacc895657ded7546cb3c5deeabad
<stikonas> this is part of 2.32
<xnox> stikonas, that's not in. Please open a bug on launchpad, specify impact / test case / pointer to the patch. And we can review it.
<stikonas> there are two more patches that are part of 2.31.1, so hopefully those will be in
<stikonas> xnox: ok, will do it
<xnox> stikonas, assume, to fill the bug out, as if you'd want to request an LTS SRU.
<xnox> stikonas, please note, that I am busy in meetings all next week, so may not get to it, until two weeks time.
<stikonas> ok, no problem, it's not urgent
<stikonas> ok, I filled in the bug report https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1752876
<ubot5`> Ubuntu bug 1752876 in util-linux (Ubuntu) "sfdisk: allow disabling boot flag on MBR partition table" [Undecided,New]
<smoser> tjaalton: could you look at the cloud-init sru for xenial also ?
<smoser> you did the artful one, we'd like the xenial in -proposed also.
<tjaalton> smoser: alright
<tjaalton> smoser: so one needs to be rejected then?
<smoser> i uploaded 2, the second upload (2 hours later) has the better changes file.
<smoser> 'rejected', from the queue, right?
<tjaalton> right
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.2]
<smoser> yeah, reject the first upload.
<smoser> where is the udoes the queue just not show the .changes file ?
<smoser> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<smoser> oh. funny. no. you just have to click on the package name.  i just assumed the package name would do the same thing as the twisty/expand arrow.
-queuebot:#ubuntu-release- New binary: mate-menus [amd64] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: mate-menus [s390x] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: mate-menus [i386] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: mate-menus [ppc64el] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: mate-menus [arm64] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: mate-menus [armhf] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
<smoser> thank you!
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.2]
<tjaalton> there
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.8]
<blackboxsw> excellent thanks tjaalton smoser
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.1 => 0.6.5.11-1ubuntu3.2] (core)
-queuebot:#ubuntu-release- New sync: linux-aws (bionic-proposed/primary) [4.4.0-1052.61]
-queuebot:#ubuntu-release- New sync: linux-gke (bionic-proposed/primary) [4.4.0-1034.34]
-queuebot:#ubuntu-release- New sync: linux-azure (bionic-proposed/primary) [4.13.0-1011.14]
-queuebot:#ubuntu-release- New sync: linux-hwe (bionic-proposed/primary) [4.13.0-36.40~16.04.1]
-queuebot:#ubuntu-release- New sync: linux-meta-aws (bionic-proposed/primary) [4.4.0.1052.54]
-queuebot:#ubuntu-release- New sync: linux-meta-gke (bionic-proposed/primary) [4.4.0.1034.35]
-queuebot:#ubuntu-release- New sync: linux-meta-kvm (bionic-proposed/primary) [4.4.0.1019.18]
-queuebot:#ubuntu-release- New sync: linux-kvm (bionic-proposed/primary) [4.4.0-1019.24]
-queuebot:#ubuntu-release- New sync: linux-meta-hwe (bionic-proposed/primary) [4.13.0.36.55]
-queuebot:#ubuntu-release- New sync: linux-meta-azure (bionic-proposed/primary) [4.13.0.1011.12]
<fossfreedom> are we in the middle of transition graphics at the moment in bionic?  both of our ISO builds failed today with a " libgl1-mesa-glx : Conflicts: libgl1"
<acheronuk> fossfreedom: same with kubuntu's
<acheronuk> tjaalton: fallout from the current mesa/everything? ^^
<dpb1> tjaalton: is it appropriate to revert? https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1752481
<ubot5`> Ubuntu bug 1752481 in snapcraft (Ubuntu) "Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35)" [Critical,In progress]
<tjaalton> acheronuk: yes
<tjaalton> dpb1: i'll check
<slangasek> tjaalton: do you know what's going on with images failing to build today due to libgl1-mesa-glx Conflicts: libgl1?  Is that something already fixed in -proposed that needs migrating?
<slangasek> tjaalton: sorry, I see this was the discussion immediately above. :P  anyway, what do I need to do to help fix it?  Get mesa migratable?
<tjaalton> slangasek: yes, the problem is that bionic had an old libglvnd which provides packages for libgl1/libegl1
<slangasek> ok
<tjaalton> and packages that were built in proposed migrated because that version was good enough for them
<tjaalton> i did file a removal bug last august, but it was still there when the migration began, so I closed it and couldn't imagine this would've still been possible...
<tjaalton> anyway, glibc made some tests unhappy (including it's own on s390x)
<slangasek> yeah, I know
<tjaalton> the deps on libegl1/libgl1 also break acceleration on upgrade..
<tjaalton> and login to wayland isn't possible
<tjaalton> because of that
<tjaalton> so, make glibc green/yellow asap ;)
<tjaalton> +please
<slangasek> yes, but that needs analysis of the test failures on s390x
<slangasek> xnox: ^^
<tjaalton> hmm, didn't think of pinging him, we had a look at them with apw
<blackboxsw> plumpcow
<Laney> yummy
<blackboxsw> hah!
<blackboxsw> #ENOSUCHLOGIN
<blackboxsw> slangasek:  I'm adding the verification logs right now to the outstanding SRU regression fix for cloud-init. Just wondering about process for a known user-data affecting SRU regression cherrypick. Does it wait in pending-sru for 7 days or does it publish to updates faster
<slangasek> blackboxsw: it publishes faster if you talk to the SRU team and remind us to pay attention that it's ready
<slangasek> blackboxsw: certainly for targeted fixes for regressions, we don't make them age
<blackboxsw> excellent slangasek, will ping shortly. nearly done w/ verification thanks
<slangasek> LocutusOfBorg: vbox hint updated
<LocutusOfBorg> <3
<LocutusOfBorg> oops it wasn't needed anymore btw, I fixed dkms
<LocutusOfBorg> it will be needed again once the linux folks update their vbox driver
-queuebot:#ubuntu-release- New binary: libmstoolkit [s390x] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [ppc64el] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [amd64] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [i386] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [arm64] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmstoolkit [armhf] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
<slangasek> alright, glibc is now hinted; thanks to everyone who helped sorting through the autopkgtests
<tjaalton> \o/
<slangasek> and adding a 'hint' hint, because update-output is being inscrutable
<slangasek> worked out by chance that libhybris also still needed a no-change upload, so done
<blackboxsw> slangasek: thanks for looking and the cherry pick fix. Just appended all verification logs and updated all necessary cloud-init SRU tags on bug #1752711 and bug #1747059.
<ubot5`> bug 1752711 in cloud-init (Ubuntu Artful) "cloud-init no longer processes user data on GCE in artful" [Critical,Fix committed] https://launchpad.net/bugs/1752711
<ubot5`> bug 1747059 in cloud-init (Ubuntu Xenial) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2-35-gf576b2a2-0ubuntu1~16.04.1" [Medium,Fix committed] https://launchpad.net/bugs/1747059
<blackboxsw> on 1752711 I also added lxd and ec2 integration logs even though the code path changed is strictly limited to GCE datasource only so lxd and ec2 can't even touch this path.
 * tsimonq2 will kick qt* this afternoon, hopefully hard enough to make it migrate
<tjaalton> dpb1: I'm not sure what is asked of the SRU team there
-queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [armhf] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
<nacc> tjaalton: dpb1: i think we'd need to upload a 2.39.3+is+really+2.35 or something
<tjaalton> ah, probably
<Laney> slangasek: tried the hint tester: https://paste.ubuntu.com/p/jdJq7Kk8wH/ - looks like bro needs a rebuild, not sure why it got those upper bounds
<Laney> no time to do it myself, so heads up for you
<Laney> see you
<ScottE> slangasek: Thanks for looking at bug #1752722 - we can validate the fix pretty quickly once it's released or in -proposed
<ubot5`> bug 1752722 in systemd (Ubuntu Bionic) "systemd 237 reports incorrect state when drop-in present" [High,Triaged] https://launchpad.net/bugs/1752722
<xnox> imho, we should not ship libhybris anymore slangasek https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1752953
<ubot5`> Ubuntu bug 1752953 in libhybris (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
<Laney> actually I can do it, my test build finished faster than expected
<Laney> done & see you for realz
<slangasek> Laney: "hint tester"?
<slangasek> ScottE: great, I've got that bug on our list to sort
-queuebot:#ubuntu-release- Unapproved: aptdaemon (artful-proposed/main) [1.1.1+bzr982-0ubuntu17 => 1.1.1+bzr982-0ubuntu17.1] (ubuntu-desktop)
<slangasek> Laney: I thought you had no time to do the upload :)
<slangasek> Laney: ah, you said.  anyway, thanks :)
<slangasek> blackboxsw: so AIUI this was a regression in artful; but in xenial it wasn't, because 17.2-35-gf576b2a2-0ubuntu1~16.04.1 did not get released to -updates yet
<slangasek> blackboxsw: is that correct?
<slangasek> blackboxsw: if it is, I would not release the xenial SRU today (on a Friday, right before everyone travels) without another compelling reason
<smoser> slangasek: you are correct.
<slangasek> ok
<smoser> and i agree with delaying the SRU release. leave it in -proposed and move it on monday is fine.
<smoser> for xenial
-queuebot:#ubuntu-release- New binary: mutter [s390x] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
<xnox> ScottE, are there any other systemd cherry-picks / SRUs that you are expecting, for systemd, e.g. on xenial? at one point it was mentioned to me on telegram, but alas, not much in further details?
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [i386] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [arm64] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
<ddstreet> slangasek if you have time, you feel like approving dpkg upload in trusty?  it's in queue, uploaded by infinity
<ScottE> xnox: I don't think so, but I'll double check
<infinity> tjaalton: That has nothing to do with the failure, and is meant to happen.
<tjaalton> infinity: right, misread the output.. those were skipped anyway
<nacc> dpb1: tjaalton: I'm testing that now (via a side PPA) and will update the bug if so
<ScottE> xnox: The only other systemd bug I'm aware of that affects xenial is bug #1651278 - we applied a local workaround via drop-ins
<ubot5`> bug 1651278 in systemd (Ubuntu) "systemd-sysv-generator does not fully translate facilities to targets" [Undecided,Confirmed] https://launchpad.net/bugs/1651278
<nacc> slangasek: for an SRU regression that's already released, where the fix is to go back to the version that was in xenial-updates before the most recent update, do I need to keep the broken version in the changelog? Or can I go back to the old version, insert a changelog entry like <new-version>+really+is+<old-version> (so that it goes later than it to apt) ?
<infinity> Anyone have context on the ruby-prof regression?
<infinity> slangasek: ^?
<infinity> slangasek: I'm badtesting glibc/s390x, the 4 regressed tests are only in the 31-bit library, and only under certain conditions (note the same tests pass during the build).  I'm not through trying to bisect the how and the why, but I also don't think a few cancel/backtrace tests in a not-really-supported biarch build should hold things up.
<infinity> slangasek: Oh, you already skiptested.  Nevermind, then.
<slangasek> infinity: yeah, the ruby-prof regression was "passed with ruby-defaults in -proposed, then migrated, then newly-failed with -proposed glibc + release ruby-defaults" :P
<infinity> slangasek: Neat.
<slangasek> infinity: oh. these were the bits that you referenced as being 31-bit only?
<slangasek> infinity: had I realized that I think we would've short-circuited that investigation a bit sooner :)
<infinity> slangasek: Yes.  If you read the log more carefully, you'll notice the testsuite failing is the "s390" target.  Thousands of lines up, the native testsuite passes fine.
<slangasek> nacc: no requirement that the SRU fix keep the broken version in the changelog; only requirement is that the versions increase
<slangasek> infinity: ack
<infinity> slangasek: Probably a bit too early for upstream bugs too, but there they are now.  So will follow up there.
<slangasek> ddstreet: I will try to find time to do some SRU processing today, but mostly today is focused on unblocking bionic-proposed wrt feature freeze
<infinity> slangasek: It's quite likely it's not glibc or the kernel immediately at fault, but rather the switch from gcc-6 to gcc-7, though it's clear the kernel is also involved.
<ddstreet> slangasek ack, of course, thnx
<slangasek> dannf: grub2 uploads in the SRU queue> which queue do you mean? I don't see any in {trusty,xenial,artful}-proposed unapproved queue
<dannf> slangasek: xenial - i see them here: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
 * slangasek reads more closely
<slangasek> dannf: found and rejected, thanks
<dannf> slangasek: cool, thx
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (xenial-proposed) [1.66.18]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
<nacc> slangasek: ack, thanks
<slangasek> ok, glibc 2.27 has cleared
<slangasek> and that includes mesa
<nacc> nice
<tjaalton> *phew*
<slangasek> why in the world does an upload of citadel trigger an sbuild autopkgtest?
<slangasek> because mail-transport-agent
<tjaalton> wait, did libglvnd migrate too?
 * slangasek looks askance at this logic
<acheronuk> cleared = migrate?
<slangasek> tjaalton: libglvnd is still stuck because of nvidia-graphics-drivers-390
<slangasek> acheronuk: yes
<tjaalton> ugh
<acheronuk> :D
<acheronuk> oh
<slangasek> tjaalton: but this may be a simple component-mismatch; looking
<slangasek> tjaalton: nope, it's an unsatisfiable dep because libnvidia-{en,de}code-390 don't exist on armhf
<tjaalton> ...
<slangasek> I'll upload the fix
<tjaalton> thanks
<tjaalton> tseliot left
<slangasek> sensible of him
<slangasek> :)
<tjaalton> yeah  :)
<blackboxsw> slangasek: sorry was at lunch. Correct Xenial never published because mid-point-release and then rejected prior to publish. Just artful published. no rush on xenial fix
<blackboxsw> so an artful publish to fix is excellent and we can sort xenial cloud-init next week
<tsimonq2> slangasek: What's a nice color for queued tests in excuses? I like a darker blue. (Let's not bikeshed albeit it's somewhat important in the implementation of bug 1654761).
<ubot5`> bug 1654761 in Auto Package Testing "Use another status for retried but queued items" [Undecided,Confirmed] https://launchpad.net/bugs/1654761
 * tsimonq2 wonders if there's a standard for this, somewhere...
<slangasek> tsimonq2: why would it be a different color than what we already use for 'in progress'?  E.g. we already use the same shade for states IGNORED-FAIL and ALWAYSFAIL
<tsimonq2> slangasek: Good point, let's just do it that way.
<slangasek> tsimonq2: and I think a certain amount of bikeshedding about both the colors and the text is called for here fwiw
<slangasek> the UX of that page is generally terrible, but the UX is still important :)
<tsimonq2> Right :)
<tsimonq2> I've prioritized this fix so expect a fix within a week or less, it's a PITA to not have...
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.12 => 4.2.4-7ubuntu12.13] (core)
<tsimonq2> (Sometimes duplicate tests won't be queued if we know they aren't in the queue, so this fix should come before bug 1686929.)
<ubot5`> bug 1686929 in Auto Package Testing "Duplicate tests can be queued" [Undecided,Confirmed] https://launchpad.net/bugs/1686929
<tsimonq2> s/aren't/are/
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.9 => 4.3.3-5ubuntu12.10] (core)
<tsimonq2> As a side note for that bug, I think it's a good idea to have an override to do duplicate tests justincase but it shouldn't be default. Does anyone oppose?
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (artful-proposed/main) [4.3.5-3ubuntu2.2 => 4.3.5-3ubuntu2.3] (core)
<tsimonq2> Soooo the bug reports live at b.lp.net/auto-package-testing which also has a code repo but that bzr repo shows as deprecated in favor of a git repo which also shows as deprecated in favor of lp:autopkgtest-cloud which is a git repo whose corresponding LP bug tracker isn't set up. I can figure that out, but it's hella weird (unless ofc there's a reason I'm not seeing)...
<tsimonq2> slangasek, Laney ^^^
<slangasek> tsimonq2: it's valuable to have auto-package-testing as a high-level project name for bug reporting; I'm not sure a good way to "reroute" https://code.launchpad.net/auto-package-testing to autopkgtest-cloud
<slangasek> I suppose we could move lp:autopkgtest-cloud to lp:auto-package-testing, maybe
<tsimonq2> That'd be a good idea imho
<tsimonq2> slangasek: Also, why does ~ubuntu-archive own lp:britney but ~ubuntu-release owns Ubuntu's britney2 code? Shouldn't ~ubuntu-release own both?
<slangasek> it's possible ubuntu-archive should own both
<slangasek> because it's code that acts with privileges on the archive
<tsimonq2> Right, but we're talking proposed migration, which imho Release Team territory
<tsimonq2> s/imho/imho is/
<tsimonq2> Yes it gives priviledges, but only to a codebase that just seems to touch proposed migration, not things like upload queues or package removals
<slangasek> tsimonq2: decisions about what to copy are a release team operation.  The privileges with which the code operates to apply those copies are an archive admin acl.
<tsimonq2> slangasek: Correct, but if the decisions on what to copy still lie with the Release Team, and if this group is trusted with those specific rights only indirectly via this tooling, I can see now ~ubuntu-release should still have access
<tsimonq2> s/now/hoe
<tsimonq2> grr
<tsimonq2> s/now/how/
<tsimonq2> that ^
<tsimonq2> *shrug* I'm not a member of either, so not my decision, just my two cents
<blackboxsw> slangasek: thanks for the publish for cloud-init. just validated fix is published and works on GCE/artful
<slangasek> only 1200 autopkgtest regressions reported now... less than half of what was showing yesterday morning.  Nice
<slangasek> stgraber: were you still working on the lx* autopkgtest blockers?
<stgraber> slangasek: yeah, I'm looking at them. I uploaded something that should unblock go-lxc and am looking at the lxcfs failure on s390x (seems to have been around for a while) and on why lxc is hitting timeouts now on all arches
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: nplan (artful-proposed/main) [0.32~17.10.2 => 0.32~17.10.3] (core)
<acheronuk> slangasek: hi. could you look at removing libkolab from bionic please?
<acheronuk> https://bugs.launchpad.net/ubuntu/+source/libkolab/+bug/1752998
<ubot5`> Ubuntu bug 1752998 in libkolab (Ubuntu) "Please remove libkolab from bionic 18.04" [Undecided,New]
<slangasek> acheronuk: reverse-depends tells me this will make the kdepim-runtime package uninstallable; do we need kdepim-runtime to migrate first?
<stgraber> ah, the lxcfs s390x failure is funny, we've seen that on ppc64el before, basically the minimum amount of memory a process requires to get spawned on s390x is much greater than on other arches :)
<stgraber> will add a similar hack as ppc64el then
<acheronuk> slangasek: that will block KDE PIM migration if it stays, and new PIM obsoletes it
<slangasek> acheronuk: how does it block?
<slangasek> really wonder why someone made redis buildable again on i386
<acheronuk> slangasek: it depends on libkf5calendarutils5 libkf5mime5abi1 from PIM 17.08
<acheronuk> The following packages will be REMOVED:
<acheronuk>   libkf5calendarutils5 libkf5mime5abi1 libkolab1
<acheronuk> and libkolab becomes uninstallable
<slangasek> acheronuk: ok; ideally we would do the removal once kdepim-runtime is a candidate
<slangasek> to minimize the number of uninstallables in the release pocket
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.3 => 0.32~16.04.4] (no packageset)
<acheronuk> slangasek: yes. you are right. sorry. end of a long day, and not thinking clearly
<jbicha> slangasek: your nvidia upload didn't work :(
<slangasek> nacc: php7.2 7.2.2-1ubuntu2 blocked by kopanocore tests, claims that php-mapi is uninstallable (?)
<slangasek> acheronuk: no worries
<slangasek> jbicha: oh?
<jbicha> I didn't look closely. I just see it still depends on stuff on armhf
<slangasek> hmm
<nacc> slangasek: i will take a look in amoment
<slangasek> jbicha: debian/control.in <shakes fist>
<slangasek> jbicha: hmm, no, not on this branch. <digs further>
<slangasek> r-base is going to be complicated vs. curl
<slangasek> under the circumstances I'm going to force nvidia-graphics-drivers-390 as-is and fix up armhf after
<slangasek> and found the hidden control.in that was to blame
<tsimonq2> slangasek: Huh, what's up with Britney promoting before the publisher finishes?
<slangasek> tsimonq2: how do you mean?
<acheronuk> [18:15] <infinity> Badness with britney promotions racing the publisher, actually
<tsimonq2> slangasek: It seems mesa et al binaries became available after metadata was updated, failing some qtbase rdep autopkgtests
<tsimonq2> (is "at al." proper or "et al"? *shrug*)
<tsimonq2> s/at/et/
<slangasek> 'et al.'
<acheronuk> the period is important
<slangasek> as for updates, britney and the publisher are both constantly running; britney should in general only be using the published archive as its source of information about things
<slangasek> anything else should probably be considered a bug
<nacc> slangasek: hrm, weird, chdist says it's fine
<tsimonq2> slangasek: et al.>cool, thanks
<acheronuk> had it the other day on an image build. failed as things were migrtating
<acheronuk> tsimonq2: lubuntu I think?
<nacc> slangasek: i'm testing the dep8 itself now (in proposed)
<tsimonq2> acheronuk: prolly, yeah
<slangasek> nacc: sorry, I triggered a retry the same time I posted, it's already passing again ;)
<tsimonq2> acheronuk: If you can hunt down logs (for justification), feel free to assign a bug to me
<nacc> slangasek: ok good!
<acheronuk> ok
<nacc> slangasek: ok, talked to kyrofa and we ahve agreed to revert snapcraft with the version i suggested earlier ... can we get that pushed through (we've got a bug tracking the regressions) if uploaded?
<slangasek> nacc: yah
<nacc> slangasek: LP: #1752481 for context
<ubot5`> Launchpad bug 1752481 in snapcraft (Ubuntu) "Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35)" [Critical,In progress] https://launchpad.net/bugs/1752481
<nacc> slangasek: thanks
<nacc> slangasek: do you have an example changelog verbage for such a regression update?
<slangasek> nacc: not to hand :)
<nacc> slangasek: np, i can make something up :)
<nacc> slangasek: version should be '2.39.3+is+really+2.35' iiuc?
<nacc> (where 2.39.3 is what is currently in x-p/x-u and 2.35 is the version we're going back to)
<cjwatson> 2.39.3+really2.35 would be a bit more usual
 * slangasek stabs r-cran-curl in the bits
<slangasek> nvidia-390 through the gauntlet
<nacc> cjwatson: ack, i can do that instead
<dx> hi! is it too late in the 18.04 cycle to request removal of an unstable/insecure package imported from debian?
<dx> if not, what do i file bugs against?
<nacc> dx: against the source pacakge
<slangasek> dx: no; the process is to file a bug against the package and subscribe the ubuntu-archive team
<dx> thank you
<slangasek> dx: if you care to mention here what the package is, we can also discuss
<dx> sure. it's "xchat", see this post by the hexchat dev: https://tingping.github.io/2018/03/02/when-distros-get-it-wrong.html
<dx> (my plan was to fuzz it for 5 minutes to have some concrete evidence that it's insecure)
<slangasek> dx: that would be useful; a much stronger statement than "it's insecure, believe us", given that /most/ software has undisclosed vulnerabilities
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.39.3 => 2.39.3+really2.35] (no packageset)
<nacc> slangasek: --^ fyi
<slangasek> statistically speaking, R is indistinguishable from nodejs
#ubuntu-release 2018-03-03
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.39.3+really2.35]
<bluesabre> Hello! Xubuntu is interested in adding a new custom action for printing from Thunar. This is a super low risk addition, but we wanted to go ahead and apply for FFe. https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1753015 Thanks!
<ubot5`> Ubuntu bug 1753015 in xubuntu-default-settings (Ubuntu) "[FFe] Add thunar custom action to directly print certain file types" [Undecided,New]
<slangasek> nacc: snapcraft accepted; will you test it and let me know when to publish?
<slangasek> ah lovely, these R packages have failing autopkgtests largely because they manually override the locale to C instead of C.UTF-8
<acheronuk> tsimonq2: I think all or nearly all Qt should be a candidate (in that grouping) now or soon
<tsimonq2> acheronuk: nice!
 * acheronuk hands baton to tsimonq2 
 * tsimonq2 grabs the baton and drop kicks Qt, hopefully pushing it through
-queuebot:#ubuntu-release- New binary: evolution-data-server [s390x] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [ppc64el] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [amd64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [i386] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
<acheronuk> tsimonq2: think you may need an extra large crowbar
<acheronuk> night
<tsimonq2> acheronuk: true
<tsimonq2> night
-queuebot:#ubuntu-release- New binary: evolution-data-server [arm64] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [armhf] (bionic-proposed/main) [3.27.90-1ubuntu1] (ubuntu-desktop)
<stgraber> ok, mostly done unstick the lxc/lxcfs/lxd mess
<stgraber> lxc should be good to go, just waiting for some more retries and hints to take effect, once it lands, it'll unstick go-lxc which can land too, lxd should soon yield enough green to get go-defaults unblocked too
<stgraber> we may still be stuck with lxd in proposed because of an odd s390x failure that I can't reproduce (but I uploaded a new LXD which should give us better logs)
<stgraber> I may have triggered some of the same stuff as slangasek though, looks like I'm not alone trying to get stuff to migrate :)
<stgraber> stepping away for a bit, I'll come back to check on the new LXD test results in a bit, if they're good enough, I'll let lxd out (might have to badtest s390x), which will unblock lxc and go, lxc will unblock go-lxc
<nacc> slangasek: i will try, it's a straight revert
<slangasek> stgraber: right, autopkgtest queue remains empty, we should retry anything we can that might stick ;)
<slangasek> nacc: yes, so testing is mostly to guard against the possibility of a misbuild
<stgraber> ok, I think I have an idea of where the race may be in the lxd test, pushing a tentative fix now
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-default-settings (xenial-proposed/universe) [1.3.14 => 1.3.14ubuntu0.1] (ubuntukylin)
<nacc> slangasek: ack, understood
<acheronuk> morning. Qt seems all a candidate. KDE PIM seems so as well. I know removal of libkolab blocks PIM partially, and some/most is also blocked on Qt for akonadi
<acheronuk> any help deciphering update_output.txt is welcome
<acheronuk> tsimonq2: no luck doing that?
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [amd64] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [s390x] (bionic-proposed) [1.13.1-1ubuntu1]
<slangasek> acheronuk: ^^ that will help KDE be migratable (via the libvpx transition in progress)
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [arm64] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [i386] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [armhf] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-good1.0 [ppc64el] (bionic-proposed) [1.13.1-1ubuntu1]
<acheronuk> slangasek: thanks. I figured that gstreamer was in the mix
<acheronuk> now I have to made digikam not FTBFS with glibc 2.27 :/
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [s390x] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
<jbicha> slangasek: since you're here, do you have time to review mutter & evolution-data-server so that we can complete those transitions?
<stgraber> ok, asked for some retries on python3-lxc which should unblock it as well as lxc-templates, go-lxc and lxc
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [amd64] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [ppc64el] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [i386] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [arm64] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: gst-plugins-bad1.0 [armhf] (bionic-proposed/universe) [1.13.1-1ubuntu1] (ubuntustudio)
<LocutusOfBorg> anybody from Release Team: since freeipa is broken, out from debian testing, and the autopkgtestsuite sucks ( tjaalton  will have a look), can we please kick it out to proposed, to make libunistring go ahead a little bit?
<LocutusOfBorg> nobody answered in https://bugzilla.gnome.org/show_bug.cgi?id=793723 and https://bugzilla.gnome.org/show_bug.cgi?id=793724 so I'll take the hammer and upload a tracker package with that test fixed/disabled
<ubot5`> Gnome bug 793723 in Tests "testsuite broken in 2.0.3 (regression since 2.0.1)" [Normal,New]
<ubot5`> Gnome bug 793724 in Tests "testsuite broken in 2.0.3 with new libunistring 0.9.8" [Normal,New]
<LocutusOfBorg> testsuite sucks a lot
<slangasek> jbicha: sorry, only intermittently here, heading to airport in 2h
<slangasek> LocutusOfBorg: yes, I will be demoting freeipa to -proposed as necessary to unblock things
<slangasek> LocutusOfBorg: but the real blocker for libunistring is that it regresses tracker
<jbicha> slangasek: I understand. Stay safe (and warm!)
<LocutusOfBorg> slangasek, the output of a test is swapped, I don't think this is a real issue
<LocutusOfBorg> I mean, nothing is dropper or added, I'll upload a test swapped tracker
<slangasek> LocutusOfBorg: it absolutely is an issue, collation order is *broken*
<slangasek> LocutusOfBorg: the test in question is a sorting test
<LocutusOfBorg> mmm bug in unistring?
<slangasek> I believe so; and I have tried to bisect, and that led me into gnulib
<slangasek> which is a terrible pain to bisect because it's a submodule and half of the stuff in the tarball is generated output
<LocutusOfBorg> slangasek, there is a new libunistring out
<LocutusOfBorg> let me upload in a ppa
<slangasek> ok
<LocutusOfBorg> did you already tried it?
 * tsimonq2 stretches and walks towards Qt with the sledgehammer
<LocutusOfBorg> my whole time has been dedicated in fixing/testing virtualbox/xenial, I slowed down everything else...
<slangasek> LocutusOfBorg: no, I haven't looked for new unistring
<LocutusOfBorg> (it wasn't out when I syncd it, maybe they got some bug reports and fixed it)
<LocutusOfBorg> seems just translation updates...
<LocutusOfBorg> wait: [18:50:02] <slangasek> I believe so; and I have tried to bisect, and that led me into gnulib
<LocutusOfBorg> oh... the change in 0.9.9 is gnulib
<LocutusOfBorg> +       Update after gnulib changed.
<LocutusOfBorg> +       * NEWS: Mention the multithread-safety fix from gnulib module 'malloca'.
<stgraber> slangasek: hey, can you make any sense of what's going on with lxc, lxc-templates, python3-lxc and go-lxc in -proposed?
<stgraber> slangasek: all tests are green or were hinted to go through but it's not migrating
<stgraber> slangasek: update_output.txt seems to be unhappy with binaries on one of the arches (was s390x last run, now arm64) but a test on a system with -proposed shows them as installable AFAICT...
<LocutusOfBorg> slangasek, libunistring 0.9.9 seems to fix the issue, uploaded
<LocutusOfBorg> processing something from new queue might make things go in release, e.g. libmstoolkit (new package, nothing really interesting, no rdeps, leaf tools binary package)
<LocutusOfBorg> sil2100 AFK?
<LocutusOfBorg> I stole a ppp merge from him, I hope he will forgive me
<LocutusOfBorg> node-rollup needs really a bootstrap, but I failed :/
<tjaalton> freeipa; it's fine to drop for now, I'll decide soon if the server is worth keeping or not, client is easy to keep
-queuebot:#ubuntu-release- New: accepted gosa [sync] (bionic-proposed) [2.7.4+reloaded3-2]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [amd64] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [armhf] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [ppc64el] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [arm64] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [s390x] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libmstoolkit [i386] (bionic-proposed) [82-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [amd64] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [armhf] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [ppc64el] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [arm64] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [s390x] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mate-menus [i386] (bionic-proposed) [1.20.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: gosa [amd64] (bionic-proposed/none) [2.7.4+reloaded3-2] (no packageset)
<Laney> slangasek: ctrl-r for --hint-tester as ubuntu-archive@snakefruit
<slangasek> Laney: ah.  sounds like something that would be useful to be able to run locally and not impose further load on snakefruit :)
<slangasek> Laney: btw, I raised an MP on britney2, about pruning update_excuses.yaml... I think it'll make retry-autopkgtest-regressions et al a bit speedier for not having to parse/load a bunch of redundant text, do you have time to take a look? https://code.launchpad.net/~vorlon/britney/+git/britney2-ubuntu/+merge/340556
<Laney> slangasek: not right now, but I'll look soon, thanks!
<slangasek> Laney: ok cool
 * slangasek works through the binary NEW queue, to see how close we are on qt
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (bionic-proposed) [3.27.91-1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [amd64] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [armhf] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [ppc64el] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [arm64] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [s390x] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gst-plugins-bad1.0 [i386] (bionic-proposed) [1.13.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [amd64] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [armhf] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [ppc64el] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [arm64] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [s390x] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [i386] (bionic-proposed) [3.27.90-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gosa [amd64] (bionic-proposed) [2.7.4+reloaded3-2]
<slangasek> LocutusOfBorg: where do you see that libunistring 0.9.9 fixes things? because tracker autopkgtests are still failing
<slangasek> LocutusOfBorg: exact same test failing as before
<LocutusOfBorg> slangasek, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-costamagnagianfranco-locutusofborg-ppa/bionic/ppc64el/t/tracker/20180303_184929_a0241@/log.gz
<LocutusOfBorg> let me see
<LocutusOfBorg> slangasek, I no-change rebuilt tracker against new libunistring, this is the only thing that changed
<slangasek> LocutusOfBorg: right, I was noticing that and wondering if it made a difference.  I certainly saw differences in behavior here w/ tracker depending on whether or not I rebuilt
<LocutusOfBorg> can I no-change rebuild?
<slangasek> sure
<LocutusOfBorg> let me meld the two tests before, just to spot different versions of dependencies
<LocutusOfBorg> no differences in packages installed, so no-change rebuilding
<LocutusOfBorg> I also sent an email to the libunistring debian maintainer, asking to update
<LocutusOfBorg> how should we deal with this? isn't an ABI break? shouldn't we rebuild everything again against libunistring?
 * LocutusOfBorg is always confused by this stuff
<slangasek> LocutusOfBorg: I wouldn't consider it an ABI break, but perhaps there are other rev deps that are misbuilt which just didn't notice because they don't have tests for it
<slangasek> maybe we should just rebuild all the revdeps after confirming that tracker is fixed
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [source] (bionic-proposed) [1.1.5-0ubuntu1]
<LocutusOfBorg> I think I will
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [s390x] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [i386] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [ppc64el] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
 * LocutusOfBorg goes afk
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [amd64] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [arm64] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-settings-daemon [armhf] (bionic-proposed/none) [1.1.5-0ubuntu1] (no packageset)
<LocutusOfBorg> slangasek, don't forget to kick out freeipa :)
<tsimonq2> Thanks to whoever reviewed ukui-settings-daemon
#ubuntu-release 2018-03-04
<slangasek> LocutusOfBorg: indeed
<acheronuk> gst-plugins-good1.0 is a sticking point now?
<slangasek> evidently
<slangasek> Laney: there appear to be some MIRs needed to make gst-plugins-good1.0 ok
<slangasek> Laney: and/or dropped dependencies
<acheronuk> slangasek: by the way, if you set LB_BOOTSTRAP_INCLUDE=-gnupg before invoking live-build, will it pick up that up and include in back in a base image?
<slangasek> acheronuk: I don't know that it works via env vars passed to live-build; but in any event, why would you want gnupg as part of a bootstrap build?
<acheronuk> taking it out from live-build may have made Kubuntu CI image build to fail
<acheronuk> 22:17:29 P: Configuring file /etc/apt/sources.list
<acheronuk> 22:17:29 deb http://ppa.launchpad.net/kubuntu-ci/stable/ubuntu bionic main
<acheronuk> 22:17:29 E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
<acheronuk> anyway, not a -release thing so I'll leave that alone now
<slangasek> hmm
<slangasek> why does it require those packages, as opposed to gpgv?
<acheronuk> seems to be the point where our CI ppa is getting added. I'll need to did down tomorrow to try to see what it's doing
<acheronuk> *dig down
<slangasek> LocutusOfBorg: same tracker autopkgtest failure....
<slangasek> nacc: gosa-dev depends on php7.0-cli?
<acheronuk> slangasek: apt-key looks for gnupg, gnupg2 and gnupg1 in its prepare_gpg_home(), and exits with that error without setting the gpg executable if it doesnt find any of those
<acheronuk> I *think*
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [amd64] (bionic-proposed) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [i386] (bionic-proposed) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [s390x] (bionic-proposed) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [arm64] (bionic-proposed) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [ppc64el] (bionic-proposed) [1.1.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-settings-daemon [armhf] (bionic-proposed) [1.1.5-0ubuntu1]
<slangasek> acheronuk: ah, I see.  then yeah, gpgv is not a substitute for those
<slangasek> ginggs: why the lazarus sync, given the FTBFS on armhf?
<acheronuk> slangasek: I guess live-build only trips when invoking apt-key add in lb_chroot_archives chroot install to add an external source, which ubuntu main isos never do
<acheronuk> anyway. I'll have to look at this tomorrow. good night all
<acheronuk> thanks for assistance with Qt/KDE
<slangasek> ah? so live-build assumes gpg is part of present in the bootstrapped set? hmm
-queuebot:#ubuntu-release- New: accepted ukui-media [source] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-media [ppc64el] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-media [s390x] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-media [amd64] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-media [i386] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-media [arm64] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-media [armhf] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
<jbicha> slangasek: please remove gnome-calendar from bionic-proposed. We need to rebuild 3.26 for e-d-s transition (3.27 adds a libdazzle dep but the MIR hasn't been approved yet)
<slangasek> jbicha: done
-queuebot:#ubuntu-release- New: accepted dptfxtract [source] (bionic-proposed) [1.2-0ubuntu1]
<jbicha> thanks :)
-queuebot:#ubuntu-release- New: accepted ukui-media [amd64] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-media [ppc64el] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: dptfxtract [amd64] (bionic-proposed/none) [1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-media [i386] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-media [s390x] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-media [arm64] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-media [armhf] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [source] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ippsample [amd64] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ippsample [ppc64el] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ippsample [i386] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ippsample [s390x] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ippsample [arm64] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ippsample [armhf] (bionic-proposed/none) [0.0+20180213-0ubuntu1] (no packageset)
<slangasek> LocutusOfBorg: right, tracker looks mostly good, except for the bit where it coredumps on arm64 in its tests
-queuebot:#ubuntu-release- New: accepted ippsample [amd64] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [i386] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [s390x] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [arm64] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [ppc64el] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ippsample [armhf] (bionic-proposed) [0.0+20180213-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [source] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [i386] (bionic-proposed/none) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [s390x] (bionic-proposed/none) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [ppc64el] (bionic-proposed/none) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [i386] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [s390x] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [ppc64el] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [arm64] (bionic-proposed/universe) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [armhf] (bionic-proposed/universe) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-themes-extra [amd64] (bionic-proposed/universe) [3.27.90.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [source] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-power-manager [i386] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-power-manager [s390x] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-power-manager [ppc64el] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-power-manager [arm64] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-power-manager [armhf] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-power-manager [amd64] (bionic-proposed/universe) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [amd64] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [armhf] (bionic-proposed) [3.27.90.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-themes-extra [arm64] (bionic-proposed) [3.27.90.1-1ubuntu1]
<jbicha> I don't understand why the evolution-data-server/mutter transition is stuck
<jbicha> mutter has these parts: mutter, gnome-shell, gnome-shell-extensions, budgie-desktop
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/evolution-data-server.html
<jbicha> maybe it all needs to be hinted together?
<slangasek> gstreamer-vaapi is going to need some fixing for 32-bit archs; probably a straightforward fix but I'm not in a position to look right now (bandwidth-constrained)
<slangasek> jbicha: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt shows mutter+eds going in together, but syncevolution-libs-gnome and gnome metapackages become uninstallable
<slangasek> jbicha: does that match what you're looking at?
<slangasek> jbicha: ok, looks like I should refresh again :)
<slangasek> jbicha: so, now it's just meta-gnome for whatever reason
<jbicha> vanilla-gnome-desktop comes from a different source package but same thing
<slangasek> jbicha: will having new meta-gnome3 help?  gnome-themes-extra is accepted now, though in universe; I guess it'll need promoting
<jbicha> my theory is that britney doesn't like doing too much at one time and I should have been more patient and not done two transitions at once
<jbicha> and I think hinting it all together will help
<jbicha> the gnome metapackages don't have such strict dependencies themselves
<slangasek> britney certainly has handled much larger transitions than this
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [i386] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [s390x] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [ppc64el] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [amd64] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [armhf] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-power-manager [arm64] (bionic-proposed) [1.1.1-0ubuntu1]
<jbicha> gnome-shell-extensions has depends gnome-shell >= 3.27, gnome-shell << 3.28 which should be fine here
<jbicha> gnome-shell-extensions shows up below "Apparently successful"
<jbicha> g-s-extensions also shows in the same "trying easy from autohinter" section. I think it's odd to show up in the 2 different parts like that
<slangasek> ah
<slangasek> https://paste.ubuntu.com/p/ptG7jVTcnj/
<slangasek> this seems to show that gnome-core is broken only on s390x?
<slangasek> the "a-11:[...]" shows the uninstallable count for each architecture, and only s390x has increased
<jbicha> oh I just ignored those funny letters and numbers :)
<jbicha> s390x shouldn't have a problem though. I intentionally added a |epiphany-browser as an alternate for meta-gnome3's browser dependency a year or so ago
<jbicha> I'm unaware of any other relevant s390x uninstallability problem
<jbicha> refresh the page and the top part changes to i386 (in other words, I don't think it's s390x's fault)
<slangasek> jbicha: ok well, adding it as an explicit hint doesn't get any farther, it still shows the same output.  Someone will have to analyze why updating this particular set of packages makes gnome-core uninstallable
<acheronuk> some KDE movement :)
<acheronuk> slangasek: thank you
<acheronuk> slangasek: why did britney let kmail migrate without it's dependencies?
<acheronuk> https://paste.ubuntu.com/p/NDYJdkfVJm/
<acheronuk> depends libkf5akonadicore5abi1 (>= 4:17.11.60+git20171017.0359)
<acheronuk> yet britney let it migrate to release, with 17.08.3 version
<Laney> slangasek: yeah I know, I'm going to file them imminently
<Laney> maybe tomorrow :-)
<Laney> I had a draft in gedit and lost it after a suspend failure :'(
<Laney> resume*
<jbicha> slangasek: I figured out my mistake for the mutter transition: http://launchpadlibrarian.net/359439534/gnome-shell-extensions_3.27.91-1_3.27.91-1ubuntu1.diff.gz
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8] (core)
<nacc> slangasek: if so that would be an oversight by debian, i'll get it fixed
<nacc> slangasek: looks to just have been missed by debian, i'll fix and submittodebian
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8]
#ubuntu-release 2019-02-25
<doko> vorlon: the hello autopkg test was meant to replace the libreoffice autopkg test trigger
<vorlon> doko: ok, and it's buggy; do you want to fix it?
<doko> vorlon: so the correct fix would be to detect the 77 exit status, and then fail in the end with this?
<doko> and likely allowing stderr
-queuebot:#ubuntu-release- Unapproved: chromium-browser (cosmic-proposed/universe) [71.0.3578.98-0ubuntu0.18.10.1 => 72.0.3626.119-0ubuntu0.18.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected libunistring [source] (bionic-proposed) [0.9.10-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-fortisslvpn [source] (bionic-proposed) [1.2.8-1ubuntu1]
<Riddell> libxcb update uploaded again should anyone be doing New/SRU queue review https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1777994
<ubot5> Launchpad bug 1777994 in libxcb (Ubuntu Bionic) "the header xcb/xinput.h is missing" [Low,Fix committed]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.10]
<cpaelzer> thanks
<Odd_Bloke> Still looking for a quick hints merge on https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 if anyone has a minute.
<Odd_Bloke> (The current version of Vagrant in the release pocket doesn't work with the Virtualbox in the release pocket, which is why I'm keen to get this migrated.)
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.1]
<cpaelzer> sil2100: hi thanks for releasing libpam-mount for bug 1804408 on cosmic
<ubot5> bug 1804408 in Ubuntu on IBM z Systems "[19.04 FEAT] LUKS2 support for pam_mount" [High,In progress] https://launchpad.net/bugs/1804408
<cpaelzer> sil2100: I wonder where the bionic variant of it got lost thou
<cpaelzer> I uploaded on the same day, and it was blocked for the 18.04.2 semi-freeze
<cpaelzer> but the release of the SUR for cosmic made me re-check and I can't see it in B-proposed nor b-unapproved
<cpaelzer> sil2100: I wonder if from the SRU-masters POV you have an idea what happened
<cpaelzer> I see no accept/denial nor anything similar
<cpaelzer> I'll also double check that I uploaded it back then ....
<cpaelzer> Feb  7 17:15 libpam-mount_2.16-3ubuntu0.1_source.ubuntu.upload
<cpaelzer> yeah sucessfully uploaded at the same time as the cosmic version (2.16-5ubuntu0.1)
<sil2100> cpaelzer: let me finish one review and try to investigate
<cpaelzer> sure
<cpaelzer> In case "just re-upload it" is an option I can easily do so, but usually if things get lost it is worth to check why :-)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.1]
<sil2100> cpaelzer: oh, I see it in the Unapproved queue
<sil2100> cpaelzer: I'll review it now
<cpaelzer> sil2100: stop the "investigation" it is just that the bionic queue is 42 entries long, I'm at #32 and the default view on LP limits to 30 results
<sil2100> Probably you didn't see it as it was on the second page ;)
<sil2100> Yeah
-queuebot:#ubuntu-release- Unapproved: accepted libpam-mount [source] (bionic-proposed) [2.16-3ubuntu0.1]
<sil2100> cpaelzer: done ^
<cpaelzer> Thank you sil2100
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1012.12~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1012.12~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1012.12] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1012.12]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1040.44] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1040.44]
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 => 2.7.15-4ubuntu4~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1] (openstack, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 => 3.7.2-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 => 2.0.9-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 => 1.84-1ubuntu0.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 => 1.0.1-1ubuntu1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 => 2.1.4-1ubuntu1.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
<juliank> Laney, sil2100, vorlon Should we add any other fields to the autopkgtest journals? I'm not sure what we could be interested in. We could tag failing result logs by exit code, for example
<juliank> Then we could do queries by exit code
<juliank> but it would only show results, and miss the head of the run
<juliank> I feel like we should have a common word we can all configure highlights on, so people can ping about autopkgtest stuff
<infinity> juliank: Jabberwocky.
<juliank> infinity: i don't like
<juliank> I thought @adt but that's too obscure
<xnox> argggg
<xnox> g
<xnox> used wrong from email again
<xnox> oh, i am subscribed
<infinity> juliank: https://www.youtube.com/watch?v=spyJ5yxTfas
<xnox> ah
<xnox> The reason it is being held:
<xnox>     Too many recipients to the message
<xnox> infinity, if you please moderate that email?! =)
<infinity> xnox: ... to?
<Laney> juliank: cloud region would be good
<xnox> infinity,     https://lists.ubuntu.com/mailman/confirm/ubuntu-release/3cbf130433d6a020d9b281155971e932f36bcb74 ubuntu-release mailing list
<xnox> infinity, but that's my post/no-post url....
<infinity> xnox: The name of the list would have been enough. :P
<xnox> ah
 * xnox is mailman failure
 * Laney tries... to... resist...
<Laney> s/mailman //
<Laney> sorry :(
<juliank> Laney: OK, but we can query for that by limiting on the @<cloud>*.service already, so it doesn ot at
<juliank> but that applies to arch too, so...
<juliank> We could also differentiate between upstream tests and ubuntu and huge queue tests
<juliank> I have no idea how much space this eats
<juliank> Gotta read up on the journal format :)
<xnox> infinity, also, what did i just watch?!!!!!!!
<infinity> xnox: Jabberwocky!  You don't know what it is?
<Laney> juliank: the journal is supposed to auto prune anyway, so I wouldn't worry about that
<Laney> although it did stop doing that and fill up the disk the other day ...
<juliank> +1
<xnox> infinity, no idea
<xnox> https://www.youtube.com/watch?v=WQVFe8TbFi4 -> this is now on autoplay
<infinity> xnox: (That's the joke)
<xnox> i'm confused what the show is
<Laney> it might be nice to make the other scripts log to the journal too, with some nice metadata
<infinity> The show is Better off Ted.  Some of the better TV ever written.
<Laney> the maintenance job / the daily image building / ...
<xnox> wait is that the 6 parallel / perpendicular lines, with weird colors?!
<xnox> ah
<Laney> interesting interleaving of conversations, here
<xnox> it's unrelated, but added this on autoplay https://www.youtube.com/watch?v=BKorP55Aqvg
<juliank> Laney: FWIW, I just removed the attached card you wanted access to. It was the card for scheduling our session
<Laney> ok
<juliank> it was only supposed to link from "schedule session" -> "https://trello.com/c/wvz1NPzD/26-adding-a-second-cloud-worker" but trello said it would recommended bidirectional ...
<vorlon> doko: if it's exit status 77, we shouldn't fail, based on the definition of the upstream test
<vorlon> doko: autopkgtest doesn't honor exit status 77, that's (apparently?) an automake thing
<tsimonq2> vorlon: css> ack
<ginggs> vorlon, doko: any ideas about pandas test regression on ppc64el? ../../../usr/lib/python2.7/dist-packages/pandas/tests/series/test_analytics.py::TestSeriesAnalytics::test_sum_overflow[True] Killed
<ginggs> same test passes during the build
<mwhudson> ginggs: oom?
<ginggs> mwhudson: could be, thanks - how can i prove, or avoid that?
<mwhudson> ginggs: no idea to be honest
<mwhudson> ginggs: you can mark a package as "big" which means its tests run in a vm with more ram
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (cosmic-proposed/main) [3.30.2-0ubuntu1 => 3.30.2.1-0ubuntu1] (ubuntu-desktop)
<tumbleweed> vorlon: looks like reverse-depends has been broken since the 9th. Looking at it...
<tsimonq2> Laney: Looking at bug 1654761 again, new code up at https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/363643
<ubot5> bug 1654761 in Auto Package Testing "Make sure duplicate tests cannot be queued" [Undecided,In progress] https://launchpad.net/bugs/1654761
<tsimonq2> I think I have a much better grasp of the situation this time around (and my programming skills have improved :P)
#ubuntu-release 2019-02-26
<tumbleweed> vorlon: and, should be running again. ubuntuwire was a little short of disk space
<vorlon> tumbleweed: ta
<vorlon> ginggs: I can reproduce the pandas failure, will try to isolate
<ginggs> vorlon: thanks. i tried reducing the size of the arange, and have just triggered the tests
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
<ginggs> vorlon: that didn't work :( i have a tested patch to disable only the failing test, only on python2 and only on ppc64el, which does the trick (nothing else fails) - shall i upload that so long?
<vorlon> ginggs: well, it is definitely an oom.  I think I should probably dig a little further to see why it ooms, as that might be real bug
<ginggs> vorlon: ack
<vorlon> ginggs: oh but it's only an oom with python2, isn't it, could we skip the test on python2 but not python3?
<vorlon> ginggs: ah you said that already - yeah, I think you should upload
<vorlon> whatever's going on seems to be a memory leak though, because running that test on its own doesn't trigger it
-queuebot:#ubuntu-release- New source: libsodium (trusty-proposed/primary) [1.0.8-5~ubuntu14.04.1]
-queuebot:#ubuntu-release- New source: python-libnacl (trusty-proposed/primary) [1.4.5-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- New source: pymacaroons (trusty-proposed/primary) [0.9.2-0ubuntu1~ubuntu14.04.1]
<ginggs> vorlon: yeah can skip on py2 only. uploading shortly
<juliank> livecd-rootfs 3.566 just landed in disco. builds using it will see direct dependencies of ubiquity not marked as automatically anymore
<juliank> in an attempt to fix #1801629
<vorlon> ginggs: and if I run the testsuite under valgrind, it uses ridiculous amounts of memory just to collect the tests without ever running them, so I think ignoring is the right answer
<ginggs> vorlon: ack
<vorlon> I do wonder if this is a memory leak in pandas however, since memory usage creeps up over time while running the other tests (when not under valgrind)
 * vorlon checks memory usage under python3
<vorlon> similar behavior under python3, it just manages not to hit the ceiling
<vorlon> ginggs: do you want to check if memory grows over time on other archS?
<ginggs> vorlon: sure, i can check amd64 now
<LocutusOfBorg> sorry for the nodejs rebuild, but I discovered an unicode bug, I'm doing some rebuilds to be sure rollup is now correctly bootstrapped
<LocutusOfBorg> we were not correctly building node-unicode, that has been an hack to bootstrap acorn/rollup, and now we should remove that hack...
<ginggs> vorlon: memory usage grows over time on amd64, but only by about 1.1GB - how much are you seeing?
-queuebot:#ubuntu-release- Unapproved: gettext (bionic-proposed/main) [0.19.8.1-6ubuntu0.1 => 0.19.8.1-6ubuntu0.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: insubstantial (bionic-proposed/universe) [7.3+dfsg3-3 => 7.3+dfsg3-4~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: java-common (bionic-proposed/main) [0.63ubuntu1~02 => 0.68ubuntu1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: javatools (bionic-proposed/universe) [0.63ubuntu1 => 0.72.1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jnr-posix (bionic-proposed/universe) [3.0.42-1 => 3.0.45-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jruby (bionic-proposed/universe) [9.1.13.0-1 => 9.1.17.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jython (bionic-proposed/universe) [2.7.1+repack-3 => 2.7.1+repack-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libgpars-groovy-java (bionic-proposed/universe) [1.2.1-7 => 1.2.1-10~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: logback (bionic-proposed/universe) [1:1.2.3-2 => 1:1.2.3-2ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-javadoc-plugin (bionic-proposed/universe) [3.0.0-4 => 3.0.1-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: openjdk-11-jre-dcevm (bionic-proposed/primary) [11.0.1+8-1~18.04]
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.2+13-1ubuntu0.18.04.4 => 11.0.2+9-3ubuntu1~18.04.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: openjfx (bionic-proposed/universe) [8u161-b12-1ubuntu2 => 11.0.2+1-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: saaj (bionic-proposed/primary) [1.4.0-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: scala (bionic-proposed/universe) [2.11.12-2 => 2.11.12-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gettext [sync] (bionic-proposed) [0.19.8.1-6ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted insubstantial [sync] (bionic-proposed) [7.3+dfsg3-4~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted java-common [sync] (bionic-proposed) [0.68ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted javatools [sync] (bionic-proposed) [0.72.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted jnr-posix [sync] (bionic-proposed) [3.0.45-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jruby [sync] (bionic-proposed) [9.1.17.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jython [sync] (bionic-proposed) [2.7.1+repack-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libgpars-groovy-java [sync] (bionic-proposed) [1.2.1-10~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted logback [sync] (bionic-proposed) [1:1.2.3-2ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maven-javadoc-plugin [sync] (bionic-proposed) [3.0.1-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (bionic-proposed) [11.0.2+1-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted scala [sync] (bionic-proposed) [2.11.12-4~18.04]
<jibel> willcooke, sil2100 bug 1817689
<ubot5> bug 1817689 in ubiquity (Ubuntu) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Undecided,New] https://launchpad.net/bugs/1817689
-queuebot:#ubuntu-release- New: accepted openjdk-11-jre-dcevm [sync] (bionic-proposed) [11.0.1+8-1~18.04]
<jibel> reproduced on both archs
<willcooke> jibel, my install just finished, and I *can* log in
<willcooke> lemme read the bug, make sure I did it right
<willcooke> yeah, that's what I did
<willcooke> jibel, did you install in French?
<willcooke> I will try a different language
<sil2100> ugh
-queuebot:#ubuntu-release- New: accepted saaj [sync] (bionic-proposed) [1.4.0-3~18.04.1]
<jibel> willcooke, 16.04.6 ?
<jibel> http://cdimage.ubuntu.com/xenial/daily-live/20190222/
<willcooke> jibel, yeah, md5 matches
<jibel> I did an installation in english
<willcooke> jibel, uefi?
<jibel> no, bios in a vm
<jibel> i'll try on bare metal
<sil2100> jibel: can you also try .5 later?
<sil2100> I'll try to reproduce here
<jibel> sure
<willcooke> jibel, 2nd install on metal - worked
<jibel> well, 2 install and both failed
<willcooke> As you might expect, I'm doing my testing on the haunted laptop
<sil2100> I seem to be able to reproduce it here
<sil2100> The system boots but on the login screen I can't log into my user
<jibel> sil2100, switch to a tty, log in and check if there are permission denied in the journal
<willcooke> sil2100, on a vm?
<sil2100> willcooke: yeah, kvm
 * willcooke tries on vbox
<sil2100> jibel: yes, the same error as you have
<willcooke> meh, I can't recreate on vbox either
<willcooke> what password are you using for encrypting the disk?
<sil2100> willcooke: so you have ecryptfs home working?
<sil2100> willcooke: it's not about disk encryption, but home encryption if anything
<willcooke> ohhhhhh
<willcooke> man
<willcooke> I cant read
<jibel> at least now we know that disk encryption is working ;)
<willcooke> Let's try that again
<willcooke> jibel, ha
<sil2100> hm, changing file owner didn't help either
<sil2100> After changing the owner of .ecryptfs, I'm getting "No such file or directory" errors while detecting wrapped passphrase version
 * jibel syncs 16.04.5
<sil2100> I do see pam_kwallet*.so load errors earlier
<sil2100> Maybe those are somehow needed for that?
<sil2100> Anyway, I need to go prep lunch now, will dig in further when back
<willcooke> jibel, so are you doing a "something else" install, creating a /home and then encrypting that (and using lvm)?
<jibel> willcooke, no, you select 'install ubuntu on entire disk' then in the 'Who are you' page, you check 'encrypt home'
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.3-0ubuntu0.18.04.1 => 2.56.4-0ubuntu0.18.04.1] (core)
<willcooke> jibel, gotit
<willcooke> thx
<jibel> then it uses ecryptfs to encrypt $HOME
<jibel> and this is a reproducible on hw so not a problem of vm vs hw
<willcooke> jibel, ok, yeah, confirmed on vbox and real hardware. Sorry for the confusion
<jibel> Thanks for the confirmation, I should have make the test case more clear
<jibel> sil2100, it's a regression in 16.04.6.
<didrocks> (confirmed as well)
<jibel> what would be a release without a respin
<didrocks> that's where the fun is, obviously :)
<jibel> I actually feel frustrated when I don't find a bug that requires a respin ;)
<didrocks> maybe it's all done on purpose then! :)
<didrocks> people care of you being happy :p
<sil2100> :|
<Laney> I can help on that bug if people want (will be back in 1 hour ish)
<sil2100> I'm back now so I'll try looking into this a bit more
<jibel> sil2100, there is this in the logs
<jibel> Feb 26 10:58:21 ubuntu user-setup: Error: Your kernel does not support filename encryption
<jibel> Feb 26 10:58:21 ubuntu user-setup: ERROR:  Could not add passphrase to the current keyring
<jibel> Feb 26 10:58:21 ubuntu user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u u' returned error code 1. Exiting.
<jibel> installation logs
<jibel> looks like a kernel issue
<jibel> apw, ^ any idea? it's bug 1817689
<ubot5> bug 1817689 in ubiquity (Ubuntu) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Undecided,New] https://launchpad.net/bugs/1817689
<apw> jibel, which kernel is that
<jibel> 4.15.0-45-generic
<apw> and this was not in .5; do we know ?
<jibel> it works fine on .5
<sil2100> jibel: and there was no message like that in the logs, right?
<jibel> it worked so I did 't check the logs
<jibel> no such message in .5 which has kernel 4.15.0-29-generic
<apw> jibel, i assume you are able to install kernels and test ?
<jibel> apw, yes, I should be able to do that. which kernel do you want to test?
<apw> jibel, i am suspicious this of -37 as being when it changed, are you able to check -36 and -37
<jibel> sure
<apw> jibel, you are a star
<sil2100> Interesting fact is that if I boot a xenial .6 system, switch to a tty, create a new user, run ecryptfs-setup-private -b -u user - all is good
<sil2100> So I would personally doubt it's kernel?
<sil2100> Since if I do it like this and manually encrypt home for a new user, I can log in normally and from what I see the home dir of that user is encrypted
<sil2100> jibel, apw: ^
<apw> sil2100, hmmmm
<apw> sil2100, and filename encryption appears to be on as far as i can tell
<apw> sil2100, i wonder how that thing decides it is not
<sil2100> ah, hmmm
<sil2100> Ok, so apparently after reboot I can't log in into the new user as well
<sil2100> So yeah, something's busted, but not sure how
<jibel> sil2100, if it helps here is the diff of the manifests with .5 http://paste.ubuntu.com/p/pfBQ6Wk924/
<sil2100> apw: so maybe there's indeed something kernel-related, since as mentioned after reboot it doesn't work again
<sil2100> I also test installed .5 and I didn't see any messages like this, everything just works
<apw> sil2100, so i think we wait on the jibel testing, if that shows a boundary there, we may have a likely culprit ... though that change sounds sane, so it might be userspace related
<apw> sil2100, still userspace related, as in the test might be invalid
<apw> anyhow, lets see
<jibel> is the archive not frozen for xenial? I've updates of ghostscript and gnome-keyring after a fresh installation
<sil2100> That's security
<sil2100> Not much I can do about that
<sil2100> jdstrand: hey! Could you maybe take a look at our xenial issues as well? ^
<sil2100> Strange that in the installer logs one can see the 'Your kernel does not support filename encryption', but then on the running system when you check /sys/fs/ecryptfs/version, it seems to have the flag for kernel encryption set
<sil2100> Both seem to be running the same kernel?
<sil2100> Oh, wait
<sil2100> Yeah, that's correct
<sil2100> So hmmm, I wonder what's going on during the install
<jibel> I cannot reproduce with -45 on an installed system
<Laney> jibel: can you share the /var/log/installer/syslog from the .5 install?
<vorlon> ginggs: well, the autopkgtest runners only have 1.5GiB of RAM altogether, so any little bit above that is enough to top out on the runners.  But also, my expectation is that memory usage doesn't grow over time at all, that certainly sounds like a leak to me.  I'll rerun under valgrind in an env with more memory.
<jibel> Laney, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1817689/+attachment/5241810/+files/syslog.16.04.5
<ubot5> Launchpad bug 1817689 in ubiquity (Ubuntu Xenial) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Critical,Confirmed]
<Laney> thx
<Laney> so you can see a difference there when it does the thing in user-setup
<jibel> yes, when it's successful is says "Done configuring" and when it fails it says
<jibel> Feb 26 10:58:21 ubuntu user-setup: Error: Your kernel does not support filename encryption
<jibel> Feb 26 10:58:21 ubuntu user-setup: ERROR:  Could not add passphrase to the current keyring
<sil2100> Looks like this is an issue only during install
<jibel> Feb 26 10:58:21 ubuntu user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u u' returned error code 1. Exiting.
<jibel> yup
<jibel> and I cannot boot with another kernel, I've boot loop for some reason
<jibel> boot the live session
<sil2100> Oh, right, I can experiment in the live session
<sil2100> On the live session on .6 /sys/fs/ecryptfs/version seems to support encrypted filenames, and doing adduser --encrypt-home seems to succeed
<sil2100> I'll try to see what happens if I try installing from the live session
<Laney> can't make this error happen myself, weird one
<sil2100> Ok, strange, when running ubiquity installer from the live session, I still see it failing in user-setup, wtf
<sil2100> Laney: like, you can't get ecryptfs to fail during install for you?
<Laney> nah
<Laney> I can't do it outside of ubiquity
<sil2100> Yeah, same here
<sil2100> My earlier case was invalid
<sil2100> So the only place where it fails is during ubiquity install
<sil2100> bdmurray: remember not to release any xenial packages into -updates o/
<sil2100> RAOF: ^
<sil2100> Laney: maybe ubiquity needs a rebuild? I didn't think that was necessary
<Laney> what for?
<sil2100> I don't know, if I knew I'd rebuild it ;)
<sil2100> It's really intriguing, user-setup fails during install with the unsupported filename encryption thing, but even when I check /target/sys/fs/ecryptfs/version etc. it all looks like this error shouldn't have been printed
<sil2100> The right flags are in the version number
<Laney> yeah I wrote a program to call that same function and it works :<
<jibel> maybe the error message is misleading did you check in which case it's displayed?
<sil2100> jibel: it's displayed by the ecryptfs tools only in this particular case, I checked the code
<sil2100> The string is in ECRYPTFS_ERROR_FNEK_SUPPORT and it's only printed in ecryptfs_add_passphrase.c, which checks for the existance of the flag in version
<sil2100> Oh, wait
<sil2100> It can also print it out with ecryptfs_get_version() returns non-zero, so maybe somehow sysfs is not mounted on /target yet? Doesn't make sense though
<sil2100> Or maybe some permission problems accessing sysfs, but that also doesn't make sense
<apw> systemd?
<vorlon> seb128: do you know why the disco desktop image is now 300MB bigger than it was at the beginning of the month? (and > 2GB)
<seb128> no idea, but that's interesting
<seb128> thanks for pointing it out, I'm going to poke
<seb128> last cycle we had the issue and it was some toolchain thing having debug by default during the unstable cycle iirc
<seb128> but I don't remember the specifics now
<seb128> I have a look a bit later and let you know
<vorlon> seb128: the count of packages has also increased sustantially, 1657 -> 1805
<jibel> sil2100, /target/sys is populated and ecryptfs/version exists
<sil2100> Yeah, I know, I saw that during the install
<sil2100> But maybe not before user-setup was called?
<sil2100> Like, it's mounted later or something?
<vorlon> seb128: mostly a lot of locale stuff that previously wasn't on the CD, so maybe someone fixed something that was previously broken?  Also curl is being pulled in which sounds like a bug (we have wget)
<sil2100> jibel: ok, I think that's the case
<sil2100> jibel, Laney: if you check  the logs, first user-setup runs and only later in the logs I see `chroot /target mount -t sysfs sysfs /sys
<sil2100> `
<vorlon> seb128: list of newly added packages in the manifest: https://paste.ubuntu.com/p/9gv6knNrZ6/
 * sil2100 checks the .5 sysfs logs
<sil2100> huh
<sil2100> Laney, jibel: that's it
<sil2100> Laney, jibel: if you check the .5 logs, there sysfs is first mounted in /target and only then user-setup runs
<sil2100> Laney, jibel: but now it's the other way around!
<sil2100> Laney: hmm, did your change for the move-the-keyboard-setup-earlier go into xenial-updates?
<sil2100> Laney: did you SRU those changes?
<sil2100> Laney: since to me it seems that the order in ubiquity somehow changed and now user-setup runs earlier due to that
<sil2100> eh, darn ubiquity
<sil2100> So now someone just needs to figure out why we now have user-setup running earlier and done
<sil2100> uh, wait
<Laney> don't think so, user-setup mounts /sys itself
-queuebot:#ubuntu-release- New source: waylandpp (disco-proposed/primary) [0.2.5-0ubuntu1]
<sil2100> Yeah...
<sil2100> Guess you're right
<sil2100> But at least I have a few other ideas to debug this
<sil2100> Laney: so strange, I didn't get much more info, but when user-setup runs ecryptfs/version seems readable and has correct contents, I was checking it right before adduser runs, no idea why it fails there
<sil2100> Even from inside the chroot
<Laney> sil2100: you hacked the script or?
<sil2100> Laney: yeah, I hacked user-setup-apply in ubiquity/user-setup
<sil2100> Right before adduser is called that does all the setup I added some catting and statting of the ecryptfs version path, from outside and inside the chroot - all looked correct
<Laney> sil2100: HMMMMMMMMMMMMMMMMMM ok
<Laney> I put a "sleep infinit_y" right after the call and now I can poke in there
<jibel> and I checked that sysfs is mounted right before calling adduser
<Laney> the version is coming out weird
<sil2100> Laney: what version number do you see?
<Laney> 611346400
-queuebot:#ubuntu-release- New sync: gmbal-commons (bionic-proposed/primary) [3.2.1-b003-1~18.04]
<Laney> but the call errors
<sil2100> Since in cat from before adduser in the chroot I'm getting 375, which is correct
<Laney> rc != 0
-queuebot:#ubuntu-release- New sync: gmbal (bionic-proposed/primary) [4.0.0-b002-1~18.04]
-queuebot:#ubuntu-release- New sync: gmbal-pfl (bionic-proposed/primary) [4.0.1-b003-2~18.04]
<sil2100> uh
<sil2100> wow
-queuebot:#ubuntu-release- Unapproved: istack-commons (bionic-proposed/universe) [3.0.6-1 => 3.0.6-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jaxb (bionic-proposed/universe) [2.3.0-3 => 2.3.0.1-7~18.04] (no packageset) (sync)
<Laney> so that's just whatever the memory had before
-queuebot:#ubuntu-release- Unapproved: jaxb-api (bionic-proposed/universe) [2.2.9-1 => 2.3.1-1~18.04] (no packageset) (sync)
<sil2100> Laney: right after the call - you mean, right after adduser?
-queuebot:#ubuntu-release- Unapproved: jaxe (bionic-proposed/universe) [3.5-9 => 3.5-11~18.04] (no packageset) (sync)
<Laney> yeah
<sil2100> (sorry for the noise guys ^)
<Laney> the one that dies
<Laney> add a sleep there, then you can get in the chroot and mess around
-queuebot:#ubuntu-release- Unapproved: jaxrs-api (bionic-proposed/universe) [2.1-1 => 2.1.2-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libwoodstox-java (bionic-proposed/universe) [1:4.1.3-1 => 1:5.1.0-2~18.04] (no packageset) (sync)
<sil2100> Laney: wow, so it's like something in adduser (the ecryptfs tools) breaks ecryptfs?
-queuebot:#ubuntu-release- Unapproved: libstax2-api-java (bionic-proposed/universe) [3.1.1-1 => 4.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-bundle-plugin (bionic-proposed/universe) [3.5.0-1 => 3.5.1-2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: jaxrpc-api (bionic-proposed/primary) [1.1.2-2~18.04]
-queuebot:#ubuntu-release- New sync: jaxws (bionic-proposed/primary) [2.3.0.2-1~18.04.1]
-queuebot:#ubuntu-release- New sync: jaxws-api (bionic-proposed/primary) [2.3.0-1~18.04]
-queuebot:#ubuntu-release- New sync: jws-api (bionic-proposed/primary) [1.1-1~18.04]
<Laney> dunno, I'm seeing what get_version does
-queuebot:#ubuntu-release- New sync: maven-jaxb2-plugin (bionic-proposed/primary) [0.14.0-1~18.04.1]
-queuebot:#ubuntu-release- New sync: mimepull (bionic-proposed/primary) [1.9.7-1~18.04]
-queuebot:#ubuntu-release- New sync: metro-policy (bionic-proposed/primary) [2.7.2-3~18.04]
-queuebot:#ubuntu-release- Unapproved: maven-enforcer (bionic-proposed/universe) [1.4.2-1 => 3.0.0~M2-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-dependency-plugin (bionic-proposed/universe) [3.0.1-3 => 3.1.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-plugin-tools (bionic-proposed/universe) [3.5-6 => 3.5-6ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: saaj-ri (bionic-proposed/primary) [1.4.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (cosmic-proposed) [3.30.2.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: stax-ex (bionic-proposed/universe) [1.7.8-1 => 1.7.8-3~18.04.1] (no packageset) (sync)
<Laney> the file in /sys *is* right
<Laney> forgot to say that, that's important ;-)
<sil2100> Ah, so in the chroot, /sys/fs/ecryptfs/version has a sane version when you cat it directly?
<Laney> ye
<sil2100> wow
<Laney> ecryptfs-utils does some weird stuff to get it
 * sil2100 needs to take care of the openjdk packages
-queuebot:#ubuntu-release- Unapproved: accepted istack-commons [sync] (bionic-proposed) [3.0.6-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jaxb [sync] (bionic-proposed) [2.3.0.1-7~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jaxb-api [sync] (bionic-proposed) [2.3.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jaxe [sync] (bionic-proposed) [3.5-11~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jaxrs-api [sync] (bionic-proposed) [2.1.2-2~18.04]
<Laney> sil2100: there's no mtab, so the function bails out
-queuebot:#ubuntu-release- Unapproved: accepted libstax2-api-java [sync] (bionic-proposed) [4.1-1~18.04]
<Laney> because /proc isn't mounted
-queuebot:#ubuntu-release- Unapproved: accepted libwoodstox-java [sync] (bionic-proposed) [1:5.1.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-bundle-plugin [sync] (bionic-proposed) [3.5.1-2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maven-dependency-plugin [sync] (bionic-proposed) [3.1.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-enforcer [sync] (bionic-proposed) [3.0.0~M2-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maven-plugin-tools [sync] (bionic-proposed) [3.5-6ubuntu1~18.04.1]
 * Laney tries ...
<sil2100> uh oh
-queuebot:#ubuntu-release- Unapproved: accepted stax-ex [sync] (bionic-proposed) [1.7.8-3~18.04.1]
<sil2100> Laney: wonder what happened that /proc is not available now
<sil2100> Laney: did you manage to get it working after mounting /proc ?
<Laney> dunno
<Laney> not got that far yet
<Laney> I should disconnect the network, it spends ages downloading stuff each time
-queuebot:#ubuntu-release- New: accepted gmbal [sync] (bionic-proposed) [4.0.0-b002-1~18.04]
-queuebot:#ubuntu-release- New: accepted gmbal-commons [sync] (bionic-proposed) [3.2.1-b003-1~18.04]
-queuebot:#ubuntu-release- New: accepted gmbal-pfl [sync] (bionic-proposed) [4.0.1-b003-2~18.04]
<Laney> AHHHHHHHH YEAHHHHHHHHHHHHHHHHH
<teward> o.O
-queuebot:#ubuntu-release- New: accepted jaxrpc-api [sync] (bionic-proposed) [1.1.2-2~18.04]
<vorlon> sil2100, doko: do you need anything from me wrt the openjdk-11 SRUs?  I could spend a little time on it this afternoon if needed, but I don't know what's next
-queuebot:#ubuntu-release- New: accepted jaxws [sync] (bionic-proposed) [2.3.0.2-1~18.04.1]
<sil2100> vorlon: I'm currently finishing copying the stage4 packages, rest has not yet been reviewed by security
<doko> vorlon, sil2100: tiago wanted to identify the leaf apps, but didn't send me an update as promised
<sil2100> Laney: works?!
-queuebot:#ubuntu-release- New: accepted jaxws-api [sync] (bionic-proposed) [2.3.0-1~18.04]
<doko> sbeattie will review the apps, tomcat and stage5 PPAs
<sil2100> Laney: did you figure out why /proc was not mounted, or not yet?
<vorlon> cpaelzer: I don't understand https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1812384/comments/20 I see no autopkgtest failures related to this SRU
<ubot5> Launchpad bug 1812384 in Ubuntu on IBM z Systems "[Ubuntu] qemu - backport diag308 stable exception fix" [Medium,Fix committed]
<Laney> sil2100: I dunno what changed, but I know that user-setup doesn't mount it
<vorlon> cpaelzer: (http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#qemu is clean)
<Laney> so I'll upload a fix to do that directly, but if someone wants to find out why the order changed they can
<Laney> I just upload user-setup and then we rebuild ubiquity to get it, right?
<sil2100> Laney: excellent! +1 on that
<doko> vorlon: and we have some autopkg test failures, but EOD for me now
<sil2100> Laney: yeah
-queuebot:#ubuntu-release- New: accepted jws-api [sync] (bionic-proposed) [1.1-1~18.04]
<sil2100> Laney: upload it then I can review/accept it, at least the user-setup one
<Laney> okey
<Laney> test/review/accept? ;-)
<sil2100> HOTFIX FOR THE WIN
<Laney> I'll have to go straight after (pub quiz) so won't be around to fix stuff up unfortunately
-queuebot:#ubuntu-release- New: accepted maven-jaxb2-plugin [sync] (bionic-proposed) [0.14.0-1~18.04.1]
<sil2100> Laney: no worries, thanks for the help with the investigation and the 'fixation' (wanted it to rhyme)!
<willcooke> nice one Laney, thank you!
<vorlon> cpaelzer: oh, I guess bdmurray already merged, n/m
-queuebot:#ubuntu-release- New: accepted metro-policy [sync] (bionic-proposed) [2.7.2-3~18.04]
<sil2100> Laney: in case you won't manage to do the ubiquity rebuild, I can do that as well
<sil2100> Laney: don't want you to miss the pub action
<willcooke> :)
-queuebot:#ubuntu-release- New: accepted mimepull [sync] (bionic-proposed) [1.9.7-1~18.04]
<sil2100> doko, vorlon: all stage4 packages should be copied and accepted now, phew
-queuebot:#ubuntu-release- New: accepted saaj-ri [sync] (bionic-proposed) [1.4.1-1~18.04]
<doko> sil2100: stage5 has 60 ...
<Laney> sil2100: definitely won't
<Laney> especially if you want to test before :>
<sil2100> Indeed
<sil2100> That's cool
<sil2100> Laney: just give me a poke once you upload user-setup
<sil2100> doko: ...lovely
<Laney> will be in one minute
-queuebot:#ubuntu-release- Unapproved: user-setup (xenial-proposed/main) [1.63ubuntu4 => 1.63ubuntu4.1] (core)
<Laney> damn it, make that two
<Laney> I haven't done anything else, like fix devel (although this option is hidden in all other supported releases AFAIK) or SRUify the bug I'm afraid
<Laney> o/
<sil2100> o/
<sil2100> That's ok
<sil2100> It's a release critical bug, it'll be fast-tracked anyway
<sil2100> Laney: thanks and have fun!
<Laney> thx
<Laney> will follow up tomorrow if anything needs doing
<Laney> goodnight
<willcooke> see you Laney
 * sil2100 prepares his kvm for testing
<jibel> sil2100, let me know when you have a package to verify
<sil2100> jibel: will do
<sil2100> I'll test the code changes before accepting
<sil2100> Code-wise looks good, testing looks promising as well
<sil2100> \o/
<sil2100> Accepting
-queuebot:#ubuntu-release- Unapproved: accepted user-setup [source] (xenial-proposed) [1.63ubuntu4.1]
<sil2100> jibel: user-setup is building in xenial-proposed now, once that's built you can give it a spin - I'll also prepare ubiquity then
-queuebot:#ubuntu-release- Unapproved: accepted lldpd [source] (cosmic-proposed) [1.0.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted lldpd [source] (bionic-proposed) [0.9.9-1ubuntu0.1]
<jibel> sil2100, k
<seb128> vorlon, the current disco iso is about the same size as the bionic/cosmic ones and your list of new packages look like thing that are usually on the iso, so I guess it's the earlier one you had which was buggy
<vorlon> ok
<sil2100> jibel: ...still waiting for the mirrors to catch up
<jibel> sil2100, I downloaded the version from lp
 * sil2100 is still waiting for it to pop up in the the main archive mirror to pull it into ubiquity
<jibel> sil2100, user-setup 1.63ubuntu4.1 fixes the problem now i'd like to know why it is not happening previously. This package didn't change since the initial release of xenial
<sil2100> jibel: yeah, we will investigate that for sure, but we should prioritize landing this anyway
<jibel> indeed
<sil2100> vorlon: is there a way to sync archive mirrors somehow?
<vorlon> mm?
<sil2100> vorlon: like, I'm waiting and waiting for user-setup to appear in archive.ubuntu.com but it's not happening!
<vorlon> you should check with IS
<vorlon> there is no manual process for triggering a sync because it's supposed to always sync asap
<cjwatson> I think there've just been a couple of big publisher runs
<sil2100> vorlon, cjwatson: thanks
<sil2100> Sorry for being impatient
<cjwatson> Not seeing anything actually wrong
<Odd_Bloke> vorlon: Do you think you might be able to merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 ?
<vorlon> Odd_Bloke: I don't understand the rationale here; the only current failure I see of vagrant-mutate is one that blocks an update of vagrant, but I see two recent successes of the autopkgtest with other triggers since the last time it was retried with -proposed vagrant
<vorlon> so can you ++verbose on what 'network issues' means?  is this actually a flaky test?
<Odd_Bloke> vorlon: Yeah, we're seeing flakiness (which appears to be network related); I hadn't seen that Christian had managed to get a qemu pass, so I'm retrying now to see if it works for vagrant too.
<vorlon> Odd_Bloke: already retried it fwiw
<Odd_Bloke> Cool, I'll keep an eye out; thanks!
-queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.9 => 2.21.63.10] (core)
<sil2100> jibel: accepted ubiquity
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.10]
<sil2100> jibel: once that builds would be nice to sanity-test it, release and re-spin the world!
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [s390x] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [amd64] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [ppc64el] (disco-proposed/universe) [0.2.1-1] (no packageset)
<vorlon> Odd_Bloke: both of our retries failed
-queuebot:#ubuntu-release- New sync: rust-ascii (disco-proposed/primary) [0.9.1-1]
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [i386] (disco-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [arm64] (disco-proposed/universe) [0.2.1-1] (no packageset)
<Odd_Bloke> vorlon: ;.;
<vorlon> merging hint
-queuebot:#ubuntu-release- New binary: rust-rusty-fork [armhf] (disco-proposed/universe) [0.2.1-1] (no packageset)
<Odd_Bloke> Thanks!
-queuebot:#ubuntu-release- Unapproved: rejected skiboot [source] (cosmic-proposed) [6.1-2ubuntu0.1]
<vorlon> ginggs: well, running to completion under valgrind, valgrind only finds 332k of memory leaking
<vorlon> ginggs: so it's possibly deferred gc but not leaks per se :/
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [armhf] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [i386] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: rejected rust-ascii [sync] (disco-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [arm64] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [s390x] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [amd64] (disco-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusty-fork [ppc64el] (disco-proposed) [0.2.1-1]
<vorlon> ==124425==    still reachable: 413,357,685 bytes in 789,082 blocks
-queuebot:#ubuntu-release- New binary: rust-proptest [amd64] (disco-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proptest [s390x] (disco-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proptest [i386] (disco-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proptest [ppc64el] (disco-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-proptest [i386] (disco-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [amd64] (disco-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [s390x] (disco-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted rust-proptest [ppc64el] (disco-proposed) [0.8.7-1]
 * sil2100 tests the new ubiquity
<sil2100> eh, ok, still not there
<sil2100> Usually when rmadison was giving me a +1 that a package is published, this meant it was available
<sil2100> But today there seems to be some lag
<sil2100> Looks good, releasing
<sil2100> vorlon, infinity: I guess I need to go to sleep now
<sil2100> vorlon, infinity: can one of you re-spin all the 16.04.6 images once ubiquity and user-setup get fully published in xenial-updates?
<sil2100> You can use the isotracker for that
<sil2100> Just remember, today it seems to take a bit for the package to publish and actually appear on the archive mirrors
<vorlon> sil2100: and I think we need to resnapshot the point release?
<sil2100> vorlon: yes, that too
<sil2100> + source iso's as well
<sil2100> (once it's all published)
<sil2100> vorlon: would be grateful o/
<vorlon> ok, I'll take it
<sil2100> Thank you!
 * sil2100 off to sleep
<sil2100> Goodnight
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (cosmic-proposed) [18.09.2-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (bionic-proposed) [18.09.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [18.09.2-0ubuntu1~16.04.1]
<vorlon> infinity: both python-biopython and postgresql-hll regressions w/ glibc 2.29 look to me like fp behavior changes that need someone to understand
#ubuntu-release 2019-02-27
<vorlon> infinity: there is a notable lack of documentation on the building of source images on https://wiki.ubuntu.com/PointReleaseProcess - is 'cron.source' (documented on https://wiki.ubuntu.com/ReleaseProcess) still the right interface?
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.6] has been updated (20190226)
-queuebot:#ubuntu-release- New binary: mir [s390x] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (cosmic-proposed) [1:12.2-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.2]
-queuebot:#ubuntu-release- New binary: mir [ppc64el] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [i386] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [amd64] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [arm64] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [armhf] (disco-proposed/main) [1.1.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xfwm4 (bionic-proposed/universe) [4.12.4-0ubuntu1 => 4.12.5-1ubuntu0.18.04.1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.8 => 3.28.1-0ubuntu4.18.04.9] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rust-rand [i386] (disco-proposed/universe) [0.6.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [armhf] (disco-proposed/universe) [0.6.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rand [armhf] (disco-proposed) [0.6.4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-rand [i386] (disco-proposed) [0.6.4-1ubuntu1]
<jibel> sil2100, Hi
<jibel> sil2100, OEM installation is broken
<jibel> on 20190226
<jibel> sil2100, there is no "Prepare for shipping" icon on first boot after an OEM installation
<sil2100> jibel: did it work in 22?
<jibel> sil2100, yes
<sil2100> ...huh?
<LocutusOfBorg> does any AA understand this?
<LocutusOfBorg> skipped: libjsr305-java (9, 14, 18)
<LocutusOfBorg>     got: 68+0: a-29:a-6:a-5:i-13:p-6:s-9
<LocutusOfBorg>     * amd64: libowasp-java-html-sanitizer-java-doc
<LocutusOfBorg> I failed
<sil2100> jibel: we literally touched nothing regarding that, did the rebuild of ubiquity do this?
<sil2100> jibel: is it reproducible?
<acheronuk> LocutusOfBorg: 0.1~+svn49-11 disn't build the libjsr305-java-doc package that  libowasp-java-html-sanitizer-java-doc depends on?
<acheronuk> *didn't
<sil2100> jibel: I don't know much about these parts, where do all the OEM installation parts come from? Is it ubiquity or d-i?
<LocutusOfBorg> acheronuk, thanks, it is mentioned in control file and excluded in rules, what an ugly hack
-queuebot:#ubuntu-release- New: accepted mir [amd64] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [armhf] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [ppc64el] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [arm64] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [s390x] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mir [i386] (disco-proposed) [1.1.1-0ubuntu2]
-queuebot:#ubuntu-release- New binary: libjs-webrtc-adapter [amd64] (disco-proposed/universe) [7.2.1~ds-1] (no packageset)
<LocutusOfBorg> can we please have gazebo hinted?
<LocutusOfBorg> autopkgtest for gazebo/9.6.0-1build1: amd64: Pass, arm64: Regression â» , armhf: Regression â» , i386: Pass, ppc64el: Regression â» , s390x: Always failed
<LocutusOfBorg> it is NBS, testsuite obviously fails now
<LocutusOfBorg> arm64 armhf and ppc64el needs an hint
<LocutusOfBorg> Removal requested in 23 hours.
<LocutusOfBorg> Superseded 14 minutes ago by libjs-webrtc-adapter - 7.2.1~ds-1
<LocutusOfBorg> LOL
<jibel> sil2100, it's surely because oem-config on the iso and ubiquity are out of sync
<jibel> sil2100, oem-config is .9 and ubiquity is .10
<jibel> sil2100, usually rebuilding the iso fixes it
<Laney> let me try that for ubuntu/amd64 (without --live)
<sil2100> huh
<sil2100> I'll leave it in your hands then guys
<jibel> you don't have to rebuild the squashfs
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190227)
<jibel> Laney, the new image is on the tracker but not published on cdimage
<Laney> it's presumably rsyncing
<Laney> I can see the files on the build machine
<sil2100> Does this mean that the images were built too soon?
<sil2100> (the ones yesterday)
<Laney> There's a local mirror on nusakan - is it that which might have been out of date?
<sil2100> I guess maybe Steve didn't do an anonftpsync
<sil2100> Before kicking the builds
<Laney> I'm not super sure how that works, sorry
<Laney> https://paste.ubuntu.com/p/q5sSF8Mk9S/
<Laney> that looks good tho
<jibel> Laney, an i386 image just appeared for today but it's the old version of oem-config
<Laney> I didn't rebuild that one yet
<jibel> ah, amd64 is correct
<Laney> can you try that amd64 one?
<jibel> can you redo i386 too?
<Laney> if it's good, yes
<sil2100> Laney, jibel: thanks guys!
<Laney> ok, i386 is going
<Laney> sil2100: not sure what else is in this point release, did you want to do those maybe?
<sil2100> Laney: looking at the other images, for instance ubuntu-mate seems to be fine (the correct oem-config was pulled in)
<sil2100> I'll be sure to re-build (without --live) those that might need it
<Laney> thanks â¥
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190227.1)
<Laney> there we go
<sil2100> Crap, lubuntu might need to be rebuilt, while I see the flavors already did some testing there, eh
<sil2100> Oh well
<sil2100> Other flavors seem to be good, so just lubuntu
<willcooke> jibel, you want me to do a test on real hardware?
<jibel> willcooke, wait until I check that oem is ok
<willcooke> jibel, ack.  Poke me when you're ready
<jibel> in ~10 minutes
 * willcooke . o O ( Time for tea )
<jibel> willcooke, ready for testing
<jibel> willcooke, use 20190227.1 (not 20190227)
<jibel> sil2100, Laney oem is ok on .1
<Laney> cool, thx for finding
<sil2100> Laney, jibel: thanks again \o/
<willcooke> jibel, roger roger
<willcooke> jibel, do you want an OEM and a encrypted home test doing?
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] has been updated (20190227)
<sil2100> tsimonq2: ^ sorry for having to respin those
<sil2100> But at least the oem-config version seems good now
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.6] has been marked as ready
<jibel> willcooke, + screenreader
<willcooke> ack
<jibel> willcooke, + uefi + secureboot and wifi
<jibel> I did it yesterday but just to be sure
<willcooke> sure thing
<jibel> but this image should be the finale one
<jibel> I'll do  cjk and vmware
<willcooke> k, the enc. home is working now
<willcooke> on to the others
 * sil2100 has his fingers crossed
<jibel> oh and I still have to cover netboot
<willcooke> mm, bit of a funny with the wifi on oem setup.  Rebooted and its fine now
<willcooke> I think its safe to ignore, but I will refd
<willcooke> redo the test later
<jibel> vmware is fine, moving to netboot/pxe
<jibel> sil2100, does d-i need a rebuild due to the update of user-setup?
<jibel> or netboot downloads the right version from the archive?
<sil2100> jibel: not sure, can you check if it all works as expected right now?
<jibel> sil2100, yes, i'm on it with pxe too
<sil2100> I would prefer not to rebuild anything right now if it works, since we already did a snapshot of the archive
<willcooke> jibel, sil2100 - oem, screenreader, uefi and legacy all ok
<willcooke> ha, now the iso tracker is down
<Laney> wfmâ¢
<willcooke> working now
<jibel> sil2100, netboot/pxe works and encrypted home too
<sil2100> phew
<sil2100> jibel: thanks!
<acheronuk> infinity: is there any ETA on glibc migration yet? no worries if not, I just have some KDE plasma bits stuck in proposed due to it, but its not a huge deal
<sil2100> jibel: you think we're good from the desktop POV?
<jibel> sil2100, I didn't finish testing
<jibel> give me 1 or 2 hours
<sil2100> Thanks ;)
<vorlon> seb128: so if the packages included in the disco desktop iso are all as expected, does that mean you think we should raise the size limit for the image?  bionic and cosmic were both < 2GB; disco is 30MB over
<slashd> morning vorlon, pinging you after a discussion I had w/ sil2100 about pam, since you seemed the TBL person for pam. I notice pam is having a unusual debian patches directory (debian/patches-applied)... my question is should I use quilt anyway with that path or does this means something special like I should avoid using quilt ?
<vorlon> slashd: it's all quilt, it predates 3.0 (quilt) format
<vorlon> slashd: eventually I'll migrate it to 3.0 (quilt) but I've only just this year gotten the VCS moved to something not defunct
<vorlon> so, baby steps
<slashd> vorlon, gotcha thanks for the quick reply
<slashd> sil2100, fyi ^
<jibel> sil2100, everything looks good. I didn't find anything else.
<seb128> vorlon, it's a conversation worth having, do you believe that being under 2Go has value (we can probably spare those 30MB if we think it has value)
<seb128> willcooke, ^
<sil2100> jibel: phew..!
<sil2100> jibel: good news then!
<vorlon> seb128: I don't have a strong opinion, obviously software grows over time; I just care because being oversized generates daily nag mails to us, and warning banners on the daily image download page, so desktop team should decide whether to raise the limit or lower the image :)
<vorlon> I think it's still defensible to *have* such limits because it avoids the image ballooning accidentally
<seb128> vorlon, can you remind me what the current limit is and where it's defined?
<seb128> right
<vorlon> seb128: 2GB exactly; defined in lp:ubuntu-cdimage lib/cdimage/tree.py
<seb128> vorlon, thx
<seb128> vorlon, I'm adding a trello card to our board to sort that out one way or another
<vorlon> n/p
<willcooke> In this instance, I think having the extra langs is useful.  We can certainly look at trying to save some space though
<seb128> willcooke, well, 30M can probably we spared if we look hard enough
<seb128> like could be swapping a snap back for a deb for example
<seb128> so it's just a matter to decide on what we consider as higher priority
<willcooke> IMO, increasing the limit is the right thing to do here
<seb128> willcooke, vorlon, https://trello.com/c/jiekZ9I0/247-revisit-the-limit-set-for-the-desktop-iso
<seb128> willcooke, k, well we just need to decide what number we want and update things then, ^ for tracking
<willcooke> thanks seb128
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1] (desktop-core)
<Laney> sil2100: do you think I should upload user-setup to bionic/disco for completeness?
<Laney> also, it appears to have not been deleted from xenial-proposed https://launchpad.net/ubuntu/+source/user-setup/1.63ubuntu4.1
<infinity> vorlon: "DIST=foo cron.source" is the interface, yes.
<infinity> vorlon: Then, because stupid reasons, need to go find it, and rm current && ln -s newserial current.
<infinity> vorlon, sil2100: And since I don't see a new one for your new images, I'll spin a new xenial source for you right now before I run off for the morning.
<infinity> Also rebuilding the ubuntu-base request that went poof from the tracker.
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.6] has been updated (20190227)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (trusty-proposed/universe) [1.0.0-0ubuntu1~14.04.1 => 1.0.0-0ubuntu1~14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (xenial-proposed/universe) [1.0.0-0ubuntu1~16.04.0 => 1.0.0-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/universe) [1.0.0-0ubuntu1~18.04.0 => 1.0.0-0ubuntu1~18.04.1] (no packageset)
<Laney> sil2100: doing disco I think
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (cosmic-proposed/universe) [1.0.0-0ubuntu1~18.10.0 => 1.0.0-0ubuntu1~18.10.1] (no packageset)
<rbalint> rbasak, if you have some sru cycles left for today could you please take a look at these? ^
<rbalint> rbasak, the change is minimal
<teward> i forget, if I have an FFe bug filed and pending review, do I wait until after approval to upload or can I upload and let it sit in the "Waiting for approval" list?
<teward> just to refresh my knowledge, sorry to sound like a total derp today :|
<ahasenack> teward: right now the FF is still a soft one,
<ahasenack> teward: so if you upload, it will land in proposed immediately
<ahasenack> teward: so wait for an ack in the FFe bug :)
<teward> ack
<teward> ahasenack: wasn't aware there was soft/hard blocks from the freezes :)
<rbasak> rbalint: looking
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (cosmic-proposed) [1.0.0-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (trusty-proposed) [1.0.0-0ubuntu1~14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (xenial-proposed) [1.0.0-0ubuntu1~16.04.1]
<rbalint> rbasak, thanks!
<jibel> sil2100, I'm done with Ubuntu Desktop, mini install and netboot/pxe. nothing to report and it's ready to release.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.2-0ubuntu0.18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2.7]
-queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (bionic-proposed) [2018.07~rc3+dfsg1-0ubuntu2~18.04.1]
<bdmurray> infinity: I accidentally accepted libsdl2 for bionic when I wanted to reject it.
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (bionic-proposed) [2.0.8+dfsg1-1ubuntu1.18.04.2]
<bdmurray> infinity: Is there anyway you can save it / me?
-queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (bionic-proposed) [1.11-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted uvloop [source] (bionic-proposed) [0.8.1+ds1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (bionic-proposed) [2.3.0-0ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted libevent-rpc-perl [source] (bionic-proposed) [1.08-2ubuntu0.1]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
<sil2100> jibel: excellent news, thank you!
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.37.1 => 2.37.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-httplib2 [source] (bionic-proposed) [0.9.2+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.37.1.1+18.04 => 2.37.4+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.37.1+18.10 => 2.37.4+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.37.1~14.04 => 2.37.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-imaplib2 [source] (bionic-proposed) [2.57-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libseccomp [source] (bionic-proposed) [2.3.1-2.1ubuntu4.1]
<infinity> bdmurray: I can remove it from proposed, obviously.
<infinity> bdmurray: Up to you to follow up with the bug and uploader to say why.
<bdmurray> infinity: I'd commented in the bug already regarding my concerns and then just pressed the wrong button.
<infinity> bdmurray: Hrm.  This also seems to be an incomplete fix...
<infinity> bdmurray: Deleted.
<infinity> bdmurray: If LocutusOfBorg later addresses both our concerns and claims that version was okay (though I'm not sure how it can be), I can just copy it back in without a new upload happening.
<infinity> bdmurray: But I'm pretty sure it'll need a fresh upload anyway.
<infinity> bdmurray: Most notably, it's missing this part of the cosmic upload:
<infinity> -# the SDL module for Vulkan not compiling even in Linux at the moment
<infinity> -confflags += --disable-video-vulkan
<infinity> -
<bdmurray> Well that's great.
-queuebot:#ubuntu-release- Unapproved: rejected skiboot [source] (bionic-proposed) [5.10~rc4-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected lmdb [source] (bionic-proposed) [0.9.21-1ubuntu2~bionic18.04]
-queuebot:#ubuntu-release- Unapproved: rejected openssl-ibmca [source] (bionic-proposed) [1.4.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (bionic-proposed) [3.28.5-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.11-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected openssl-ibmca [source] (cosmic-proposed) [2.0.0-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted openssl-ibmca [source] (cosmic-proposed) [2.0.0-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted openssl-ibmca [source] (bionic-proposed) [1.4.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (cosmic-proposed) [4.6.0-2ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.7]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
#ubuntu-release 2019-02-28
-queuebot:#ubuntu-release- Unapproved: pam (bionic-proposed/main) [1.1.8-3.6ubuntu2 => 1.1.8-3.6ubuntu2.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: pam (cosmic-proposed/main) [1.1.8-3.6ubuntu2 => 1.1.8-3.6ubuntu3] (core)
<superm1> Hi, can an archive admin please poke fwupd in disco?  It's awaiting publication due to UEFI binaries
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.6] has been marked as ready
<doko> why are fastqc and picard-tools autopkg tests triggered by openjdk-lts?
-queuebot:#ubuntu-release- New sync: sway (disco-release/primary) [1.0~rc3-1]
-queuebot:#ubuntu-release- New: accepted sway [sync] (disco-release) [1.0~rc3-1]
-queuebot:#ubuntu-release- Unapproved: libsdl2 (bionic-proposed/universe) [2.0.8+dfsg1-1ubuntu1.18.04.1 => 2.0.8+dfsg1-1ubuntu1.18.04.3] (kubuntu)
<LocutusOfBorg> bdmurray, it should be ok now
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1040.44~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1040.44~14.04.1]
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.4-0ubuntu0.18.10.1 => 1:6.1.5-0ubuntu0.18.10.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.4-0ubuntu0.18.10.1 => 1:6.1.5-0ubuntu0.18.10.1] (ubuntu-desktop)
<rbalint> sil2100, if you have sru cycles please promote unattended-upgrades for cosmic and bionic, also please accept it to xenial-proposed
<sil2100> rbalint: on it
<slashd> o/ sil2100 could you please approve upload in B & C for pam ?
<sil2100> slashd: will try! I'll be doing the .6 publishing dance soon though
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (cosmic-proposed/main) [5.11.1+dfsg-7ubuntu2 => 5.11.1+dfsg-7ubuntu3] (kubuntu, qt5, ubuntu-desktop)
<slashd> sil2100, ok no worries
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.2]
<Laney> juliank / sil2100: If you have a few minutes, do you feel like implementing a bit of wait/retry around uploading files to swift from the worker? I don't know if you're getting the spam I am, but swift is flaky as hell when it's replicating to new volumes and results are failing to upload properly. https://pastebin.canonical.com/p/wt9tgBtrMN/
<sil2100> Laney: not sure if I'll have any cycles today, sadly
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (cosmic-proposed) [1.1.8-3.6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (bionic-proposed) [1.1.8-3.6ubuntu2.18.04.1]
<Laney> bloop
 * sil2100 is prepping the .6 release to go out
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready
<sil2100> ^ I marked those images that were tested as ready
 * willcooke checks desktop
<willcooke> yeah, marked already
-queuebot:#ubuntu-release- New sync: haskell-secret-sharing (disco-proposed/primary) [1.0.0.3-6]
 * Laney does it then
<juliank> Laney: sorry, had a lunch break
<Laney> np, feel free to review / fix the commit in master
<Laney> now it's my turn to eat
<sil2100> Ok, publishing the images
<oSoMoN> sil2100, when you have a moment, would you mind accepting libreoffice{,-l10n} 1:6.1.5-0ubuntu0.18.10.1 into cosmic-proposed?
<sil2100> oSoMoN: will try o/
<oSoMoN> thanks!
<ddstreet> xnox hi, checking on systemd upload - unless you have one planned for today with the list of patches slashd emailed you, we're planning to upload systemd srus today - let us know asap please if you are planning to instead
-queuebot:#ubuntu-release- Unapproved: cinder (cosmic-proposed/main) [2:13.0.2-0ubuntu1 => 2:13.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.1-59-g0f993084-0ubuntu1 => 18.2-10-g7afd77fa-0ubuntu1~18.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu10 => 1.79ubuntu10.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu10 => 1.79ubuntu10.18.10.1] (no packageset)
<ddstreet> sil2100 i know you're super busy with the point release, but this resolvconf sru is for a regression fix; do you know if anyone else on the sru team is available to review/approve it?  bdmurray or rbasak maybe?  lp #1817903
<ubot5> Launchpad bug 1817903 in resolvconf (Ubuntu Cosmic) "systemd-resolve appends "options edns0" to resolv.conf" [Critical,In progress] https://launchpad.net/bugs/1817903
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.1-0ubuntu2 => 3:14.0.2-0ubuntu1] (openstack, ubuntu-server)
<sil2100> ddstreet: not sure, but hopefully I should be done with the image publishing in an hour or so
<sil2100> Might want to do a quick SRU shift then, since I basically skipped mine today (mostly)
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.1-59-g0f993084-0ubuntu1~18.04.1 => 18.2-10-g7afd77fa-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: swift (cosmic-proposed/main) [2.19.0-0ubuntu1 => 2.19.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.0.3-0ubuntu2 => 2:18.1.0-0ubuntu1] (openstack, ubuntu-server)
<rbasak> ddstreet, sil2100: if it helps, the SRU makes sense to me, but I don't have time to do a full review right now :-/
<rbasak> (and IMHO a detailed looks is necessary only because of the severity of the consequences of getting it wrong)
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.1-59-g0f993084-0ubuntu1~16.04.1 => 18.2-10-g7afd77fa-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lmdb (bionic-proposed/universe) [0.9.21-1 => 0.9.21-1ubuntu2~bionic18.04] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lmdb (cosmic-proposed/universe) [0.9.22-1 => 0.9.22-1ubuntu1~bionic18.10] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lmdb (cosmic-proposed/universe) [0.9.22-1 => 0.9.22-1ubuntu1~cosmic18.10] (kubuntu)
<acheronuk> bdmurray: uploads in response to your lmdb rejection message I think ^^
<Laney> retry thing seems to be working more or less
<Laney> seems swift is saaaaaaaaaaaddddddddddd at the minute
<vorlon> doko: libcolt-free-java, reproducible for me in a disco env w/ LANG=C.UTF-8
<vorlon> Laney: yeah I was noticing this, have you asked IS?
<wgrant> lol
<Laney> think they know ;-)
 * Laney snuggles wgrant 
<sil2100> ...ok, 16.04.6 should be out
<Laney> long live xenial
<vorlon> doko: so, run that sed command with LANG=C, so that sed doesn't refuse to process a line with invalid input
 * sil2100 celebrates the release all by himself, dancing in the corner
<sil2100> (it's a very unimpressive release)
<sil2100> ;)
<vorlon> sil2100: :)  well done, regardless
<cwayne> sil2100: every release is impressive in it's own way :)
<sil2100> Thanks ;p Let me send out the announcement then
<sil2100> Guess I'll wait for stuff to propagate first
<Laney> well, we had a couple of incidents
<Laney> so it certainly is a proper release :D
<tsimonq2> 'tis releasemanagering - it's all tested and ready to go, then respin :P
<tsimonq2> Congrats though :)
 * doko hands sil2100 a kinnie
<sil2100> doko: better not!
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: rejected lmdb [source] (cosmic-proposed) [0.9.22-1ubuntu1~bionic18.10]
-queuebot:#ubuntu-release- Unapproved: mutter (cosmic-proposed/main) [3.30.2-1~ubuntu18.10.3 => 3.30.2-1~ubuntu18.10.4] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [amd64] (disco-proposed) [1.2.4-3]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [i386] (disco-proposed) [1.2.4-3]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [arm64] (disco-proposed) [1.2.4-3]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (disco-proposed) [1.2.4-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (disco-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (disco-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (disco-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (disco-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: virt-manager (bionic-proposed/universe) [1:1.5.1-0ubuntu1.1 => 1:1.5.1-0ubuntu1.2] (no packageset)
<sil2100> ddstreet: hey! I had a quick look at the resolvconf change, but I think I'll have to defer the final review to someone else or actually pull in some expertise
<sil2100> I don't feel knowledgable enough to know the full consequences here
<sil2100> rbasak, vorlon: ^ can one of you guys take a look at it instead?
<vorlon> wince
<sil2100> It's resolvconf in cosmic and bionic
<ddstreet> sil2100 thnx :)
<vorlon> I am not impartial; I tried to get the package removed for bionic
<sil2100> The change seems *sane*, but is that change desirable in bionic?
 * sil2100 checks something
 * ddstreet stepping away for dinner soon but will check back later in case there's any questions for me about resolvconf sru
<vorlon> ddstreet: I think the information you've included under regression-potential should actually be listed as test cases
<sil2100> So looking at it some more and getting some context, I personally feel this is the right thing to SRU
<sil2100> vorlon: are you reviewing this SRU? Or only took a look?
<vorlon> sil2100: I'm not holding any lock on it, anyway
#ubuntu-release 2019-03-01
<ddstreet> i updated the bug test case to include the info from the regression potential section and tried to clarify everything between test case and regression potential.  thnx
-queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
<juliank> Is that ok, I could not make a test case: bug 1814543?
<ubot5> bug 1814543 in apt (Ubuntu) "deal with EPIPE from json hooks" [Undecided,Fix released] https://launchpad.net/bugs/1814543
<juliank> I hope i did not miss any sru bugs containing just templates :)
-queuebot:#ubuntu-release- Unapproved: apt (cosmic-proposed/main) [1.7.2 => 1.7.3] (core)
-queuebot:#ubuntu-release- Unapproved: numactl (cosmic-proposed/main) [2.0.11-2.2 => 2.0.11-2.2ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.8 => 1.6.9] (core)
-queuebot:#ubuntu-release- Unapproved: numactl (bionic-proposed/main) [2.0.11-2.1 => 2.0.11-2.1ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.29ubuntu0.1 => 1.2.30] (core)
<jibel> sil2100, Hi, thanks for the release of 16.04. Are you preparing 14.04.6 images today?
<sil2100> jibel: hey! I might be looking into that, yes, we'll see if today or Monday
<jibel> sil2100, k, let me know if there's something ready today so I can do an early review.
<juliank> apt/trusty coming soon, gotta fix a few minor issues
<juliank> at least xenial, bionic, and cosmic are approvable now :)
-queuebot:#ubuntu-release- New sync: gcc-8-cross-mipsen (disco-proposed/primary) [2~c2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-mipsen [sync] (disco-proposed) [2~c2]
-queuebot:#ubuntu-release- New: accepted libjs-webrtc-adapter [amd64] (disco-proposed) [7.2.1~ds-1]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [sync] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [amd64] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [i386] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [s390x] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [ppc64el] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [arm64] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-secret-sharing [armhf] (disco-proposed/none) [1.0.0.3-6] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [amd64] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [armhf] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [ppc64el] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [arm64] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [s390x] (disco-proposed) [1.0.0.3-6]
-queuebot:#ubuntu-release- New: accepted haskell-secret-sharing [i386] (disco-proposed) [1.0.0.3-6]
<sil2100> jibel: thanks, will do o/
-queuebot:#ubuntu-release- New binary: node-autoprefixer [amd64] (disco-proposed/universe) [8.6.5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (cosmic-proposed) [1.79ubuntu10.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu10.18.04.1]
-queuebot:#ubuntu-release- Unapproved: jruby-openssl (bionic-proposed/universe) [0.9.21-1 => 0.9.21-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jruby-openssl [sync] (bionic-proposed) [0.9.21-2~18.04]
-queuebot:#ubuntu-release- Unapproved: asm (bionic-proposed/universe) [6.0-1 => 7.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: bnd (bionic-proposed/universe) [3.5.0-1 => 3.5.0-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1013.13~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: fonts-liberation2 (bionic-proposed/main) [2.00.1-7~18.04.1 => 2.00.1-7~18.04.2] (kubuntu, personal-gunnarhj, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: java3d (bionic-proposed/universe) [1.5.2+dfsg-14 => 1.5.2+dfsg-16~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1013.13] (kernel)
-queuebot:#ubuntu-release- Unapproved: libequinox-osgi-java (bionic-proposed/universe) [3.9.1-1 => 3.9.1-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libgoogle-gson-java (bionic-proposed/universe) [2.8.2-1 => 2.8.5-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libnb-javaparser-java (bionic-proposed/universe) [7.4-1 => 9+2018-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libnb-platform18-java (bionic-proposed/universe) [8.1+dfsg1-7 => 10.0-2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.2 => 1:6.0.7-0ubuntu0.18.04.4] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.2 => 1:6.0.7-0ubuntu0.18.04.4] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: netbeans (bionic-proposed/universe) [8.1+dfsg3-4 => 10.0-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sweethome3d (bionic-proposed/universe) [5.7+dfsg-2 => 6.1.2+dfsg-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: visualvm (bionic-proposed/universe) [1.3.9-1 => 1.4.2-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1013.13~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1013.13]
-queuebot:#ubuntu-release- Unapproved: accepted asm [sync] (bionic-proposed) [7.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted bnd [sync] (bionic-proposed) [3.5.0-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted java3d [sync] (bionic-proposed) [1.5.2+dfsg-16~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libequinox-osgi-java [sync] (bionic-proposed) [3.9.1-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libgoogle-gson-java [sync] (bionic-proposed) [2.8.5-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libnb-javaparser-java [sync] (bionic-proposed) [9+2018-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libnb-platform18-java [sync] (bionic-proposed) [10.0-2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted netbeans [sync] (bionic-proposed) [10.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d [sync] (bionic-proposed) [6.1.2+dfsg-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted visualvm [sync] (bionic-proposed) [1.4.2-2~18.04]
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.20 => 1.0.1ubuntu2.21] (core)
<doko> looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt  (the line after the successful message, including glibc, gcc-8, gcc-9)
<doko> using update-output-helper, I get:
<doko> $ apt-get -oDir=/home/doko/.cache/brapt/aptroot -oDir::State::status=/home/doko/.cache/brapt/aptroot/status --dry-run install gcc-9-base libgcc1
<doko> The following packages have unmet dependencies:
<doko>  libgcc1 : Depends: gcc-9-base (= 9-20190220-0ubuntu1) but 9-20190227-0ubuntu1 is to be installed
<doko> E: Unable to correct problems, you have held broken packages.
<doko> this doesn't make sense, both packages are built from the same source
<doko> Laney: ^^^
<seb128> doko, he's off until monday
-queuebot:#ubuntu-release- Unapproved: squid (cosmic-proposed/main) [4.1-1ubuntu3 => 4.1-1ubuntu3.1] (no packageset)
<LocutusOfBorg> can we please hint python-asdf? it has been failing on s390x since the begin, for some reasons the result code was not correctly parsed...
<LocutusOfBorg> ./ubuntu-release:force-badtest python-asdf/2.3.1-1/s390x
<LocutusOfBorg> we can throw away the armhf hint, and update the s390x to 2.3.1-2
-queuebot:#ubuntu-release- Unapproved: accepted libxcb [source] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New binary: libxcb [s390x] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxcb [i386] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxcb [ppc64el] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- New binary: libxcb [armhf] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.4 => 4.3.40-dfsg-0ubuntu1.14.04.1~14.04.4] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcb [amd64] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.37.3~14.04]
-queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.2 => 4.3.40-dfsg-0ubuntu14.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.37.3]
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.4 => 4.3.40-dfsg-0ubuntu1.14.04.1~14.04.4] (no packageset)
<doko> LocutusOfBorg: looking at the virtualbox ftbfs in 18.04 with openjdk-11. Would it be ok to backport the disco version to bionic, and if yes, what could break?
-queuebot:#ubuntu-release- Unapproved: base-files (trusty-proposed/main) [7.2ubuntu5.5 => 7.2ubuntu5.6] (core)
-queuebot:#ubuntu-release- New binary: libxcb [arm64] (bionic-proposed/main) [1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted squid [source] (cosmic-proposed) [4.1-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.4 => 4.3.40-dfsg-0ubuntu1.14.04.1~14.04.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virt-manager [source] (bionic-proposed) [1:1.5.1-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (cosmic-proposed) [3.30.2-1~ubuntu18.10.4]
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.8 => 239-7ubuntu10.9] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.13 => 237-3ubuntu10.14] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.16 => 229-4ubuntu21.17] (core)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Trusty 14.04.6] (20101020ubuntu318.45) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Trusty 14.04.6] (20101020ubuntu318.45) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Trusty 14.04.6] (20101020ubuntu318.45) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Trusty 14.04.6] (20101020ubuntu318.45) has been added
<ddstreet> vorlon as you're the sru vanguard backup today, can you review/approve the systemd uploads to x/b/c please
<vorlon> ddstreet: is this something that warrants jumping the queue?
<ddstreet> it's for 3 bugs which have been waiting anywhere from 1 to multiple months
<ddstreet> and as we know, the 'queue' isn't processed linearly :)
<ddstreet> so yes, please jump the queue for it
<vorlon> it certainly is processed linearly by me on my vanguard day, unless there's an overriding reason
<ddstreet> k, well all i can do is ask you
<vorlon> "the bugs are old" isn't an overriding reason. "we have a customer deadline" would be an overriding reason :)
<vorlon> (or also, "this is the only window we have to get these changes in before CVEs stomp on us again")
<ddstreet> well our upload queues have stuff waiting over a month, so if you really only process it linearly, then i'd expect this to get approved sometime in april ;-)
<ddstreet> with systemd, every minute counts, as security releases come regularly
<ddstreet> i have no specific knowledge for when a systemd security release is coming up, but i am fairly sure that next week is clear.  after that, not sure, which is why i'd like to get it into -proposed today
<vorlon> ack
<gaughen> vorlon, these are the systemd issues we'd talked about last week at the sprint, and they do need to move quickly
<gaughen> vorlon, remember that passionate discussion?
<gaughen> ;-)
<vorlon> gaughen: yep - just wasn't sure it was connected to this particular upload :)
<gaughen> I think most of SEG has PTSD
<gaughen> :-)
<vorlon> anyway, I'm going to do some processing of the older stuff in the queue, but I'll be sure to get to systemd before EOD
<vorlon> ddstreet: ^^ if that's ok?
<gaughen> thank you vorlon!
<ddstreet> thnx vorlon
-queuebot:#ubuntu-release- New: accepted node-autoprefixer [amd64] (disco-proposed) [8.6.5-2]
-queuebot:#ubuntu-release- New: accepted libxcb [amd64] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New: accepted libxcb [armhf] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New: accepted libxcb [ppc64el] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New: accepted libxcb [arm64] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New: accepted libxcb [s390x] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- New: accepted libxcb [i386] (bionic-proposed) [1.13-2~ubuntu18.04]
-queuebot:#ubuntu-release- Unapproved: accepted partman-efi [source] (cosmic-proposed) [71ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: gnome-software (cosmic-proposed/main) [3.30.2-0ubuntu9 => 3.30.2-0ubuntu10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: debian-installer (trusty-proposed/main) [20101020ubuntu318.45 => 20101020ubuntu318.46] (core)
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (trusty-proposed) [7.2ubuntu5.6]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (trusty-proposed) [7.2ubuntu5.6]
<vorlon> cpaelzer: open-vm-tools includes a packaging change to try to modprobe vmgfx unconditionally when the open-vm-tools-desktop package is installed.  I think this is a packaging change that requires a separate SRU bug
-queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (cosmic-proposed) [2:10.3.5-6~ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (cosmic-proposed) [3.30.2-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (cosmic-proposed) [1.1.2-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1ubuntu0.18.10.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [source] (cosmic-proposed) [2.5.1-5ubuntu4.2]
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1ubuntu0.18.10.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1ubuntu0.18.10.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (cosmic-proposed/main) [1.2 => 1.2ubuntu0.1] (desktop-core)
<vorlon> xnox: your ruby2.5 SRU upload synced from a bileto ppa and built with a wrong -v can die in a fire
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [sync] (bionic-proposed) [2.5.1-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [source] (bionic-proposed) [2.5.1-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (cosmic-proposed) [1.1.2-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (cosmic-proposed) [1.1.2-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (cosmic-proposed) [1.1.2-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1ubuntu0.18.10.1 => 1.1.2-1ubuntu0.18.10.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected openssl1.0 [source] (cosmic-proposed) [1.0.2n-1ubuntu6.2]
-queuebot:#ubuntu-release- Unapproved: rejected openssl1.0 [source] (bionic-proposed) [1.0.2n-1ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: accepted glewmx [source] (cosmic-proposed) [1.13.0-4ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted glewmx [source] (bionic-proposed) [1.13.0-4ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (trusty-proposed) [20101020ubuntu318.46]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (cosmic-proposed) [1.1.2-1ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (cosmic-proposed) [1.2ubuntu0.1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Trusty 14.04.6] has been updated (20101020ubuntu318.46)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Trusty 14.04.6] has been updated (20101020ubuntu318.46)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Trusty 14.04.6] has been updated (20101020ubuntu318.46)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Trusty 14.04.6] has been updated (20101020ubuntu318.46)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (cosmic-proposed) [1:6.1.5-0ubuntu0.18.10.1]
<vorlon> LocutusOfBorg: you synced a lintian and its autopkgtests have regressed because they now take forever and timeout, are you looking into this?
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.5-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (cosmic-proposed) [5.11.1+dfsg-7ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (cosmic-proposed) [2:13.0.3-0ubuntu1]
<vorlon> coreycb: LP: #1815948 is still awaiting verification in cosmic-proposed, are you going to verify that before horizon 3:14.0.2-0ubuntu1 goes in?
<ubot5> Launchpad bug 1815948 in horizon (Ubuntu Cosmic) "[SRU] Upgrade from queens py2 -> rocky py2 packages breaks /usr/share/openstack-dashboard/openstack_dashboard" [High,Fix committed] https://launchpad.net/bugs/1815948
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (cosmic-proposed) [2.19.1-0ubuntu1]
<vorlon> rharper: you have a lot of bugs linked from the changelog of this curtin/cosmic SRU, without SRU templates
<vorlon> ddstreet, slashd: LP: #1755863 the bug description says 'casper is masking a mounted NFS share' but I don't see any code in casper which does this?
<ubot5> Launchpad bug 1755863 in systemd (Ubuntu Cosmic) "netbooting the bionic live CD over NFS goes straight to maintenance mode :" [Medium,In progress] https://launchpad.net/bugs/1755863
<vorlon> ddstreet: LP: #1812760, two of the patches relate to not dropping addresses/routes on networkd restart, but the test case doesn't do anything at all with restarting networkd
<ubot5> Launchpad bug 1812760 in systemd (Ubuntu Cosmic) "networkd: [Route] PreferredSource not working in *.network files" [Medium,In progress] https://launchpad.net/bugs/1812760
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (trusty-proposed/universe) [1.0.0-0ubuntu1~14.04.2 => 1.0.0-0ubuntu4~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (xenial-proposed/universe) [1.0.0-0ubuntu1~16.04.1 => 1.0.0-0ubuntu4~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/universe) [1.0.0-0ubuntu1~18.04.1 => 1.0.0-0ubuntu4~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (cosmic-proposed/universe) [1.0.0-0ubuntu1~18.10.1 => 1.0.0-0ubuntu4~18.10.0] (no packageset)
#ubuntu-release 2019-03-02
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.9]
<ddstreet> vorlon lp #1755863 was worked by vtapia who is out on vac for the next weekish, but i think he actually mean cdrom.mount not nfs
<ubot5> Launchpad bug 1755863 in systemd (Ubuntu Bionic) "netbooting the bionic live CD over NFS goes straight to maintenance mode :" [Medium,In progress] https://launchpad.net/bugs/1755863
<ddstreet> casper does mask cdrom.mount
<vorlon> right, I do see that
<vorlon> anyway, accepted cosmic at this point, going through the others now
<ddstreet> re: lp #1812760 the instructions say to either netplan apply, or reboot, both of which restart systemd
<ubot5> Launchpad bug 1812760 in systemd (Ubuntu Bionic) "networkd: [Route] PreferredSource not working in *.network files" [Medium,In progress] https://launchpad.net/bugs/1812760
<ddstreet> restart systemd-networkd, i should say
<ddstreet> thnx
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.14]
<vorlon> ah, didn't realize there's an actual restart in there
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.17]
-queuebot:#ubuntu-release- New: accepted libsodium [source] (trusty-proposed) [1.0.8-5~ubuntu14.04.1]
-queuebot:#ubuntu-release- New binary: libsodium [arm64] (trusty-proposed/universe) [1.0.8-5~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsodium [armhf] (trusty-proposed/universe) [1.0.8-5~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsodium [arm64] (trusty-proposed) [1.0.8-5~ubuntu14.04.1]
-queuebot:#ubuntu-release- New: accepted libsodium [armhf] (trusty-proposed) [1.0.8-5~ubuntu14.04.1]
-queuebot:#ubuntu-release- New: accepted python-libnacl [source] (trusty-proposed) [1.4.5-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (bionic-proposed) [2:10.3.5-6~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted pymacaroons [source] (trusty-proposed) [0.9.2-0ubuntu1~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.37.3+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.18-dfsg-3~ubuntu18.04.2]
<vorlon> anyone know how xdg-desktop-portal 1.0.3-0ubuntu0.0 got into xenial-proposed without any comments on the bug or without bionic being accepted?
<vorlon> ah, it's a new package in xenial
<doko> please ignore the picard-tools/i386 test failure. the package is now amd64 only
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (cosmic-proposed/universe) [5.11.1+dfsg-2ubuntu4 => 5.11.1+dfsg-2ubuntu4.1] (kubuntu)
#ubuntu-release 2019-03-03
-queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu2.3 => 2.2.7-1ubuntu2.4] (core)
-queuebot:#ubuntu-release- New sync: netkit-ftp-ssl (disco-proposed/primary) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New binary: piuparts [amd64] (disco-proposed/universe) [0.98] (no packageset)
<LocutusOfBorg> vorlon, the reason for the lintian sync was to try to unblock the current proposed version, suffering from the very same issue... can't we move the package to some testing system with more computational power? it is a regression in release, from what I can see in arm64 backlog
<vorlon> LocutusOfBorg: why *should* we move it to runners with more compute?  Why does lintian need a test suite that exceeds glibc's in runtime?
<jbicha> vorlon: please remove birdtray/s390x from disco-proposed.  birdtray is now correctly not built on s390x since thunderbird is not available there currently
<vorlon> jbicha: done
<mwhudson> vorlon: where is the glibc transtition out of curiosity? i think i've seen chatter that the failing tests are going to get badtest-ed
<mwhudson> maybe not postgresql-hll
<vorlon> mwhudson: I only know of chatter about glibc's own autopkgtest regressions getting badtested. I don't know if infinity has analyzed postgresql-hll and python-biopython
<mwhudson> k
<mwhudson> postgresql-hll looks a bit interesting
<mwhudson> biopython is the AssertionError: 188.51403793245183 != 188.51404344898586 within 5 places one
<jbicha> it looks like the poppler transition needs to be completed for glibc to migrate
<vorlon> mwhudson: yeah, the implementation of that takes the difference between the two values and checks that it's < 0.00001, which in this case it's not.  So even though the values both round to the same thing, the test fails, which I'm not sure if that is or isn't sane
<mwhudson> vorlon: it seems _unlikely_ to be the result of a change in behaviour of glibc that should cause concern but i guess that does need to be verified
<mwhudson> in other news, linux block devices are terrible
-queuebot:#ubuntu-release- New source: flatbuffers (disco-proposed/primary) [1.10.0+dfsg1-0ubuntu1]
#ubuntu-release 2020-02-24
-queuebot:#ubuntu-release- New: accepted openssh [arm64] (focal-proposed) [1:8.2p1-1]
-queuebot:#ubuntu-release- New: accepted python-questplus [s390x] (focal-proposed) [2019.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lavasearch2 [s390x] (focal-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted openssh [armhf] (focal-proposed) [1:8.2p1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lavasearch2 [ppc64el] (focal-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted openssh [amd64] (focal-proposed) [1:8.2p1-1]
-queuebot:#ubuntu-release- New: accepted openssh [s390x] (focal-proposed) [1:8.2p1-1]
-queuebot:#ubuntu-release- New: accepted python-questplus [armhf] (focal-proposed) [2019.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lavasearch2 [amd64] (focal-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lavasearch2 [armhf] (focal-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted openssh [ppc64el] (focal-proposed) [1:8.2p1-1]
-queuebot:#ubuntu-release- New: accepted python-questplus [ppc64el] (focal-proposed) [2019.4-1]
-queuebot:#ubuntu-release- New: accepted python-questplus [arm64] (focal-proposed) [2019.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lavasearch2 [arm64] (focal-proposed) [1.5.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jcmturner-gofork [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-errgo.v2 [amd64] (focal-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-jcmturner-aescts.v1 [amd64] (focal-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-jcmturner-goidentity.v2 [amd64] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-questplus [amd64] (focal-proposed) [2019.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-karrick-godirwalk [amd64] (focal-proposed) [1.15.3-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-jcmturner-dnsutils.v1 [amd64] (focal-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted zshdb [amd64] (focal-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-hlandau-acmeapi.v2 [amd64] (focal-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-jcmturner-rpc.v0 [amd64] (focal-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New binary: r-cran-kutils [amd64] (focal-proposed/universe) [1.69+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: profanity [amd64] (focal-proposed/universe) [0.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: profanity [ppc64el] (focal-proposed/universe) [0.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: profanity [s390x] (focal-proposed/universe) [0.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: profanity [arm64] (focal-proposed/universe) [0.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: profanity [armhf] (focal-proposed/universe) [0.8.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted profanity [arm64] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- New: accepted profanity [s390x] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- New: accepted profanity [armhf] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- New: accepted profanity [amd64] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- New: accepted r-cran-kutils [amd64] (focal-proposed) [1.69+dfsg-2]
-queuebot:#ubuntu-release- New: accepted profanity [ppc64el] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- New binary: r-cran-rockchalk [amd64] (focal-proposed/universe) [1.8.144+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [212-1~ubuntu19.04.1 => 213-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (eoan-backports/universe) [212-1~ubuntu19.10.1 => 213-1~ubuntu19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [212-1~ubuntu18.04.1 => 213-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [213-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (eoan-backports) [213-1~ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [213-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- New: accepted r-cran-rockchalk [amd64] (focal-proposed) [1.8.144+dfsg-1]
-queuebot:#ubuntu-release- New binary: poppler [s390x] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [amd64] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [armhf] (focal-proposed/main) [0.85.0-1ubuntu1] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (focal-proposed) [0.85.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-rogpeppe-go-internal [amd64] (focal-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rogpeppe-go-internal [ppc64el] (focal-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rogpeppe-go-internal [s390x] (focal-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rogpeppe-go-internal [arm64] (focal-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-rogpeppe-go-internal [armhf] (focal-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu6 => 0.09.25-1ubuntu8] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1.5]
-queuebot:#ubuntu-release- New: accepted golang-github-rogpeppe-go-internal [amd64] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rogpeppe-go-internal [armhf] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rogpeppe-go-internal [s390x] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rogpeppe-go-internal [arm64] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-rogpeppe-go-internal [ppc64el] (focal-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- Unapproved: stress-ng (eoan-proposed/universe) [0.10.07-1ubuntu3 => 0.10.07-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-semplot [amd64] (focal-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymupdf [amd64] (focal-proposed/universe) [1.16.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymupdf [s390x] (focal-proposed/universe) [1.16.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymupdf [ppc64el] (focal-proposed/universe) [1.16.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymupdf [armhf] (focal-proposed/universe) [1.16.11-1] (no packageset)
<cpaelzer> is an archive admin around to do two Binary only movements to universe as shown in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<cpaelzer> qemu-system-x86-microvm and vlan - both are intentional
-queuebot:#ubuntu-release- New binary: pymupdf [arm64] (focal-proposed/universe) [1.16.11-1] (no packageset)
<cpaelzer> if you need a bug for it, this https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1856279 was about cutting the last few dependencies
<ubot5> Ubuntu bug 1856279 in Ubuntu Cloud Archive "demote vlan to universe in 20.04" [High,Fix committed]
<apw> cpaelzer, looking
<cpaelzer> thanks apw, if there are any questions let me know
<apw> cpaelzer, done
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [s390x] (focal-proposed/main) [3.35.91-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [amd64] (focal-proposed/main) [3.35.91-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [ppc64el] (focal-proposed/main) [3.35.91-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [arm64] (focal-proposed/main) [3.35.91-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-desktop3 [armhf] (focal-proposed/main) [3.35.91-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [amd64] (focal-proposed) [3.35.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [armhf] (focal-proposed) [3.35.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [s390x] (focal-proposed) [3.35.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [arm64] (focal-proposed) [3.35.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-desktop3 [ppc64el] (focal-proposed) [3.35.91-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1041.46] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1041.46]
-queuebot:#ubuntu-release- New: accepted pymupdf [amd64] (focal-proposed) [1.16.11-1]
-queuebot:#ubuntu-release- New: accepted pymupdf [armhf] (focal-proposed) [1.16.11-1]
-queuebot:#ubuntu-release- New: accepted pymupdf [s390x] (focal-proposed) [1.16.11-1]
-queuebot:#ubuntu-release- New: accepted pymupdf [arm64] (focal-proposed) [1.16.11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-semplot [amd64] (focal-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted pymupdf [ppc64el] (focal-proposed) [1.16.11-1]
<jamespage> afternoon
<jamespage> please can the ceph in bionic/unapproved be rejected - I'd like to include a cherry pick for another issue
<apw> jamespage, looking
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (bionic-proposed) [12.2.13-0ubuntu0.18.04.1]
<apw> jamespage, ^
<jamespage> apw: pls can you do the one in eoan as well :) thankyou btw
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (eoan-proposed) [14.2.7-0ubuntu0.19.10.1]
<apw> jamespage, ^
<jamespage> apw: thankyou very much !
<vorlon> doko: the behavior of compile() seems to have changed from python3.7 to python3.8 in ways that are breaking sphinx gallery stuff; do you have any ideas on this?  https://launchpad.net/ubuntu/+source/astropy/4.0-4/+build/18740142
-queuebot:#ubuntu-release- New binary: remmina [s390x] (focal-proposed/main) [1.4.1+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [ppc64el] (focal-proposed/main) [1.4.1+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: mozjs68 (focal-proposed/primary) [68.5.0-1~fakesync]
<vorlon> doko: note that astropy holds up the icu transition via wcslib->casacore
-queuebot:#ubuntu-release- New binary: remmina [armhf] (focal-proposed/main) [1.4.1+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [amd64] (focal-proposed/main) [1.4.1+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [arm64] (focal-proposed/main) [1.4.1+dfsg-1ubuntu1] (ubuntu-desktop)
<RikMills> looks similar to the sphinx-gallery errors matplotlib had
-queuebot:#ubuntu-release- New: accepted mozjs68 [source] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (eoan-proposed) [18.01-0ubuntu9.2]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (bionic-proposed) [18.01-0ubuntu3.5]
-queuebot:#ubuntu-release- New binary: mozjs68 [s390x] (focal-proposed/main) [68.5.0-1~fakesync] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs68 [ppc64el] (focal-proposed/main) [68.5.0-1~fakesync] (no packageset)
<hellsworth> hey folks. looking at the autopkgtest failures libreoffice is seeing (http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64), it looks like all of the failed ones are taking the same amount of time to fail and they're failing with "ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'"
<hellsworth> example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/libr/libreoffice/20200222_190130_26661@/log.gz
<hellsworth> any thoughts on what might be the cause?
<Laney> yeah
<Laney> it copies the unpacked source tree back to the host which is controlling the tests
<Laney> and this takes too long for the timeout
-queuebot:#ubuntu-release- New binary: mozjs68 [amd64] (focal-proposed/main) [68.5.0-1~fakesync] (no packageset)
<Laney> perhaps we should bump that, but I don't know how far off it was ...
<hellsworth> what do you mean by bump it?
<Laney> increase
<hellsworth> oh increase the timeout
<Laney> https://paste.ubuntu.com/p/h8NpbXQhzw/
<Laney> something like that
<hellsworth> i can imagine that as LO releases continue, the source tree will likely grow in size, perpetuating this problem
<Laney> the problem is worse when there are many tests running at once
<Laney> because they all end up copying at the same time which means they all go slower
<Laney> then timeout, restart, reach the copying part at the same time ...
<hellsworth> ok that makes sense. so when are there the least number of tests running in the day?
<Laney> we've got plans to work on parallelising the test runner itself for pretty much exactly this problem, but it's not implemented yet
<hellsworth> ok so restart the tests until they get past this point
<Laney> no particular time, but you can see the queue on http://autopkgtest.ubuntu.com/running
<hellsworth> but if i know when they are most likely to pass, i can angle to get them running then
<hellsworth> ok cool
<Laney> if there's a non empty queue then it probably means all the capacity is in use -> this problem might be more likely to occur
<Laney> however most packages are trivial in size
<Laney> but you can see right now that a lot of LO runs are happening simultaneously...
<Laney> if the last line in the log is "build not needed" then it's doing this copying thing
<hellsworth> what does the triggers mean exactly?
<hellsworth> so i see that LO triggers icu. does that mean that it triggers the build of icu?
<Laney> it means that uploading ICU triggered a test run of libreoffice
<Laney> because LO depends on ICU
<hellsworth> ok thanks
<hellsworth> so is the best thing to do is to just run each of these http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64, one at a time?
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ pgrep -cf tar
<Laney> 34
 * Laney hugs that machine's poor NIC
<Laney> and/or vCPUs
<Laney> I'd wait until most of those in progress runs have cleared out before trying any new ones
<Laney> and be guided by what's red on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Laney> I will increase the copy timeout too, it's best to have the machine be slow for longer one time than slow for shorter many times I think
<hellsworth> okey dokey thanks for the advice and increasing the copy timeout :)
<Laney> sure
<Laney> like I say, no idea if it's going to help because we don't know how far it's getting in the current timeout
<Laney> hopefully 20,000 seconds = 5 hours 33 minutes should be enough ...
<hellsworth> yeah hopefully, i'll keep an eye on the red ones and we'll see
-queuebot:#ubuntu-release- New binary: mozjs68 [armhf] (focal-proposed/main) [68.5.0-1~fakesync] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs68 [arm64] (focal-proposed/main) [68.5.0-1~fakesync] (no packageset)
<Laney> Does seeding by regex not work with component-mismatches or did I make a mistake? I've seeded /^oem-.+-meta$/ and I was hoping for it to show up there but it hasn't.
<Laney> Perhaps we just have to promote and then it won't be nominated for demotion?
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (eoan-proposed) [3.9-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.9-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: azure-data-lake-store-python [amd64] (focal-proposed/none) [0.0.48-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libobject-lazy-perl [amd64] (focal-proposed/none) [0.15-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jaro-winkler [amd64] (focal-proposed/none) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liboptimade-filter-perl [amd64] (focal-proposed/none) [0.7.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgit-annex-perl [amd64] (focal-proposed/none) [0.001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-mojo-magick [amd64] (focal-proposed/none) [0.5.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-nfqueue [amd64] (focal-proposed/none) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-ponder [amd64] (focal-proposed/none) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jaro-winkler [ppc64el] (focal-proposed/none) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-pastel [amd64] (focal-proposed/none) [0.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-necromancer [amd64] (focal-proposed/none) [0.5.1-1] (no packageset)
<Laney> cjwatson: ^- maybe you know? (sorry to ping about a release-related thing ...)
<cjwatson> I don't know why that wouldn't work, but I may also be forgetful
<cjwatson> You may need to go through germinate output logs
-queuebot:#ubuntu-release- New: accepted azure-data-lake-store-python [amd64] (focal-proposed) [0.0.48-1]
-queuebot:#ubuntu-release- New: accepted libobject-lazy-perl [amd64] (focal-proposed) [0.15-2]
-queuebot:#ubuntu-release- New: accepted ruby-jaro-winkler [amd64] (focal-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-mojo-magick [amd64] (focal-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- New: accepted ruby-nfqueue [amd64] (focal-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-ponder [amd64] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted libgit-annex-perl [amd64] (focal-proposed) [0.001-1]
-queuebot:#ubuntu-release- New: accepted ruby-jaro-winkler [ppc64el] (focal-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-pastel [amd64] (focal-proposed) [0.7.3-1]
-queuebot:#ubuntu-release- New: accepted liboptimade-filter-perl [amd64] (focal-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-necromancer [amd64] (focal-proposed) [0.5.1-1]
<Laney> I can't see anything mentioning this line in there, but it is in the .seedtext file
<Laney> Maybe someone could try promoting oem-qemu-meta and we'll see if c-m complains the other way..?
-queuebot:#ubuntu-release- New binary: azure-uamqp-python [amd64] (focal-proposed/universe) [1.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-colored2 [amd64] (focal-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-cursor [amd64] (focal-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-uamqp-python [ppc64el] (focal-proposed/universe) [1.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-screen [amd64] (focal-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rushover [amd64] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbio-alignio-stockholm-perl [amd64] (focal-proposed/universe) [1.7.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-espeak [amd64] (focal-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xr-el [amd64] (focal-proposed/universe) [1.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagure [amd64] (focal-proposed/universe) [5.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-wisper [amd64] (focal-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-e2mmap [amd64] (focal-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-sync [amd64] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-which [amd64] (focal-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jaro-winkler [s390x] (focal-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-uamqp-python [s390x] (focal-proposed/universe) [1.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: psychopy [amd64] (focal-proposed/universe) [2020.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: coq [s390x] (focal-proposed/universe) [8.9.1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jaro-winkler [arm64] (focal-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jaro-winkler [armhf] (focal-proposed/universe) [1.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-uamqp-python [arm64] (focal-proposed/universe) [1.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-uamqp-python [armhf] (focal-proposed/universe) [1.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: coq [ppc64el] (focal-proposed/universe) [8.9.1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mozjs68 [amd64] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- New: accepted mozjs68 [armhf] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- New: accepted mozjs68 [s390x] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- New: accepted ruby-e2mmap [amd64] (focal-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jaro-winkler [arm64] (focal-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-jaro-winkler [s390x] (focal-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-sync [amd64] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-tty-screen [amd64] (focal-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-wisper [amd64] (focal-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted mozjs68 [arm64] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- New: accepted ruby-colored2 [amd64] (focal-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-jaro-winkler [armhf] (focal-proposed) [1.5.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-tty-cursor [amd64] (focal-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted xr-el [amd64] (focal-proposed) [1.15-1]
-queuebot:#ubuntu-release- New: accepted mozjs68 [ppc64el] (focal-proposed) [68.5.0-1~fakesync]
-queuebot:#ubuntu-release- New: accepted ruby-rushover [amd64] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-espeak [amd64] (focal-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-tty-which [amd64] (focal-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted remmina [amd64] (focal-proposed) [1.4.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [armhf] (focal-proposed) [1.4.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [s390x] (focal-proposed) [1.4.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [arm64] (focal-proposed) [1.4.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [ppc64el] (focal-proposed) [1.4.1+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted azure-uamqp-python [amd64] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- New: accepted azure-uamqp-python [armhf] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- New: accepted azure-uamqp-python [s390x] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- New: accepted azure-uamqp-python [arm64] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- New: accepted libbio-alignio-stockholm-perl [amd64] (focal-proposed) [1.7.3-1]
-queuebot:#ubuntu-release- New: accepted azure-uamqp-python [ppc64el] (focal-proposed) [1.2.6-1]
-queuebot:#ubuntu-release- New: accepted coq [ppc64el] (focal-proposed) [8.9.1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted pagure [amd64] (focal-proposed) [5.8.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted coq [s390x] (focal-proposed) [8.9.1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted psychopy [amd64] (focal-proposed) [2020.1.1+dfsg-1]
<doko> vorlon, RikMills: how was that fixed in matplotlib?
<vorlon> doko: I don't know that it was fixed
<RikMills> doko: oh, lol https://launchpad.net/ubuntu/+source/matplotlib/3.1.2-1ubuntu1
<RikMills> I remembered seeing it fixed, just not that....
<vorlon> hmm so doesn't that mean doc generation is incomplete?
-queuebot:#ubuntu-release- New binary: ruby-qr4r [amd64] (focal-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-reader [amd64] (focal-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-thwait [amd64] (focal-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-spinner [amd64] (focal-proposed/universe) [0.9.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-qr4r [amd64] (focal-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-tty-reader [amd64] (focal-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-thwait [amd64] (focal-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-tty-spinner [amd64] (focal-proposed) [0.9.3-1]
-queuebot:#ubuntu-release- New binary: coccinelle [amd64] (focal-proposed/universe) [1.0.4.deb-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: coccinelle [ppc64el] (focal-proposed/universe) [1.0.4.deb-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted coccinelle [amd64] (focal-proposed) [1.0.4.deb-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted coccinelle [ppc64el] (focal-proposed) [1.0.4.deb-5ubuntu1]
<xnox> vorlon:  so arm64 instances fail to boot? see libreoffice failing on arm64, should that be escalated to the kernel team? or is that flash-kernel / initramfs-tools fall out?
<vorlon> xnox: see Laney's comments in scrollback
<vorlon> he has a different analysis of the overall problem
<xnox> vorlon:  can icu skiptest the libreoffice on arm64 then?
<vorlon> xnox: when I get to it
<xnox> vorlon:  would it migrate, or should php transition start?
<xnox> cause otherwise php will entangle with icu
<vorlon> xnox: it won't migrate; are you tracking update_output / update_output_notest?  See my comments above about astropy
<vorlon> and no we shouldn't be uploading any packages currently tangled in icu for the php transition until icu is done
<vorlon> xnox: icu hinted. but wcslib needs to be migrated before boost+icu, because of casacore->boost-python3.8
<vorlon> xnox: thus we need a fix for the sphinx-gallery stuff on astropy
<vorlon> xnox: rdkit is also a blocker
<rharper> sil2100: hi,   the curtin SRU is now verified and ready for release, please take a look if you can, https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-02-14 - 19.3-26-g82f23e3d-0ubuntu1" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu18 => 2.04-1ubuntu19] (core)
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (eoan-proposed) [2.62.4-1~ubuntu19.10.1]
-queuebot:#ubuntu-release- New binary: ocaml-usb [ppc64el] (focal-proposed/universe) [1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-usb [s390x] (focal-proposed/universe) [1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu19 => 2.04-1ubuntu19] (core)
-queuebot:#ubuntu-release- New binary: ocaml-usb [amd64] (focal-proposed/universe) [1.3.1-3] (no packageset)
<ahasenack> hi, I want to upload sssd, but don't want to get in the way of these transitions going on, how can I be sure?
-queuebot:#ubuntu-release- New binary: ocsigenserver [ppc64el] (focal-proposed/universe) [2.16.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocsigenserver [s390x] (focal-proposed/universe) [2.16.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-usb [arm64] (focal-proposed/universe) [1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocsigenserver [amd64] (focal-proposed/universe) [2.16.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-usb [armhf] (focal-proposed/universe) [1.3.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-usb [amd64] (focal-proposed) [1.3.1-3]
-queuebot:#ubuntu-release- New: accepted ocaml-usb [armhf] (focal-proposed) [1.3.1-3]
-queuebot:#ubuntu-release- New: accepted ocaml-usb [s390x] (focal-proposed) [1.3.1-3]
-queuebot:#ubuntu-release- New: accepted ocsigenserver [ppc64el] (focal-proposed) [2.16.0-2]
-queuebot:#ubuntu-release- New: accepted ocaml-usb [arm64] (focal-proposed) [1.3.1-3]
-queuebot:#ubuntu-release- New: accepted ocsigenserver [amd64] (focal-proposed) [2.16.0-2]
-queuebot:#ubuntu-release- New: accepted ocaml-usb [ppc64el] (focal-proposed) [1.3.1-3]
-queuebot:#ubuntu-release- New: accepted ocsigenserver [s390x] (focal-proposed) [2.16.0-2]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1010.11~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1034.37] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1012.17] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tty-prompt [amd64] (focal-proposed/universe) [0.20.0-1] (no packageset)
<ahasenack> sssd not mentioned in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#icu
 * ahasenack will upload
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1012.17]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1034.37]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1010.11~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (eoan-proposed) [2.12.0-0ubuntu1.1]
<vorlon> ahasenack: if there isn't already a version of the package in -proposed, you don't need to worry about it being part of the transition
<vorlon> ahasenack: if there is a version of the package in -proposed, it's part of the transition if its excuses entry mentions Depends: foo icu (or one of the other packages involved in the transition)
-queuebot:#ubuntu-release- Unapproved: accepted spamassassin [source] (eoan-proposed) [3.4.2-1ubuntu0.19.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted spamassassin [source] (bionic-proposed) [3.4.2-0ubuntu0.18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted spamassassin [source] (xenial-proposed) [3.4.2-0ubuntu0.16.04.4]
-queuebot:#ubuntu-release- New: accepted ruby-tty-prompt [amd64] (focal-proposed) [0.20.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted quassel [source] (eoan-proposed) [1:0.13.1-1ubuntu1.19.10.1]
<blackboxsw> RAOF: I'm not sure if you are 'on' for SRU reviews for today, but I wanted to check whether some SRU eyes could land on the unattended-upgrades SRU queued related to Xenial, Bionic and Eoan https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051
<ubot5> Ubuntu bug 1857051 in unattended-upgrades (Ubuntu Eoan) "Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)" [Undecided,Fix committed]
<blackboxsw> I've completed verification for that apt config change
<RAOF> blackboxsw: I celebrate US Tuesday for my SRU rotation (ie: actually tomorrow). But I'll happily have a look at that now!
<blackboxsw> sweet RAOF I was uncertain and was just pondering that. and Thanks! I celebrate US tuesdays too, but only because it's trash collection day and I get the esteemed responsibility of wheeling out the garbage :)
<doko> vorlon, xnox: ignoring the example docs build failure, lets the if the current astropy passes autopkg tests
<ahasenack> vorlon: thx
<vorlon> doko: yeah, you beat me to the upload.  But what about the actual behavior change in python?  I'm not sure if this is a sphinx or python bug
-queuebot:#ubuntu-release- Unapproved: accepted quassel [source] (bionic-proposed) [1:0.12.4-3ubuntu1.18.04.1]
<RAOF> Hm. Has `sru-release` hung, or is it just speaking to launchpad.net over tin cans and string?
<cjwatson> RAOF: LP is down due to a GS2 network outage; see #is-outage internal
<RAOF> Ah, good. I'll stop trying to release things then.
<cjwatson> "good"
<cjwatson> but yes
#ubuntu-release 2020-02-25
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.620 => 2.620.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.164 => 0.175ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [amd64] (focal-proposed) [2.04-1ubuntu19]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [arm64] (focal-proposed) [2.04-1ubuntu19]
<mwhudson> did britney get wedged by the outage or something?
<mwhudson> excuses is about 3 hours old
<mwhudson> vorlon: ^
<vorlon> mwhudson: probably; I was about to check on it
<vorlon> britney actually not currently running
<vorlon> so possibly a dead lockfile somewhere
<vorlon> bzr locks in the b1 checkout :P
<mwhudson> vorlon: orsum
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (eoan-proposed) [1.0.0~rc10-0ubuntu1~19.10.1]
<vorlon> mwhudson: first real run appears to be going now since 01:54 UTC; last two runs after I broke the lock both failed talking to swift
<vorlon> hopefully the network problems are settled enough now
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (bionic-proposed) [1.0.0~rc10-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: libxmlada [amd64] (focal-proposed/universe) [19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [s390x] (focal-proposed/universe) [19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [ppc64el] (focal-proposed/universe) [19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [armhf] (focal-proposed/universe) [19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [arm64] (focal-proposed/universe) [19-2] (no packageset)
<vorlon> xnox: had you looked at odil previously?  It uses d-shlibs, and winds up with a dependency from libodil-dev to libboost-log-dev but libboost-filesystem1.71-dev, which somehow confuses britney (AFAICS it's fixed by including both odil and boost-defaults in the hint, so maybe that's a manual fix-up for when everything else is ready)
<vorlon> xnox: rdkit/arm64 looks like it got caught up in the lp outage (no build log).  retried
-queuebot:#ubuntu-release- New binary: golang-github-yuin-goldmark-highlighting [amd64] (focal-proposed/universe) [0.0~git20200218.d1af22c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1034.37~16.04.1] (kernel)
<LocutusOfBorg> vorlon, missing build on i386: ocamlweb (from 1.41-3)
<LocutusOfBorg>  please?
<LocutusOfBorg> also missing build on i386: liblwt-ocaml-doc (from 2.7.1-7ubuntu2)
<LocutusOfBorg> apw, can I get a test forget for morbig ppc64el please? it passed because of a wrong return 0 in testsuite, I don't want to carry-forever a delta for something that always failed and debian fails too https://ci.debian.net/packages/m/morbig/
<LocutusOfBorg> btw, it is tracked upstream https://github.com/ocaml/ocaml/issues/9137
<gitbot> ocaml issue 9137 in ocaml "ppc64el: compilation of a C program against the C API of morbig fails" [Open]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1034.37~16.04.1]
<apw> LocutusOfBorg: sounds sensible, do you know the first post return 0 version?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/m/morbig/disco/ppc64el
<LocutusOfBorg> apw, 0.9.1-1 should be the first version that introduced the new test
<LocutusOfBorg> +  * debian/tests: add a test for the C API
<apw> looking for the version which went from good to fail
<LocutusOfBorg> 0.9.1-1
<Laney> sil2100: hey, just noticed a bug in the SRU regression comments ;-)
<Laney> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1848202 <- comment #10 was about the wrong version, I think it fails to pick up re-uploads properly
<ubot5> Ubuntu bug 1848202 in glib2.0 (Ubuntu Eoan) "Use after free in gdbus leads to eds segfaults" [Undecided,Fix committed]
<Laney> there are actually many more failures than that, but it looks like there was a network incident at the time ...
<apw> LocutusOfBorg, ok in theory that is hinted
<Laney> apw: fancy doing your pal Laney a favour and promoting oem-qemu-meta to main? it is covered by https://wiki.ubuntu.com/MIRTeam/Exceptions/OEM so no MIR needed
<apw> Laney, sure :)
<Laney> thanks!
<apw> Laney, i assume that is your 'test' kit
<Laney> ya
<Laney> you can set some smbios thingies to make it match
<apw> Laney, done (modulo a publisher run)
<Laney> woot
<Laney> so I guess we'll see if c-m tries to get it kicked back out
<LocutusOfBorg> lovely thanks
<cpaelzer> Laney: glad to see this move forward
<sil2100> Laney: oh, hm, indeed looks wrong
<cpaelzer> Laney: do you have anything left in this regard to discuss in todays MIR Team meeting or are you good right now?
<didrocks> Laney: as this is the reference and someone else accepted it, do you plan doing a following upload with the license fix?
<sil2100> Laney: could you fill in a buggy for it against britney? ;)
<sil2100> (once you have a moment)
<Laney> cpaelzer: all good from me
<Laney> didrocks: Yes, don't worry I didn't forget your request, there have been multiple emails about it that you might have seen
<Laney> sil2100: sure!
<didrocks> Laney: thanks, as you are requesting someone else to promote, I was hoping this didnât fall through cracks :)
<Laney> not really, more waiting for a resolution
<sil2100> Thanks o/
<Laney> sil2100: done and subscribed you _o_
-queuebot:#ubuntu-release- New: accepted golang-github-yuin-goldmark-highlighting [amd64] (focal-proposed) [0.0~git20200218.d1af22c-1]
-queuebot:#ubuntu-release- New: accepted libxmlada [arm64] (focal-proposed) [19-2]
-queuebot:#ubuntu-release- New: accepted libxmlada [ppc64el] (focal-proposed) [19-2]
-queuebot:#ubuntu-release- New: accepted libxmlada [amd64] (focal-proposed) [19-2]
-queuebot:#ubuntu-release- New: accepted libxmlada [s390x] (focal-proposed) [19-2]
-queuebot:#ubuntu-release- New: accepted libxmlada [armhf] (focal-proposed) [19-2]
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu20 => 2.04-1ubuntu20] (core)
-queuebot:#ubuntu-release- New binary: pcb-rnd [amd64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcb-rnd [s390x] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcb-rnd [ppc64el] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcb-rnd [armhf] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [amd64] (focal-proposed/universe) [2019-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pcb-rnd [arm64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [s390x] (focal-proposed/universe) [2019-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu20 => 2.04-1ubuntu20] (core)
-queuebot:#ubuntu-release- New: accepted pcb-rnd [amd64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted pcb-rnd [armhf] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted pcb-rnd [s390x] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted pcb-rnd [arm64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New binary: gprbuild [ppc64el] (focal-proposed/universe) [2019-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted pcb-rnd [ppc64el] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted gprbuild [amd64] (focal-proposed) [2019-3]
-queuebot:#ubuntu-release- New: accepted gprbuild [s390x] (focal-proposed) [2019-3]
-queuebot:#ubuntu-release- New: accepted gprbuild [ppc64el] (focal-proposed) [2019-3]
-queuebot:#ubuntu-release- New binary: gprbuild [arm64] (focal-proposed/universe) [2019-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted gprbuild [arm64] (focal-proposed) [2019-3]
<Laney> anyone remember / know how the mirror on nusakan gets updated?
<Laney> is it just from ubuntu-cdimage?
<Laney> yeah, looks like it
<Laney> ah I think there's maybe a stuck image build
<Laney> that seems better
-queuebot:#ubuntu-release- New source: setuptools (focal-proposed/primary) [45.2.0-1]
-queuebot:#ubuntu-release- New: accepted setuptools [source] (focal-proposed) [45.2.0-1]
-queuebot:#ubuntu-release- New binary: ball [s390x] (focal-proposed/universe) [1.5.0+git20180813.37fc53c-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ball [amd64] (focal-proposed/universe) [1.5.0+git20180813.37fc53c-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ball [ppc64el] (focal-proposed/universe) [1.5.0+git20180813.37fc53c-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted ball [amd64] (focal-proposed) [1.5.0+git20180813.37fc53c-4]
-queuebot:#ubuntu-release- New: accepted ball [s390x] (focal-proposed) [1.5.0+git20180813.37fc53c-4]
-queuebot:#ubuntu-release- New: accepted ball [ppc64el] (focal-proposed) [1.5.0+git20180813.37fc53c-4]
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu8.4 => 2.20.11-0ubuntu8.5] (core)
<seb128> apw, hey, could you subscribe kernel-packages to the component listed on https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1862776 ? Anthony pointed out that he can't do it since only you and Brian are member of that team
<ubot5> Ubuntu bug 1862776 in alsa-ucm-conf (Ubuntu) "[MIR] alsa-ucm-conf & alsa-topology-conf (b-d of alsa-lib)" [High,New]
<LocutusOfBorg> apw, can you please try harder with morbig? maybe you need to put a version that exist on focal?
<xnox> apw:  doko: can you please RM pandas from focal-proposed? it only built amd64 & all packages, making pandas uninstallable on all other arches now, causing pain for ocaml transition.
<xnox> it should be fixed not to FTBFS on other arches.
<xnox> or shall i just upload a thing that ignores test failures?
<xnox> hm, maybe not ocaml, but rdkit
<xnox> that's the one
<apw> LocutusOfBorg, to be fair to me, i used the version you said was the last transition from good to bad, which it was not
<apw> LocutusOfBorg, i may have used a better hint this time, or not
<LocutusOfBorg> sorry, I probably misread the request you did, I though the first version being bad (form debian new test), not the last version being good in the history, due to my changes...
-queuebot:#ubuntu-release- New binary: rust-chrono [s390x] (focal-proposed/universe) [0.4.10-2] (no packageset)
<LocutusOfBorg> force-reset-test morbig/0.9.1-3ubuntu20.9.1-3ubuntu2/ppc64el
<LocutusOfBorg> in any case this seems bad...
-queuebot:#ubuntu-release- New binary: rust-chrono [ppc64el] (focal-proposed/universe) [0.4.10-2] (no packageset)
<LocutusOfBorg> 0.9.1-3ubuntu2 is probably the answer I should have provided you, sorry but this is the first time I ask to force-reset
<LocutusOfBorg> apw, ^^
-queuebot:#ubuntu-release- New source: ovn-octavia-provider (focal-proposed/primary) [0.0.1~git2020022414.000049c-0ubuntu1]
<LocutusOfBorg> doko, I think I fixed llvm-toolchain-8-9-10 testsuites, sad news is that I had to upload a new version, so lets wait 24h to know the answer
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8.5]
-queuebot:#ubuntu-release- New binary: rust-chrono [amd64] (focal-proposed/universe) [0.4.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-chrono [arm64] (focal-proposed/universe) [0.4.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-chrono [armhf] (focal-proposed/universe) [0.4.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [ppc64el] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [s390x] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [amd64] (focal-proposed/universe) [19-3] (no packageset)
<doko> xnox: done
-queuebot:#ubuntu-release- New: accepted libgnatcoll [amd64] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [s390x] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted rust-chrono [arm64] (focal-proposed) [0.4.10-2]
-queuebot:#ubuntu-release- New: accepted rust-chrono [ppc64el] (focal-proposed) [0.4.10-2]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [ppc64el] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted rust-chrono [armhf] (focal-proposed) [0.4.10-2]
-queuebot:#ubuntu-release- New: accepted rust-chrono [amd64] (focal-proposed) [0.4.10-2]
-queuebot:#ubuntu-release- New: accepted rust-chrono [s390x] (focal-proposed) [0.4.10-2]
-queuebot:#ubuntu-release- New binary: libgnatcoll [armhf] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [arm64] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgnatcoll [arm64] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [armhf] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New binary: bind9 [s390x] (focal-proposed/main) [1:9.16.0-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [i386] (focal-proposed/main) [1:9.16.0-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (focal-proposed/main) [1:9.16.0-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [amd64] (focal-proposed/main) [1:9.16.0-1ubuntu1] (core, i386-whitelist)
<xnox> doko:  please RM two packages for ocaml transition, they are leaf https://bugs.launchpad.net/ubuntu/+source/ocaml-melt/+bug/1864659
<ubot5> Ubuntu bug 1864659 in ocamlviz (Ubuntu) "RM: ftbfs strings vs bytes with new ocaml; dead upstream" [Undecided,New]
<xnox> actually three
<doko> done
-queuebot:#ubuntu-release- New: accepted bind9 [amd64] (focal-proposed) [1:9.16.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (focal-proposed) [1:9.16.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [i386] (focal-proposed) [1:9.16.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [s390x] (focal-proposed) [1:9.16.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: bind9 [arm64] (focal-proposed/main) [1:9.16.0-1ubuntu1] (core, i386-whitelist)
<seb128> apw, did you see my ping earlier?
<apw> seb128, i did not
<seb128> apw, hey, could you subscribe kernel-packages to the component listed on https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+bug/1862776 ? Anthony pointed out that he can't do it since only you and Brian are member of that team
<ubot5> Ubuntu bug 1862776 in alsa-ucm-conf (Ubuntu) "[MIR] alsa-ucm-conf & alsa-topology-conf (b-d of alsa-lib)" [High,New]
<apw> oh yeah i was doing that, in a window over there, and couldn't find the right button and forgot
<seb128> apw, https://bugs.launchpad.net/ubuntu/+source/alsa-topology-conf/+subscribe
<seb128> apw, https://bugs.launchpad.net/ubuntu/+source/alsa-ucm-conf/+subscribe
<apw> seb128, ok done
<seb128> apw, thanks!
<apw> seb128, oh going to the link is comlpetly different to the link which claims to point to that when clicked, mad
<seb128> apw, well, if you are on the main page you get the pretty dynamic UI, if you open the url you get a fallback full page version :)
<apw> seb128, and the latter is what an old-dog like me likes
<seb128> :)
<locutus_> apw, please update morbig hint version? 0.9.1-3ubuntu2
-queuebot:#ubuntu-release- Unapproved: s390-tools (focal-proposed/main) [2.12.0-0ubuntu2 => 2.12.0-0ubuntu2] (core)
<apw> locutus_, i already updates it to the version which had the bad
<locutus_> https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/4570
<locutus_> apw, force-reset-test morbig/0.9.1-3ubuntu20.9.1-3ubuntu2/ppc64el
<locutus_> looks copy-pasta went wrong
<apw> oh balls
<apw> tennis obvouisly
<locutus_> I thought about src:ball, the one currently in proposed pocket :p
<locutus_> btw since some weeks, each time I use the middle mouse button to paste, it is pasted twice, I blamed my mouse, but maybe some kernel regression is going on...
<rharper> RAOF:  hi,   the curtin SRU is now verified and ready for release, please take a look if you can, https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-02-14 - 19.3-26-g82f23e3d-0ubuntu1" [Undecided,Confirmed]
<ahasenack> hi, thanks for accepting the bind9 new sonames, could someone also accept the arm64 debs? Not sure why there are still new, given the others were accepted. Maybe the build wasn't done yet (https://launchpad.net/ubuntu/focal/+queue?queue_state=0&queue_text=bind9)
-queuebot:#ubuntu-release- New: accepted bind9 [arm64] (focal-proposed) [1:9.16.0-1ubuntu1]
<ahasenack> thank you!
<coreycb> hello, can an archive admin please accept ovn-octavia-provider  and python-edgegrid from the focal NEW queue
<doko> coreycb: requres source review. I can try to do that tomorrow
-queuebot:#ubuntu-release- New binary: neutron [amd64] (focal-proposed/main) [2:16.0.0~b2~git2020020712.d5b33ffc77-0ubuntu2] (openstack, ubuntu-server)
<coreycb> doko: thank you
-queuebot:#ubuntu-release- New: accepted neutron [amd64] (focal-proposed) [2:16.0.0~b2~git2020020712.d5b33ffc77-0ubuntu2]
-queuebot:#ubuntu-release- New binary: libgnatcoll-bindings [amd64] (focal-proposed/universe) [19-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll-bindings [ppc64el] (focal-proposed/universe) [19-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll-bindings [s390x] (focal-proposed/universe) [19-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgnatcoll-bindings [amd64] (focal-proposed) [19-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll-bindings [s390x] (focal-proposed) [19-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll-bindings [ppc64el] (focal-proposed) [19-1ubuntu1]
-queuebot:#ubuntu-release- Packageset: Removed enum34 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed protozero from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed ruby-thread-order from i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: libgnatcoll-bindings [arm64] (focal-proposed/universe) [19-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [s390x] (focal-proposed/universe) [1.06.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [amd64] (focal-proposed/universe) [1.06.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgnatcoll-bindings [arm64] (focal-proposed) [19-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libxmlezout [s390x] (focal-proposed) [1.06.2-1]
-queuebot:#ubuntu-release- New: accepted libxmlezout [amd64] (focal-proposed) [1.06.2-1]
-queuebot:#ubuntu-release- New binary: libgnatcoll-bindings [armhf] (focal-proposed/universe) [19-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [ppc64el] (focal-proposed/universe) [1.06.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [arm64] (focal-proposed/universe) [1.06.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [armhf] (focal-proposed/universe) [1.06.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgnatcoll-bindings [armhf] (focal-proposed) [19-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libxmlezout [armhf] (focal-proposed) [1.06.2-1]
-queuebot:#ubuntu-release- New: accepted libxmlezout [arm64] (focal-proposed) [1.06.2-1]
-queuebot:#ubuntu-release- New: accepted libxmlezout [ppc64el] (focal-proposed) [1.06.2-1]
-queuebot:#ubuntu-release- New binary: adasockets [amd64] (focal-proposed/universe) [1.11.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [amd64] (focal-proposed/universe) [2.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [ppc64el] (focal-proposed/universe) [1.11.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [ppc64el] (focal-proposed/universe) [2.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [s390x] (focal-proposed/universe) [1.11.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [s390x] (focal-proposed/universe) [2.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [armhf] (focal-proposed/universe) [2.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [arm64] (focal-proposed/universe) [2.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [arm64] (focal-proposed/universe) [1.11.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: adasockets [armhf] (focal-proposed/universe) [1.11.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [ppc64el] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [s390x] (focal-proposed/universe) [2017-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [s390x] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [ppc64el] (focal-proposed/universe) [6.1.20180127-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [amd64] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [ppc64el] (focal-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [ppc64el] (focal-proposed/universe) [2.1.0-16] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [ppc64el] (focal-proposed/universe) [2017-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [amd64] (focal-proposed/universe) [2.1.0-16] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [amd64] (focal-proposed/universe) [6.1.20180127-5] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [amd64] (focal-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [amd64] (focal-proposed/universe) [2017-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [s390x] (focal-proposed/universe) [6.1.20180127-5] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-puppetlabs-mount-core [amd64] (focal-proposed/universe) [1.0.4+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [s390x] (focal-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-node-exporter-collectors [amd64] (focal-proposed/universe) [0+git20200110.fc91c86-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-sidebar [amd64] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dpl1 [amd64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dc1 [amd64] (focal-proposed/universe) [0.3.3-1] (no packageset)
<locutus_> xnox, rebuilding coccinelle won't make it feel better :D
-queuebot:#ubuntu-release- New binary: libtexttools [s390x] (focal-proposed/universe) [2.1.0-16] (no packageset)
<locutus_> the ocaml transition is mostly ready, will have a look tomorrow once llvm-* finish and autopkgtests
-queuebot:#ubuntu-release- New binary: libaunit [arm64] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dc1 [ppc64el] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [armhf] (focal-proposed/universe) [19-3] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dpl1 [ppc64el] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [ppc64el] (focal-proposed/universe) [19-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [s390x] (focal-proposed/universe) [19-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [arm64] (focal-proposed/universe) [2017-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [armhf] (focal-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted adasockets [amd64] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- New: accepted adasockets [armhf] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- New: accepted adasockets [s390x] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- New: accepted adasockets [arm64] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- New: accepted adasockets [ppc64el] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- New: accepted ahven [amd64] (focal-proposed) [2.7-3]
-queuebot:#ubuntu-release- New: accepted ahven [armhf] (focal-proposed) [2.7-3]
-queuebot:#ubuntu-release- New: accepted ahven [s390x] (focal-proposed) [2.7-3]
-queuebot:#ubuntu-release- New: accepted libaunit [arm64] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libaunit [ppc64el] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libflorist [amd64] (focal-proposed) [2017-7]
-queuebot:#ubuntu-release- New: accepted libflorist [ppc64el] (focal-proposed) [2017-7]
-queuebot:#ubuntu-release- New binary: libncursesada [arm64] (focal-proposed/universe) [6.1.20180127-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted ahven [arm64] (focal-proposed) [2.7-3]
-queuebot:#ubuntu-release- New: accepted libaunit [amd64] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libaunit [s390x] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New: accepted libflorist [s390x] (focal-proposed) [2017-7]
-queuebot:#ubuntu-release- New: accepted ahven [ppc64el] (focal-proposed) [2.7-3]
-queuebot:#ubuntu-release- New: accepted libflorist [arm64] (focal-proposed) [2017-7]
-queuebot:#ubuntu-release- New: accepted libaunit [armhf] (focal-proposed) [19-3]
-queuebot:#ubuntu-release- New binary: libncursesada [armhf] (focal-proposed/universe) [6.1.20180127-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgmpada [amd64] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [ppc64el] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [ppc64el] (focal-proposed) [19-4]
-queuebot:#ubuntu-release- New: accepted libncursesada [amd64] (focal-proposed) [6.1.20180127-5]
-queuebot:#ubuntu-release- New: accepted libncursesada [s390x] (focal-proposed) [6.1.20180127-5]
-queuebot:#ubuntu-release- New: accepted libtexttools [ppc64el] (focal-proposed) [2.1.0-16]
-queuebot:#ubuntu-release- New: accepted prometheus-node-exporter-collectors [amd64] (focal-proposed) [0+git20200110.fc91c86-1]
-queuebot:#ubuntu-release- New: accepted ukui-sidebar [amd64] (focal-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted zita-dc1 [ppc64el] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zita-dpl1 [ppc64el] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libgmpada [armhf] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [s390x] (focal-proposed) [19-4]
-queuebot:#ubuntu-release- New: accepted libtexttools [amd64] (focal-proposed) [2.1.0-16]
-queuebot:#ubuntu-release- New: accepted puppet-module-puppetlabs-mount-core [amd64] (focal-proposed) [1.0.4+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted zita-dpl1 [amd64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libgmpada [s390x] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted libtexttools [s390x] (focal-proposed) [2.1.0-16]
-queuebot:#ubuntu-release- New: accepted libncursesada [ppc64el] (focal-proposed) [6.1.20180127-5]
-queuebot:#ubuntu-release- New: accepted zita-dc1 [amd64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New binary: libflorist [armhf] (focal-proposed/universe) [2017-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [arm64] (focal-proposed/universe) [2.1.0-16] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [arm64] (focal-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [armhf] (focal-proposed/universe) [2.1.0-16] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [amd64] (focal-proposed/universe) [19-4] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dc1 [s390x] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dpl1 [s390x] (focal-proposed/universe) [0.3.3-1] (no packageset)
<locutus_> any AA please
<locutus_> missing build on i386: liblwt-ocaml-doc (from 2.7.1-7ubuntu2)
<locutus_> doko, ^^
<locutus_> blocks ocaml
<locutus_> and this one missing build on i386: ocamlweb (from 1.41-3)
-queuebot:#ubuntu-release- New binary: zita-dc1 [arm64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dpl1 [arm64] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dc1 [armhf] (focal-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zita-dpl1 [armhf] (focal-proposed/universe) [0.3.3-1] (no packageset)
<vorlon> locutus_: I have removed those on i386
<xnox> please remove coccinelle again.... https://bugs.launchpad.net/ubuntu/+source/coccinelle/+bug/1864684
<ubot5> Ubuntu bug 1864684 in coccinelle (Ubuntu) "RM coccinelle, again" [Undecided,New]
<xnox> locutus_:  ^^^
<locutus_> vorlon, also this one? missing build on i386: libmlpost-ocaml-doc (from 0.8.1-8build6)
<locutus_> xnox, coccinelle is not in release, why is it considered by britney?
<xnox> i deliberately dropped libmlpost-ocaml-doc, because it now FTBFS due to security policy prohibiting insecure image conversion
<xnox> locutus_:  it was in the transition tracker and hence i uploaded it =) without realizing it has been demoted/removed.
<locutus_> xnox, I wasn't asking why you did rebuild, I'm trying to figure out if it is a blocker or not :)
<locutus_> FWIW there is a version from debian experimental
<xnox> locutus_:  it is not a blocker
<locutus_> but update_output_notest shows it...
<xnox> yes, it will try to migrate byitself
<xnox> but it will never block other things migrating
-queuebot:#ubuntu-release- New binary: asis [s390x] (focal-proposed/universe) [2019-1] (no packageset)
<xnox> locutus_:  experimental version also depends on python-gtk2, so is of no help either
<locutus_> thanks! yes I figured out experimental was not good when I did my first upload today :)
<locutus_> in any case, better kick it out, yes
<locutus_> vorlon, can I ask you for an advice w.r.t. https://bugs.launchpad.net/ubuntu/+source/satpy/+bug/1863596  please?
<ubot5> Ubuntu bug 1863596 in satpy (Ubuntu) "satpy: autopkgtests run out of memory" [Undecided,New]
<locutus_> it is blocking quite some stuff
<locutus_> and it might be easy-fix
<locutus_> also, my merge of this package failed because of python-msgpack removed
<locutus_> https://launchpad.net/ubuntu/+source/python-cachecontrol/0.12.6-1ubuntu1
<locutus_> is it possible to restore the old version?
-queuebot:#ubuntu-release- New: accepted asis [s390x] (focal-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted libgmpada [arm64] (focal-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [arm64] (focal-proposed) [6.1.20180127-5]
-queuebot:#ubuntu-release- New: accepted libtexttools [arm64] (focal-proposed) [2.1.0-16]
-queuebot:#ubuntu-release- New: accepted zita-dc1 [arm64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zita-dc1 [s390x] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zita-dpl1 [armhf] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libflorist [armhf] (focal-proposed) [2017-7]
-queuebot:#ubuntu-release- New: accepted libncursesada [armhf] (focal-proposed) [6.1.20180127-5]
-queuebot:#ubuntu-release- New: accepted zita-dc1 [armhf] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted zita-dpl1 [s390x] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libgtkada [amd64] (focal-proposed) [19-4]
-queuebot:#ubuntu-release- New: accepted zita-dpl1 [arm64] (focal-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libtexttools [armhf] (focal-proposed) [2.1.0-16]
<locutus_> it is blocking subvertpy from building
-queuebot:#ubuntu-release- New binary: asis [amd64] (focal-proposed/universe) [2019-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [armhf] (focal-proposed/universe) [19-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [arm64] (focal-proposed/universe) [19-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted asis [amd64] (focal-proposed) [2019-1]
-queuebot:#ubuntu-release- New: accepted libgtkada [armhf] (focal-proposed) [19-4]
-queuebot:#ubuntu-release- New: accepted libgtkada [arm64] (focal-proposed) [19-4]
-queuebot:#ubuntu-release- New binary: libgnatcoll-db [s390x] (focal-proposed/universe) [19.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll-db [ppc64el] (focal-proposed/universe) [19.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll-db [amd64] (focal-proposed/universe) [19.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgnatcoll-db [amd64] (focal-proposed) [19.2-1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll-db [s390x] (focal-proposed) [19.2-1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll-db [ppc64el] (focal-proposed) [19.2-1]
-queuebot:#ubuntu-release- New binary: libtemplates-parser [s390x] (focal-proposed/universe) [20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [s390x] (focal-proposed) [20-2]
<rharper> bdmurray:  would you have some time to look at   the curtin SRU; it is now verified and ready for release, https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-02-14 - 19.3-26-g82f23e3d-0ubuntu1" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: dbusada [amd64] (focal-proposed/universe) [0.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [s390x] (focal-proposed/universe) [0.7.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [s390x] (focal-proposed/universe) [0.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [ppc64el] (focal-proposed/universe) [0.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [s390x] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [ppc64el] (focal-proposed/universe) [0.7.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [ppc64el] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [amd64] (focal-proposed/universe) [0.7.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [amd64] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [s390x] (focal-proposed/universe) [20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [amd64] (focal-proposed/universe) [20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [arm64] (focal-proposed/universe) [0.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [ppc64el] (focal-proposed/universe) [20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dbusada [armhf] (focal-proposed/universe) [0.5.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [arm64] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [arm64] (focal-proposed/universe) [0.7.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libalog [armhf] (focal-proposed/universe) [0.6.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [armhf] (focal-proposed/universe) [0.7.5-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted dbusada [arm64] (focal-proposed) [0.5.0-3]
-queuebot:#ubuntu-release- New: accepted libalog [amd64] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted libalog [armhf] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted libaws [ppc64el] (focal-proposed) [20.0-1]
-queuebot:#ubuntu-release- New: accepted pcscada [arm64] (focal-proposed) [0.7.5-2]
-queuebot:#ubuntu-release- New: accepted dbusada [armhf] (focal-proposed) [0.5.0-3]
-queuebot:#ubuntu-release- New: accepted libaws [amd64] (focal-proposed) [20.0-1]
-queuebot:#ubuntu-release- New: accepted pcscada [armhf] (focal-proposed) [0.7.5-2]
-queuebot:#ubuntu-release- New: accepted libalog [arm64] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted libaws [s390x] (focal-proposed) [20.0-1]
-queuebot:#ubuntu-release- New: accepted dbusada [amd64] (focal-proposed) [0.5.0-3]
-queuebot:#ubuntu-release- New: accepted dbusada [s390x] (focal-proposed) [0.5.0-3]
-queuebot:#ubuntu-release- New: accepted libalog [s390x] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted pcscada [ppc64el] (focal-proposed) [0.7.5-2]
-queuebot:#ubuntu-release- New: accepted dbusada [ppc64el] (focal-proposed) [0.5.0-3]
-queuebot:#ubuntu-release- New: accepted pcscada [amd64] (focal-proposed) [0.7.5-2]
-queuebot:#ubuntu-release- New: accepted libalog [ppc64el] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted pcscada [s390x] (focal-proposed) [0.7.5-2]
-queuebot:#ubuntu-release- New binary: libaws [armhf] (focal-proposed/universe) [20.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libaws [armhf] (focal-proposed) [20.0-1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- Packageset: Added php7.4 to i386-whitelist in focal
-queuebot:#ubuntu-release- New binary: corosync [amd64] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: corosync [s390x] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: corosync [ppc64el] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: corosync [i386] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: corosync [arm64] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: anet [s390x] (focal-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: corosync [armhf] (focal-proposed/main) [3.0.3-2ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: anet [amd64] (focal-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [ppc64el] (focal-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [ppc64el] (focal-proposed/universe) [1.3.1.b6dafb49-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-apparentlymart-go-dump [amd64] (focal-proposed/universe) [0.0~git20190214.042adf3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-dreamitgetit-statuscake [amd64] (focal-proposed/universe) [0.0~git20190809.9d26ad7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-goji-httpauth [amd64] (focal-proposed/universe) [0.0~git20160601.2da839a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-svanharmelen-jsonapi [amd64] (focal-proposed/universe) [1.0.0+git20180618.0c0828c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-phpdave11-gofpdi [amd64] (focal-proposed/universe) [1.0.8+git20190928.81a2921-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [s390x] (focal-proposed/universe) [1.3.1.b6dafb49-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [amd64] (focal-proposed/universe) [1.3.1.b6dafb49-2] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [arm64] (focal-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: anet [armhf] (focal-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pacemaker [i386] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pacemaker [s390x] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pacemaker [ppc64el] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pacemaker [amd64] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
<ahasenack> vorlon: don't we need bind9-libs building for i386 too, as bind9 is?
-queuebot:#ubuntu-release- New binary: pacemaker [armhf] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
<vorlon> ahasenack: remind me what are the set of packages that will use bind9-libs?
<ahasenack> isc-dhcp (just checked, no i386 for it)
<ahasenack> debian-installer
<ahasenack> bind-dyndb-ldap (which I will file a bug to remove, because it's meant to be used on the server)
<ahasenack> I think that's it
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1074.84] (kernel)
-queuebot:#ubuntu-release- New binary: pacemaker [arm64] (focal-proposed/main) [2.0.3-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblog4ada [arm64] (focal-proposed/universe) [1.3.1.b6dafb49-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [armhf] (focal-proposed/universe) [1.3.1.b6dafb49-2] (no packageset)
<ahasenack> hmm, dnsutils is now a transitional package, so arch is different now
<ahasenack> that might be my problem
<ahasenack> what's the trick again with all arch packages and multi-arch? Multi-Arch: any?
 * ahasenack reads docs
<ahasenack> foreign
<ahasenack> vorlon: src:bind9 (9.16.0) produces bin:dnsutils(transitional) and bin:bind9-dnsutils(the real thing)
<ahasenack> vorlon: the bind9 i386 dep8 test is failing with this: Depends: dnsutils:i386
<ahasenack> if I try "apt install dnsutils:i386" in a focal proposed lxd, it tries to install the old one, from the old bind9:9.11.x package
<ahasenack> my guess is because the new dnsutils from bind9-9.16.0 is a transitional package, and thus "arch: all"
<ahasenack> and apt prefers the i386 one, which is the old one
<ahasenack> should the transitional dnsutils package from src:bind9 (9.16.0) be marked "Multi-Arch: foreign"?
<vorlon> ahasenack: if it's arch: all, then yes probably
<ahasenack> it is arch all, since it's a transitional package
<ahasenack> ok
#ubuntu-release 2020-02-26
-queuebot:#ubuntu-release- Unapproved: python-pip (xenial-proposed/universe) [8.1.1-2ubuntu0.4 => 8.1.1-2ubuntu0.5] (no packageset)
<hellsworth> Laney: the added copy timeout definitely helped and icu passed
<hellsworth> autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64
<hellsworth> so the only failure i see now for LO arm64 is the uicheck test timing out.. is this a build issue too?
<hellsworth> https://paste.ubuntu.com/p/C6gzvvmW4p/
<hellsworth> that was taken from the openjdk-lts run that ran for 11.5 hours
<hellsworth> full log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/libr/libreoffice/20200226_025555_be507@/log.gz
<hellsworth> marcustomlinson: could you please rerun the openjdk-lts test and see if it passes? maybe it just needs another run.. i'm not sure what else to do
<hellsworth> http://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=openjdk-lts/11.0.6%2B10-2ubuntu2
<hellsworth> also marcustomlinson could you please rerun the redland test: http://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=redland/1.0.17-1.1ubuntu1
-queuebot:#ubuntu-release- New binary: ponyorm [amd64] (focal-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gazebo [amd64] (focal-proposed/universe) [9.12.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (focal-proposed/universe) [20.04.0] (ubuntukylin)
<cpaelzer> hello archive admins - there are new corosync and pacemaker uploades hanging in the new queue
<cpaelzer> the former adds vqsync and the latter split out libpacemaker
<cpaelzer> both is intentional and expected
<cpaelzer> it would be great if someone could accept those in the focal new queue so that the tests kick off and rafaeldtinoco can later (when he gets online) on check those results
<cpaelzer> not sure who might still (vorlon) already (doko, apw) be around to process that ^^
<vorlon> amazing timing
<vorlon> cpaelzer: are these both changes that came from Debian?
-queuebot:#ubuntu-release- New: accepted anet [armhf] (focal-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [arm64] (focal-proposed) [1.3.1.b6dafb49-2]
-queuebot:#ubuntu-release- New: accepted ponyorm [amd64] (focal-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted gazebo [amd64] (focal-proposed) [9.12.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted liblog4ada [armhf] (focal-proposed) [1.3.1.b6dafb49-2]
-queuebot:#ubuntu-release- New: accepted anet [arm64] (focal-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted golang-github-dreamitgetit-statuscake [amd64] (focal-proposed) [0.0~git20190809.9d26ad7-1]
-queuebot:#ubuntu-release- New: accepted golang-github-phpdave11-gofpdi [amd64] (focal-proposed) [1.0.8+git20190928.81a2921-1]
-queuebot:#ubuntu-release- New: accepted liblog4ada [amd64] (focal-proposed) [1.3.1.b6dafb49-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [s390x] (focal-proposed) [1.3.1.b6dafb49-2]
-queuebot:#ubuntu-release- New: accepted golang-github-apparentlymart-go-dump [amd64] (focal-proposed) [0.0~git20190214.042adf3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-svanharmelen-jsonapi [amd64] (focal-proposed) [1.0.0+git20180618.0c0828c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-goji-httpauth [amd64] (focal-proposed) [0.0~git20160601.2da839a-1]
-queuebot:#ubuntu-release- New: accepted liblog4ada [ppc64el] (focal-proposed) [1.3.1.b6dafb49-2]
-queuebot:#ubuntu-release- New: accepted anet [amd64] (focal-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted anet [s390x] (focal-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted anet [ppc64el] (focal-proposed) [0.4.2-2]
<cpaelzer> vorlon: yes we didn't add them - they are in debian already
<cpaelzer> => https://paste.debian.net/1132339/
-queuebot:#ubuntu-release- New: accepted corosync [amd64] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted corosync [armhf] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted corosync [ppc64el] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [amd64] (focal-proposed) [2.0.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [armhf] (focal-proposed) [2.0.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [ppc64el] (focal-proposed) [2.0.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted corosync [arm64] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted corosync [s390x] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [i386] (focal-proposed) [2.0.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted corosync [i386] (focal-proposed) [3.0.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [s390x] (focal-proposed) [2.0.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted pacemaker [arm64] (focal-proposed) [2.0.3-3ubuntu1]
<cpaelzer> thank you vorlon, that allows rafaeldtinoco to later hit the ground running :-)
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (focal-proposed) [20.04.0]
<cpaelzer> vorlon: BTW I have prepared and tested the staged uploads to un-break libnbd/nbdkit
<cpaelzer> started the first of three uploads a few minutes ago
<cpaelzer> just mentioning as we discussed about it a few days ago
<vorlon> \o/
-queuebot:#ubuntu-release- New binary: adacgi [amd64] (focal-proposed/universe) [1.6-23] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [ppc64el] (focal-proposed/universe) [1.6-23] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [s390x] (focal-proposed/universe) [1.6-23] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [arm64] (focal-proposed/universe) [1.6-23] (no packageset)
-queuebot:#ubuntu-release- New binary: adacgi [armhf] (focal-proposed/universe) [1.6-23] (no packageset)
-queuebot:#ubuntu-release- New: accepted adacgi [amd64] (focal-proposed) [1.6-23]
-queuebot:#ubuntu-release- New: accepted adacgi [armhf] (focal-proposed) [1.6-23]
-queuebot:#ubuntu-release- New: accepted adacgi [s390x] (focal-proposed) [1.6-23]
-queuebot:#ubuntu-release- New: accepted adacgi [arm64] (focal-proposed) [1.6-23]
-queuebot:#ubuntu-release- New: accepted adacgi [ppc64el] (focal-proposed) [1.6-23]
-queuebot:#ubuntu-release- New binary: supysonic [amd64] (focal-proposed/universe) [0.5.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu20]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu20]
<rbalint> sil2100, could you please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/379876 for systemd?
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu0.18.04.4 => 12.2.13-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
<sil2100> rbalint: looking
<sil2100> rbalint: done
<rbalint> sil2100, thanks!
-queuebot:#ubuntu-release- Unapproved: ceph (eoan-proposed/main) [14.2.4-0ubuntu0.19.10.1 => 14.2.7-0ubuntu0.19.10.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: php-nikic-fast-route [amd64] (focal-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [amd64] (focal-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [ppc64el] (focal-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [s390x] (focal-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [arm64] (focal-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quickcheck-macros [armhf] (focal-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted php-nikic-fast-route [amd64] (focal-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [arm64] (focal-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [ppc64el] (focal-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted supysonic [amd64] (focal-proposed) [0.5.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [amd64] (focal-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [s390x] (focal-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted rust-quickcheck-macros [armhf] (focal-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted ovn-octavia-provider [source] (focal-proposed) [0.0.1~git2020022414.000049c-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-edgegrid [source] (focal-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: python-edgegrid [amd64] (focal-proposed/none) [1.1.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ovn-octavia-provider [amd64] (focal-proposed/none) [0.0.1~git2020022414.000049c-0ubuntu1] (no packageset)
<doko> the mpi4py/ppc64el issues is known upstream: https://bitbucket.org/mpi4py/mpi4py/issues/127/test-failure-with-openmpi-on-ppc64le
-queuebot:#ubuntu-release- New: accepted ovn-octavia-provider [amd64] (focal-proposed) [0.0.1~git2020022414.000049c-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-edgegrid [amd64] (focal-proposed) [1.1.1-0ubuntu1]
<Laney> I'm going to kill those in progress libreoffice/arm64 runs against icu
<Laney> there have been altogether too many retries of that one
<Laney> locutus_: you already got a pass there, so not sure why you have another one in progress, also could you please stop using all-proposed randomly?
<Laney> gone
<seb128> Laney, http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64 icu got 3 successful retries so yeah, no need to extra ones still
<Laney> indeed
<Laney> both of the runs in progress were from people who have green ticks there ;-)
<seb128> Laney, the timeout increase was not specific to libreoffice right?
<Laney> no
<Laney> don't know of any other package that was affected by that problem though
<Laney> not much that's as big as libreoffice to copy about
<seb128> probably not
<seb128> right
<seb128> I was just curious, I don't have a specific case/example :)
<Laney> okey
<locutus_> Laney, it was a mistake due to wrong trigger, or me refreshing the page, sorry for that
<Laney> that's ok
<Laney> it just matters more for libreoffice since that creates more load than most things
<locutus_> doesn't use of all-proposed make all of them become green with just one test?
<Laney> all of what?
<locutus_> if the proposed version is fixed, isn't this the only way to avoid useless rebuilds?
<locutus_> sorry let me provide an example
<locutus_> openjdk-14 is libreoffice/bad/arm64 same for redland/bad/arm64 openjdk-lts/bad/arm64
<locutus_> isn't triggering one of them with all-proposed=1 enough to make them all go green if it passes?
<locutus_> instead of triggering three different tests?
<Laney> no it's not, you need it in the triggers for that
<Laney> all-proposed or not is not looked at by proposed-migration at all
<Laney> retry-autopkgtest-regressions generates you retries with triggers consolidated though
<Laney> https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=arm64&package=libreoffice&trigger=openjdk-14%2F14~36-2&trigger=redland%2F1.0.17-1.1ubuntu1&trigger=openjdk-lts%2F11.0.6%2B10-2ubuntu2
<Laney> that's what it makes for libreoffice currently
<locutus_> thanks, so using the stuff from ubuntu-archive-tools and doing it by clicking via web has different behaviours
<Laney> I mean it's still a bit questionable to consolidate like that, not sure r-a-r is wise to do it
<locutus_> I mean, using all-proposed=1 via web, and running retry-autopkgtest-regressions --all-proposed has different meanings, the former uses proposed pocket, the latter uses more triggers
<Laney> umm
<Laney> the latter gives &all-proposed=1 too, it just gets you the "right" triggers as well
<locutus_> oh ok, so the one from cmdline is more powerful
<locutus_> I'm trying to do it for llvm now, lets see if I do any mistake
<Laney> it's not only the triggers you get from proposed with all-proposed=1, it is everything
<Laney> that is pretty much why it's a bad idea
<locutus_> ok makes sense
<locutus_> apw, autopkgtest for gazebo/9.12.0+dfsg-1: amd64: Pass, arm64: Regression â» , armhf: Regression â» , i386: Regression â» , ppc64el: Regression â» , s390x: Always failed
<locutus_> is this one candidate for a forget test?
<locutus_> it is amd64 only now
<locutus_> so it makes no sense to let it in proposed-forever due to NBS
<apw> locutus_, i'd need to think about the 'simplest' graph from there to sanity
<apw> (and i am thinking about something esle right now)
<Laney> (chips)
<seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html was indicating what 'candidate' items were blocked on some days ago
<seb128> does anyone know why it stopped doing that? it was a nice
<seb128> (like it would state that things needed icu)
<Laney> are you sure it did that?
<Laney> because I feel like it was probably before icu became a candidate
<doko> coreycb: packages reviewed and accepted.  I did assume that "Openstack developers" == "Neutron developers"
<ahasenack> hi release team, I'm not sure how to fix the related bug (or even if it's a bug), so I filed a badtest hint: https://code.launchpad.net/~ahasenack/britney/bind9-i386-dnsutils/+merge/379886
<ahasenack> it has more details
<Laney> seb128: Looks like that could be added though: it's called migrate-after in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.yaml
<Laney> I think the code for this is in lp:ubuntu-archive-scripts
<seb128> Laney, I saw it did that for a couple of days which I found cool but maybe I misrember...
<seb128> Laney, thx for the pointers, maybe a project for the hack day next week :)
<Laney> sure!
<coreycb> doko: thanks, and I've added "Neutron developers" to copyright
-queuebot:#ubuntu-release- New binary: libserial [s390x] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libserial [ppc64el] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libserial [armhf] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libserial [amd64] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: libserial [arm64] (focal-proposed/universe) [1.0.0-2~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.3 => 1.10.6-2ubuntu1.4] (kubuntu, ubuntu-desktop)
<hellsworth> hey Laney could you take a quick look at this LO test failure? it is timing out but it's not clear why. is there an autopkgtest build infra timeout we could increase?
<hellsworth> full log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/libr/libreoffice/20200226_025555_be507@/log.gz
<hellsworth> snippet: https://paste.ubuntu.com/p/krVHdrXc98/
<tkamppeter> Can someone "badtest" gscan2pdf on arm64? Its autopkgtests hang on this platform: bug 1860592 Especially it stops sane-backends from migrating.
<ubot5> bug 1860592 in gscan2pdf (Ubuntu) "Test t/06190 hangs on arm64" [Undecided,New] https://launchpad.net/bugs/1860592
<seb128> tkamppeter, you can do a merge request against https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu to add it
<tkamppeter> hellsworth, if an autopkgtest run takes more than 2:30 hours (150 min) it gets killed.
<hellsworth> that's not ture
<hellsworth> there are plenty of passing tests listed here http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64 that took longer than 6.5 hours
<tkamppeter> hellsworth, is at least my experience, or is it perhaps 150 min hanging, being idle, ...?
<hellsworth> idk
<RikMills> I recognise the 150 min timeout, but I forget what on exactly. test hanging or buildd?
<RikMills> Laney: ^ ?
<tkamppeter> seb128, is there any documentation and/or policy about adding entries to hints-ubuntu?
<seb128> tkamppeter, not that I know
<Laney> hellsworth: no, there is nothing to bump for that
<Laney> why is a random test in the middle timing out?
<hellsworth> i have no clue, but i thought it wouldn't hurt to ask if it was maybe build related
<Laney> I don't know I'm afraid, it's probably going to want someone interested in the package to investigate that specific test and work out what it does and why it might time out
<hellsworth> yeah i'm actually trying to find a test timeout now :)
<tkamppeter> seb128, LocutusOfBorg: https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379910 I hope it is correct.
<Laney> hellsworth: interesting that it's the two java triggers and nothing else, and looks like that test usually only takes ~1h but the timeout happened after like 5.5 hours
<Laney> so I would say it probably does look likely that the test itself hung (i.e. has a bug or the new java does or some combination)
<hellsworth> oh great points!
<rharper> rbasak:  would you have some time to look at   the curtin SRU; it is now verified and ready for release, https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1861452
<ubot5> Ubuntu bug 1861452 in curtin (Ubuntu) "sru curtin 2020-02-14 - 19.3-26-g82f23e3d-0ubuntu1" [Undecided,Confirmed]
 * Laney eyes the number of libreoffice/armhf/zlib test runs in progress simultaneously
<Laney> including an all-proposed one, arrrghghghgh
<Laney> LocutusOfBorg: you don't need all-proposed if you include the right triggers!!!!!
<hellsworth> what does all-proposed mean?
<Laney> unless you *specifically* want everything from proposed for some (good!) reason
<hellsworth> oh i see
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu21 => 2.04-1ubuntu21] (core)
<LocutusOfBorg> Laney, I have to fix my workflow somewhere
<LocutusOfBorg> let me see what I did
<LocutusOfBorg> ok now my ctrl+r should pick the no all-proposed  version
<rbasak> rharper: what's the status of bug 1861452 in Focal?
<ubot5> bug 1861452 in curtin (Ubuntu) "sru curtin 2020-02-14 - 19.3-26-g82f23e3d-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1861452
<rharper> rbasak: released, the version is in the archive for focal
<rharper> rbasak: I'll mark that now
<vorlon> mitya57: qtwebengine-opensource-src is in the middle of the icu transition, please don't do uploads of packages that are waiting on icu in -proposed
<rbasak> Thanks
<mitya57> vorlon: ok, sorry. In fact I prepared binaries in a PPA in order to reduce harm to the transition.
<vorlon> mitya57: it invalidates my hint, which is by version, which means 2h+ after I notice it before I get an updated view of the migration status
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu21 => 2.04-1ubuntu21] (core)
<ahasenack> vorlon: hi, when you have a moment, https://code.launchpad.net/~ahasenack/britney/bind9-i386-dnsutils/+merge/379886 explains the problem and what I tried (and didn't work)
<mitya57> Ack, I won't do any more related uploads.
<vorlon> ... and also we're still waiting for test results, so
<vorlon> pyside2 tests take 2+h on arm
 * vorlon forces qtwebengine-opensource-src to not wait for test results
<LocutusOfBorg> yay
<rbasak> rharper: is there supposed to be a MAAS test result logged against the Eoan proposed package?
<rharper> rbasak: no; maas is not supported on eoan; only on LTS releases
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu21]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu21]
<LocutusOfBorg> vorlon, FYI ocaml is also mostly ready, entangled only with gnat/gprbuild
<rbasak> rharper: but maas ships in Eoan :-/
<LocutusOfBorg> I would appreciate if you can do anything in case britney is stuck :(
<rbasak> And that's not documented in https://wiki.ubuntu.com/CurtinUpdates
<rharper> rbasak: you are correct
 * rbasak is reminded of "Papers, please"
<vorlon> ahasenack: you say "it didn't help" to mark dnsutils Multi-Arch: foreign, how did you actually test this?  Do you have an autopkgtest commandline that'll work against a ppa?
<ahasenack> vorlon: no, I tried "apt install dnsutils:i386"
<ahasenack> with my ppa added
<vorlon> ahasenack: ok, that's not the command that autopkgtest will run
<ahasenack> let me try a dep8 run against the ppa then
<ahasenack> but
<vorlon> it will decipher that it's Arch: all / Multi-Arch: foreign and will just install the one that's there
<vorlon> but it's considered by apt to be arch: amd64 for such purposes
<ahasenack> is it fine to try with a local lxd image, or should I use bileto?
<vorlon> I'm fine with you testing locally
<rbasak> rharper: so I'm looking for a summary of what testing was done, including what version was tested and in this case which type of test each one is, to match against the test plan documented at https://wiki.ubuntu.com/CurtinUpdates
<ahasenack> the usual autopkgtest -o logs ... <include ppa>... --apt-pocket=proposed ... ./<source>/ -- lxd ubuntu-daily:focal?
<rbasak> rharper: everything else looks fine
<rbasak> rharper: the MAAS tests I can see what versions were tested by extracting the zips, which was tedious but I got there
<rbasak> rharper: the other test artifacts seem rather unfathomable.
<rbasak> Oh, and that each test passed of course
<ahasenack> running
<rbasak> But I can't see those things, or a summary of those things
<rharper> the console.log will show the version use for vmtests,  and for the CDO QA run, it's a click-through to their web form and log with version;
<doko> vorlon: please hint in python3.8, while the arm64 tests are still running. the one kopanocore test failure did already succeed. will give a better view on icu again
<ahasenack> vorlon: ah, wait, I don't know how to run autopkgtest locally with an i386 focal
<rharper> rbasak: I can add a summary entry as  a comment or updated description;
<rbasak> rharper: the CDO QA run I did find details for, but that doesn't seem to be required according to https://wiki.ubuntu.com/CurtinUpdates
<rharper> ok
<ahasenack> vorlon: do I just include "sudo dpkg --add-architecture i386" in the setup commands?
<ahasenack> cpaelzer: you did that in the recent past, no? ^
<vorlon> doko: it doesn't change the view on icu, python3.8 isn't part of the icu transition
<vorlon> ahasenack: you have to --add-architecture and also apt-get update afterwards
<ahasenack> vorlon: ok, thanks
 * ahasenack crosses fingers
<rharper> rbasak: for the vmtest rnus, the -console.log includes curtin versions used at the top; and the bottom includes the summary of tests/passed failed.  in two cases, we re-run tests that fail due to hardware resource issues (timed out); and include a second log (v2);
<doko> xnox: so what did you claim? ;p
<rbasak> rharper: I'm also a bit puzzled that those console logs seem to be pulling the curtin source package. Is the binary being tested?
<doko> I see that ocaml and python3.8 are connected
<xnox> xnox:  my claim is confused about life
<xnox> doko:  there is pyocaml yes.
<rharper> rbasak: curtin is all python, so the source is the binary; curtin is deployed by packing up it's python source and pushing that into the target environment via cloud-init;  this is how MAAS deploys curtin in ephemaral environments, and this is how curtin's vmtest harness does as well
<ahasenack> vorlon: Get:59 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 dnsutils all 1:9.16.0-1ubuntu1 [2756 B]
<ahasenack> hah
<ahasenack> looks like it worked
<ahasenack> it pulled the arch-all transitional package from 9.16.0 (and the real package later)
<ahasenack> Get:63 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 bind9-dnsutils amd64 1:9.16.0-1ubuntu1 [134 kB]
<ahasenack> but amd64,hm
<vorlon> ah
<ahasenack> let me repeat without dpkg --add-architecture
<rbasak> rharper: is the source picked up from the source package or from the binary package? Because packaging can modify Python source when it builds the binary package.
<ahasenack> time autopkgtest -o dep8-i386-with-ppa-and-proposed -U -B -s --apt-pocket=proposed --setup-commands="sudo dpkg --add-architecture i386; sudo add-apt-repository ppa:ahasenack/junk -y;sudo apt-get update" ./bind9/ -- lxd ubuntu-daily:focal
<ahasenack> that was my command line
<doko> promoted ruby2.7 again
<ahasenack> maybe without -U? and do a dist-upgrade in my setup-commands
<ahasenack> yeah, it didn't use my ppa
 * ahasenack checks
<rbasak> rharper, powersj: ^ sorry for the pain. AIUI, my reviewing job is to check these things. If you're in a hurry, feel free to pass to someone who already follows all of this. vorlon maybe?
<vorlon> ahasenack: bind9-dnsutils isn't Multi-Arch: foreign, so dnsutils -> bind9-dnsutils will follow the dep within the native arch.  And we probably want to be able to install the :i386 one, and it's a utils package so M-A: foreign is probably correct
<rharper> rbasak: packing happens from the installed binary;  the installed curtin will pack it's installed code into blob to be written out via cloud-init
<rbasak> rharper: OK, so surely the test should be testing from the binary and not the source then?
<rharper> it is testing from the binary; we create a container in which we install curtin from -proposed
<rbasak> The usual goal of SRU verification is to test the built binary
<rbasak> But the first thing it seems to do is pull-lp-source?
<ahasenack> wait, it used my ppa, I just happened to have pasted the first grep hit, it later installed mine
 * ahasenack continues checking
<rharper> and then we call curtin inside this container and run the 'pack' command to build the blob that's deployed into VMs for testing that the version from the archive deploys correctly
<ahasenack> it did get my ppa, but I don't see it installing i386 packages
<vorlon> ahasenack: oh.  couldn't you fix this by making the autopkgtest depend on bind9-dnsutils in debian/tests/control, instead of the transitional package?
 * vorlon whistles innocentl/y
<ahasenack> vorlon: oh
<ahasenack> someone needs a clue bat looks like it
<ahasenack> but I still need a way to verify, I'll try bileto
<vorlon> ahasenack: I assumed it was pulling in dnsutils because it had a Depends: @ or something; but in this case it's a simple replace to not pull in the transitional package :)
<rharper> rbasak: the source is pulled to acquire the tool to create the container in which we install the binary from -proposed
<ahasenack> vorlon: I assumed it was the testbed, because dnsutils was installed already
<ahasenack> vorlon: if this fixes it, no need for multi-arch? OR is that still something good to do? Or better wait for bugs to happen, if at all?
<ahasenack> weird, I did have this in bileto before, and it passed
<ahasenack> anyway
<vorlon> ahasenack: no need for multi-arch, it would still be correct but probably useless
<ahasenack> ok
<ahasenack> thanks for your help
<rbasak> rharper: ah, OK
<rbasak> Sorry
<rbasak> rharper: so I can see that in the Eoan vmtest that failed, but not in the Eoan vmtest that succeeded
<rharper> rbasak: not a problem; it's not immediately obvious
<rharper> rbasak:  e-console.log ?
<rbasak> Sorry no, that's wrong
<rbasak> This is confusing!
<rbasak> curtin-vmtest-proposed-x-console.log says "installed curtin at 19.3-26-g82f23e3d-0ubuntu1~16.04.1
<rbasak> "
<rbasak> Which is a convenient confirmation
<rbasak> But that's the first one that failed
<rbasak> The retry test logs seem to have a different format?
<rbasak> And those don't seem to have that output
<rharper> rbasak: they are different as it's human (me) re-issuing the command to run a subset of the tests
<rbasak> rharper: subset because the remainder passed the previous time?
<rharper> correct
<rharper> on the jenkins node we have, at some levels of load, tests just timeout due to contrained resourse; we rerun them sequentially (rather than in parallel) to confirm that they are passing
<rbasak> vorlon: in https://wiki.ubuntu.com/CurtinUpdates, what do you understand by the MAAS integration test requirement? Is that supposed to apply only to LTS releases, or all supported Ubuntu releases?
<vorlon> rbasak: all supported, or else why SRU it to that release?
<rbasak> rharper: ^
<rharper> We're SRU'ing curtin; not maas.    The code path we (curtin) verify is in an Eoan ephemeral enviroment, does curtin install correctly in all of the integration tests we have.  MAAS QA re-runs a subset of curtin vmtest scenarios, but not all of what we run.    This is a limitation of the MAAS test harness;
<rharper> rbasak: I need to relocate; thanks for looking into the SRU; I'll be back online in about 30 minutes or so
<locutus__> vorlon, what is wrong with odil?
<locutus__> I see update_output failing because of it
<locutus__> reverse-depends -r focal  python-odil returns nothing
<locutus__>  python-odil | 0.10.0-3ubuntu1 | focal/universe  | amd64, arm64, armhf, ppc64el, s390x
<locutus__> any AA please NBS cleanup=
<locutus__> doko, ^^
<vorlon> locutus__: nothing's wrong with odil, only with the order in which the autohinter is considering packages for inclusion in its hint
<vorlon> see also output of my hint in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt , which gets odil just fine but is currently hung up on r-cran-insight
-queuebot:#ubuntu-release- Unapproved: flatpak (eoan-proposed/universe) [1.4.3-1 => 1.4.4-0ubuntu0.1] (ubuntugnome) (sync)
<kenvandine> ahayzen: ^^
-queuebot:#ubuntu-release- New binary: apt [s390x] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: apt [ppc64el] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
<juliank> final APT ABI (well, at least the minimum ABI, might make more stuff public again) is coming in! :D
<juliank> python-apt 1.9.8 is already uploaded with a build-depends on this version
-queuebot:#ubuntu-release- New binary: apt [amd64] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: apt [i386] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: apt [arm64] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: apt [armhf] (focal-proposed/main) [1.9.11] (core, i386-whitelist)
<juliank> Would somebody be so kind to approve the apt soname bump?
<juliank> I already upload libept as well with the packaging changes for the new apt version
<juliank> so hopefully once it's in, libept binaries should get build and hit new
<juliank> and once they are in we can build the rest
<juliank> well, we can build most before libept :D
-queuebot:#ubuntu-release- New binary: kodiplatform [amd64] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kodiplatform [s390x] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
<ahayzen> kenvandine, awesome thanks :-D
-queuebot:#ubuntu-release- New binary: kodiplatform [ppc64el] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
<rbalint> please reject the kodiplatform binaries
-queuebot:#ubuntu-release- New binary: kodiplatform [arm64] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kodiplatform [armhf] (focal-proposed/universe) [20180302-0ubuntu1] (no packageset)
<vorlon> rafaeldtinoco: I'm rolling back ruby-charlock-holmes in -proposed, the ruby transition can't stack on the icu transition right now
<rafaeldtinoco> alright
-queuebot:#ubuntu-release- New: accepted apt [amd64] (focal-proposed) [1.9.11]
<rafaeldtinoco> kanashiro: ^
-queuebot:#ubuntu-release- New: accepted apt [armhf] (focal-proposed) [1.9.11]
-queuebot:#ubuntu-release- New: accepted apt [ppc64el] (focal-proposed) [1.9.11]
-queuebot:#ubuntu-release- New: accepted apt [arm64] (focal-proposed) [1.9.11]
-queuebot:#ubuntu-release- New: accepted apt [s390x] (focal-proposed) [1.9.11]
-queuebot:#ubuntu-release- New: accepted apt [i386] (focal-proposed) [1.9.11]
<rbalint> the kodiplatform ubuntu2 binaries will be ok
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1002.2] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1002.2]
-queuebot:#ubuntu-release- Packageset: Added libfido2 to i386-whitelist in focal
<ahasenack> vorlon: hmpf, now I got this, after changing the test builddep to the non-transitional package:  builddeps:/tmp/autopkgtest.ZYqxfY/1-autopkgtest-satdep.dsc:i386 : Depends: bind9-dnsutils:i386
<ahasenack> I'll have to look at that tomorrow
<vorlon> that alone doesn't look like a problem
<vorlon> is there error output?
<ahasenack> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/b/bind9/20200226_222941_4f774@/log.gz is the log
<vorlon> ok
<vorlon> ahasenack: could be fixed by making bind9-utils Multi-Arch: foreign
<ahasenack> but it's not an arch all package
<ahasenack> ah, hm
<ahasenack> running the tools doesn't really matter
<ahasenack> let me check its contents
<vorlon> the reason it would fix it is that dnsutils, which is installed for some reason, would still have its dependency satisfied by bind9-dnsutils:i386 instead of bind9-dnsutils:amd64, allowing apt to make the switch
<ahasenack> dnsutils is installed because it's a rdep of ubuntu-standard I think
<vorlon> "for some reason" - because it's standard, yes
<ahasenack> ok, so bind9-utils has /usr/sbin/* binaries and python scripts
<ahasenack> and the python module these scripts import: /usr/lib/python3/dist-packages/isc
<ahasenack> hm, this worked in bileto just before
<ahasenack> vorlon: as simple as this, hopefully? :) https://pastebin.ubuntu.com/p/xMVQjxBDfN/
-queuebot:#ubuntu-release- Packageset: Added tepl to i386-whitelist in focal
<vorlon> ahasenack: I believe so
<ahasenack> vorlon: this is hard to test, I couldn't even get autopkgtest locally to do it, with the new "-a i386" flag from that git repo autokgtest-development
<vorlon> cpaelzer, rafaeldtinoco: sorry https://launchpad.net/ubuntu/+source/kronosnet/1.14-1ubuntu2
<vorlon> ahasenack: yes, I've had difficulty testing those kinds of changes locally
<vorlon> so I tend to just upload them because they don't make it worse ;)
<rafaeldtinoco> hey steve
 * rafaeldtinoco checks
<rafaeldtinoco> yep, my last i386 changes were "best guess" with "local attempts" and "prays"
-queuebot:#ubuntu-release- New binary: azure-cosmos-table-python [amd64] (focal-proposed/universe) [1.0.5+git20191025-1] (no packageset)
-queuebot:#ubuntu-release- New binary: eshell-z [amd64] (focal-proposed/universe) [0.4-3] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added fmtlib to i386-whitelist in focal
#ubuntu-release 2020-02-27
<xnox> vorlon:  openssh:i386 has a depwait on libfido2-dev => would you like to disable that feature on i386? or build libfido2-dev for i386?
<xnox> https://launchpad.net/ubuntu/+source/openssh/1:8.2p1-4/+build/18767920
<vorlon> xnox: that's so 2 hours ago
<vorlon> xnox: now I need to fix the dep-wait of libfido2/i386 instead
<xnox> ok
<xnox> vorlon:  you don't need to do no-change rebuild, you can have done a binary copy from focal to focal-proposed => this would have created a build record on i386.
 * xnox ponders to do that with libcbor then
<vorlon> (it's being mired so there's no reason to deviate)
<vorlon> xnox: no, the binary copy does not create the build records
<vorlon> I tried that early in the process :)
<vorlon> xnox: hmm although I don't think I ever did a focal->focal-proposed, did you actually do this and see that it worked?
<xnox> vorlon:  it did for me before, i've done that earler in the cycle when something for doko got re-whitelisted
<xnox> i have done this now for libcbor, let's see what happens.
<vorlon> k
 * xnox has no ACLs to copy to focal-release, so I only can copy to focal-proposed
<xnox> vorlon:  https://launchpad.net/ubuntu/focal/i386/libcbor-dev looks like it is getting published from the past
<vorlon> and we don't want it built in focal anyway, we want it built in focal-proposed and go through the appropriate p-m sanity checks
<xnox> vorlon:  why build at all? it's simply republishing removed i386 binary that was there.
<vorlon> xnox: ah right, in that case it'll bring back the i386 binaries with no new build
<xnox> i386 build of libcbor-dev already exists
<vorlon> yes
<xnox> vorlon:  i have done this already
<vorlon> but I've not seen the binary copy create a new build record
<xnox> ignore me =)
<xnox> vorlon:  so for mattias, i did binary copy for something that didn't have i386 build, that was built in focal-proposed and already migrated to release pocket.
<xnox> and i386 build record got created in focal-proposed
<vorlon> and the binary copy resuscitates the i386 binaries whether you want them or not
<xnox> that's similar to how new arches get bootstraped too
<xnox> i think it still goes thorugh the whitelist/blacklist. I did not see non-whitelisted binaries getting published.
<xnox> but also wouldn't want to experiment with that
<vorlon> no, the whitelist definitely does not filter out the binaries on binary copy
<vorlon> so packages that were built in -proposed before the whitelist was in place and haven't yet migrated to the release pocket, I've been having to go back and clean up :P
<xnox> ouch
<xnox> ok
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1054.57] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-90.91] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-90.91] (core, kernel)
-queuebot:#ubuntu-release- Packageset: Added libcbor to i386-whitelist in focal
<xnox> hm
-queuebot:#ubuntu-release- New: accepted azure-cosmos-table-python [amd64] (focal-proposed) [1.0.5+git20191025-1]
-queuebot:#ubuntu-release- New: accepted kodiplatform [amd64] (focal-proposed) [20180302-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kodiplatform [armhf] (focal-proposed) [20180302-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kodiplatform [s390x] (focal-proposed) [20180302-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libserial [arm64] (focal-proposed) [1.0.0-2~build1]
-queuebot:#ubuntu-release- New: accepted libserial [ppc64el] (focal-proposed) [1.0.0-2~build1]
-queuebot:#ubuntu-release- New: accepted eshell-z [amd64] (focal-proposed) [0.4-3]
-queuebot:#ubuntu-release- New: accepted kodiplatform [ppc64el] (focal-proposed) [20180302-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libserial [armhf] (focal-proposed) [1.0.0-2~build1]
-queuebot:#ubuntu-release- New: accepted kodiplatform [arm64] (focal-proposed) [20180302-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libserial [s390x] (focal-proposed) [1.0.0-2~build1]
-queuebot:#ubuntu-release- New: accepted libserial [amd64] (focal-proposed) [1.0.0-2~build1]
<wxl> did we add some thing to check the iso on boot? if so, where?
<wxl> also does anyone know if this new iso manifest-diff check applies to flavors? or can we make it be? is there code for this somewhere?
<wxl> (forgive me folks on devel for the doublespeak but it should probably be here)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (focal-proposed) [2.12.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-16.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-16.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-16.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-16.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1054.57]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-90.91]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1074.84]
-queuebot:#ubuntu-release- New binary: microsoft-authentication-library-for-python [amd64] (focal-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-multiapi-storage-python [amd64] (focal-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-16.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-16.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-16.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-16.19]
<vorlon> doko: was a new upload of python3-defaults still incoming this week?
<vorlon> cpaelzer: https://launchpad.net/ubuntu/+source/procps/2:3.3.16-1ubuntu2 lol (Debian bug #951494)
<ubot5> Debian bug 951494 in libprocps-dev "libprocps-dev: dead symlink point to the old soname" [Grave,Fixed] http://bugs.debian.org/951494
<vorlon> mysqltest: At line 69: Query 'ALTER EVENT event_starts_test ON SCHEDULE AT '2020-02-02 20:00:02'' failed.
<vorlon> ERROR 1589 (HY000): Event execution time is in the past and ON COMPLETION NOT PRESERVE is set. The event was not changed. Specify a time in the future.
<vorlon> mmmhmm
<cpaelzer> vorlon: nice on procps, one would think that this would have wreaked more havoc than the bit we have seen
<vorlon> Laney, sil2100: so icu didn't quite make it because of one last package that was in the easy hint but shouldn't have been because it's not a candidate. :/  the next britney run SHOULD take care of this, but I don't have 2 hours to wait around for it.  can one of you help shepherd?  I've added some aggressive hints on this such that it really really should go through, but there might be some manual
<vorlon> cleanup required afterwards
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-90.91]
<sil2100> vorlon: hey! Okay, thanks for that! I can keep an eye out on it
<sil2100> vorlon: I see the force hint, any particular issues I should be looking out for? Or just seeing if icu migrates?
-queuebot:#ubuntu-release- New binary: libept [s390x] (focal-proposed/universe) [1.1+nmu3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [ppc64el] (focal-proposed/universe) [1.1+nmu3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [amd64] (focal-proposed/universe) [1.1+nmu3ubuntu3] (no packageset)
<juliank> Finishing up the APT transition uploads now
-queuebot:#ubuntu-release- New binary: libept [arm64] (focal-proposed/universe) [1.1+nmu3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: libept [armhf] (focal-proposed/universe) [1.1+nmu3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: aptitude (eoan-proposed/universe) [0.8.11-3ubuntu3 => 0.8.12-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: therion [amd64] (focal-proposed/universe) [5.4.4ds1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apt-move (eoan-proposed/universe) [4.2.27-5ubuntu1 => 4.2.27-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libapt-pkg-perl (eoan-proposed/main) [0.1.36 => 0.1.36build2] (core)
-queuebot:#ubuntu-release- Unapproved: libqapt (eoan-proposed/universe) [3.0.4-1ubuntu4 => 3.0.4-1ubuntu5] (kubuntu)
<juliank> huh
<juliank> Sorry seems the script had eoan in changelog
<juliank> I'll reupload shortly, sorry
<apw> juliank, should i assume that those 4 uploads all want to be rejected ?
<juliank> yes, apw
<juliank> thanks
<apw> np
-queuebot:#ubuntu-release- Unapproved: rejected apt-move [source] (eoan-proposed) [4.2.27-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected libapt-pkg-perl [source] (eoan-proposed) [0.1.36build2]
-queuebot:#ubuntu-release- Unapproved: rejected aptitude [source] (eoan-proposed) [0.8.12-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected libqapt [source] (eoan-proposed) [3.0.4-1ubuntu5]
<seb128> hey there, so since the icu transition still didn't go through, if it doesn't clear today, can we get a standing ff report for packages blocked from being uploaded by it?
<juliank> seb128: did you wait for the latest run?
<juliank> seb128: vorlon added hints an hour ago that should make it go through
<seb128> juliank, I had other packages migrating 50 minutes ago
<seb128> but maybe it needs yet another round?
<juliank> seb128: sil2100 should know
<seb128> juliank, do you know where one can check what's the publisher status? like when was the last update started/finished?
<sil2100> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/focal/2020-02-27/
<sil2100> So it's still running right now, the previous run seems to have been the one for vorlon's previous easy hint
<sil2100> I assume only now the force one will be taken into consideration
<seb128> hey sil2100, thanks
<seb128> sil2100, do you know if update_excuses_by_team.html was listed reason why 'candidate' were not moving, like 'depends on icu' earlier in the week of I had dreamed that one?
<juliank> who/what's retrying python-apt builds all the time`
<juliank> ?
<juliank> this is annoying
<juliank> it's failing, it will continue to fail, there's no point in retrying it every hour or so
<LocutusOfBorg> juliank, sorry, I mass retried what failed tonight, because of the x11 sadness
<LocutusOfBorg> I had around 40 packages that went from sad to good
<LocutusOfBorg> and I retried them once more after they published
<rbalint> LocutusOfBorg, thanks for the retries for the sadness
<LocutusOfBorg> lots of ruby stuff is now good
<doko> vorlon: I wanted the current one to migrate first, maybe overriding the uninstallability issue firsdt
<LocutusOfBorg> vorlon, can you please NBS-proposed cleanup https://launchpad.net/ubuntu/+source/reposurgeon/4.3+git20200214.8d048e1-1 ?
<LocutusOfBorg> armhf is NBS now and gone in Debian
<Laney> icu stuff is going in now
<LocutusOfBorg> <3
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (eoan-proposed/main) [1.8+19.10ubuntu1 => 1.9+19.10ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (bionic-proposed/main) [1.8+18.04ubuntu2 => 1.9+18.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/main) [1.8+16.04ubuntu1 => 1.9+16.04ubuntu1] (no packageset)
<LocutusOfBorg> since ocaml/gprbuild were mostly ready before ruby started the transition, can we copy-back two packages and then restore after migration?
<LocutusOfBorg> hivex 1.3.18-2build1 and libguestsfs 1:1.40.2-7ubuntu3 are probably enough
<LocutusOfBorg> doko,  what is your opinion? I can't parse anymore britney, it was stuck by python3.8 autopkgtests
-queuebot:#ubuntu-release- New: accepted azure-multiapi-storage-python [amd64] (focal-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted microsoft-authentication-library-for-python [amd64] (focal-proposed) [1.1.0-1]
<cjwatson> vorlon: Could you file a bug about copies reviving binaries in spite of the DAS filter?  I don't think that's totally intended.
<cjwatson> Or at least it seems questionable.
<cjwatson> Copies should certainly create build records.
<cjwatson> (Assuming the filter permits them)
-queuebot:#ubuntu-release- New source: kpeoplevcard (focal-proposed/primary) [0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: microsoft-authentication-extensions-for-python [amd64] (focal-proposed/universe) [0.1.3-1] (no packageset)
<sforshee> can someone help get linux-firmware 1.173.15 promoted in bionic? It looks like it should be ready
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-90.91~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-90.91~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-90.91~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-90.91~16.04.1]
<sil2100> rbalint: hey! Did you see my comment/question https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1861909/comments/8 ?
<ubot5> Ubuntu bug 1861909 in ec2-instance-connect (Ubuntu Eoan) "Please ship ec2-instance-connect.conf instead of creating it in postinst" [Undecided,Fix committed]
-queuebot:#ubuntu-release- New binary: elasticsearch-curator [amd64] (focal-proposed/universe) [5.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1073.78] (kernel)
-queuebot:#ubuntu-release- New source: sane-airscan (focal-proposed/primary) [0.9.16-0ubuntu1]
<cpaelzer> hi AAs I'd ask for help on https://launchpad.net/ubuntu/+source/microsoft-authentication-extensions-for-python
<cpaelzer> 0.1.3-1 just passed debian-New ~10h ago
<cpaelzer> as usual with Debian new that was a binary upload
<cpaelzer> 0.1.3-2 is the source upload and in Debian since ~3h and soon hitting ubutu as well I guess
<cpaelzer> the package is in the Ubuntu new queue at https://launchpad.net/ubuntu/focal/+queue?queue_state=0&queue_text=
<cpaelzer> I was wondering if an AA would need to accept the one in the new queue right now
<cpaelzer> or if this has to wait until the source upload of 0.1.3-2 appears?
<cpaelzer> apw: seb128: doko: ^^
<cpaelzer> bluca: I just asked the archive admins - lets wait for an answer
<bluca> hello - thanks
<bluca> hi seb128 - I see you took care of network-manager-openconnect in the past, any chance you could have time to please look at https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1857624 please? We got patches in Debian to add GP support, and we use GP in Microsoft so it would be great if it worked out of the box in 20.04 for the internal users. Thanks!
<ubot5> Ubuntu bug 1857624 in network-manager-openconnect (Ubuntu) "Option Protocol gp (Palo Alto GlobalProtect) missing on GUI" [Undecided,Confirmed]
<seb128> bluca, do you know what that version is in debian/experimental only?
<seb128> cpaelzer, I'm in a call but I try to have a look when possible
<bluca> not 100% sure - I think the maintainer was holding back to go to the next release directly, since the patches in -3 were reworked upstream - but that requires also a new version of openconnect, so it's all kinda stalled
<rbalint> sil2100, no, i've missed that but i'm on it, thanks!
<vorlon> sil2100: it was just watching to make sure that if the uninstallables increased, we followed through on those.  The force hint was "just in case" something changed and broke the main hint
<vorlon> now, does anyone know why there hasn't been a britney run /since/ this?
<vorlon> doko: the current python3-defaults /did/ migrate last week
<vorlon> doko: because I override the tests as we discussed
<vorlon> overrode
<Laney> this> icu? Sure there has
<vorlon> ah, I was just using a wrong glob
<vorlon> hours beginning with 1 do not have logs matching 0*
<vorlon> :)
<Laney> check out snakefruit:~laney/tail-latest-britney-log
<Laney> :>
<vorlon> Laney: do you know why arm64 autopkgtest queues aren't progressing?
<Laney> vorlon: they are
<Laney> ubuntu@juju-prod-ues-proposed-migration-machine-11:~$ journalctl --since=15:00 ADT_ARCH=arm64 | grep -c 'Acknowledging request'
<Laney> 48
<vorlon> Laney: but much more slowly than they should https://cdo.kpi.canonical.com/d/000000030/ubuntu-foundations?panelId=19&fullscreen&orgId=1
<Laney> can't say what the value of should is
<Laney> I noticed some unhelpful things earlier in the day like lots of duplicated gscan2pdf requests that people had done
<Laney> and for example right now there are some libreoffice runs that are duplicating one another
<vorlon> ah, well we should axe those for sure
<vorlon> Laney: generally arm64 seems to be about half as fast as the others
<vorlon> but obviously duplicate libreoffice tests are outside the norm :P
<Laney> I sort of trained myself to expect arm64 to be the worst
<Laney> perhaps that's not always been the case ...
<Laney> if we had engineering but not hardware to look into this I would suggest looking at lxding by default and VMing only when needed
<doko> vorlon: no asked for python3.8, not python3-defaults
<vorlon> <doko> vorlon: would you be willing to ignore every autopkg test for python3-defaults, dropping python3.7? the reason I'm asking is that everything else is still tested with 3.7, which we don't care about anymore
<vorlon> doko: there are logs :P
<vorlon> you asked me to skip for python3-defaults and said there would be a new upload this week
<Laney> vorlon: would be handy if you could take on killing off those libreoffice requests if you've time; I'm trying to help people get stuff uploaded for FF at the minute
<vorlon> ack
<Laney> you might like the not committed filter-amqp-dupes script
<Laney> hmm, actually that's not that helpful for already-in-progress runs
<Laney> what you need to do is HUP the workers, kill the runner/autopkgtest processes and then filter the requests before anything restarts and picks it back up
<cpaelzer> seb128: apw: doko: (and now I also see vorlon around) - I wanted to ping again for microsoft-authentication-extensions-for-python in the focal new queue and how it needs to be handled (details about 2h up in the log)
<seb128> cpaelzer, accepted
-queuebot:#ubuntu-release- New: accepted microsoft-authentication-extensions-for-python [amd64] (focal-proposed) [0.1.3-1]
<cpaelzer> thanks seb128
<cpaelzer> did the discussion on that vpn thing conlude as well?
<cpaelzer> +c
-queuebot:#ubuntu-release- New: accepted elasticsearch-curator [amd64] (focal-proposed) [5.8.1-1]
-queuebot:#ubuntu-release- New: accepted libept [arm64] (focal-proposed) [1.1+nmu3ubuntu3]
-queuebot:#ubuntu-release- New: accepted libept [ppc64el] (focal-proposed) [1.1+nmu3ubuntu3]
-queuebot:#ubuntu-release- New: accepted therion [amd64] (focal-proposed) [5.4.4ds1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted libept [amd64] (focal-proposed) [1.1+nmu3ubuntu3]
-queuebot:#ubuntu-release- New: accepted libept [s390x] (focal-proposed) [1.1+nmu3ubuntu3]
-queuebot:#ubuntu-release- New: accepted libept [armhf] (focal-proposed) [1.1+nmu3ubuntu3]
<seb128> cpaelzer, if it's not good enough to get to Debian unstable I'm a bit nervous to get it in focal
<seb128> cpaelzer, but if someone wants to do the Debian merge and upload I will not stop them
<seb128> I just don't have enough acccess to VPNs to test that and the fact that the Debian maintainer keeps it in experimental doesn't give me confidence
<cpaelzer> ok good to know, bluca ^^ here you know what to work on now
<cpaelzer> get it in unstable might be the easiest path to work on for you I guess?
<vorlon> rafaeldtinoco: libguestfs entangled ocaml and ruby, I'm rolling this back to let us try to get both halves through sooner
<rafaeldtinoco> no problem. tks!
<cjwatson> Can I assume that somebody is going to take care of putting auto-sync into --dry-run mode at EOD today?
<vorlon> cjwatson: yes
<cpaelzer> vorlon: will you (later) bring libguestfs back again => https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1864164 ?
<ubot5> Error: Could not gather data from Ubuntu for bug #1864164 (https://launchpad.net/bugs/1864164). The error has been logged
<cjwatson> good good
<vorlon> cpaelzer: yes
<cpaelzer> ok
<cpaelzer> just asked as I've known bugs depend on it
<bluca> thanks, I'll ping the Debian maintainer
<bluca> and thanks for processing new
<juliank> ooh, libept is accepted, time to do rebuilds for its rdeps
<juliank> oh not publshed yet
<juliank> oh, my affected hint is wrong for apt transition, so you only see bad ones
<bluca> are syncs from unstable still happening automatically? I've fixed a silly mistake in the b-deps list in https://launchpad.net/ubuntu/+source/azure-functions-devops-build/ early this morning
<vorlon> bluca: yes, until EOD Pacific coast time
<vorlon> LocutusOfBorg, kenvandine, marcustomlinson: I am killing all libreoffice/arm64 autopkgtests from the queue, please don't queue any more; these timeouts are choking the infra.  We will treat this as a badtest for now
<sforshee> can linux-firmware 1.173.15 in bionic be promoted? It looks ready to me
<vorlon> by promoted, you mean the sru released to -updates?
<sforshee> vorlon: yes
<vorlon> yes, doing
<sforshee> ta
<vorlon> xnox: I've done what I can to clear out the autopkgtest regressions for your glibc upload (by badtesting those reproducible in updates), but there are some that seem to really be proposed-only; nauty/i386 is really weird
<vorlon> doko: what did you say was the blocker for removing python3.7 right now?
-queuebot:#ubuntu-release- New binary: python-pweave [amd64] (focal-proposed/universe) [0.25-2] (no packageset)
-queuebot:#ubuntu-release- New binary: smrtanalysis [amd64] (focal-proposed/universe) [0~20200227] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-pweave [amd64] (focal-proposed) [0.25-2]
-queuebot:#ubuntu-release- New: accepted smrtanalysis [amd64] (focal-proposed) [0~20200227]
-queuebot:#ubuntu-release- New binary: gnumed-server [amd64] (focal-proposed/universe) [22.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnumed-server [amd64] (focal-proposed) [22.9-1]
<vorlon> rafaeldtinoco: hivex also rolled back, same rationale (ocaml+ruby)
<rafaeldtinoco> cool
<xnox> vorlon:  i've seen weird things on i386, as if the machines started to use 64bit kernel; because some packages started to try to search for 64bit implementation of things, instead of 32bit ones. Do we know if images have changed in eoan to use 64bit kernel and for example some packages didn't run tests in eoan, since that change?
<vorlon> xnox: but a baseline retest of that one succeeded, it only failed with the new glibc
<xnox> vorlon:  excellent. it does suggest a missbuilt glibc.
<xnox> and nauty itself hasn't been rebuilt in ages.
<vorlon> except via the rebuild autopkgtest
<xnox> checked rebuild test results for disco & eoan they don't list it
<LocutusOfBorg> vorlon, are you available for some quick migration? 1) reposurgeon -> NBS on armhf in proposed, removed in debian 2) gazebo: amd64 only package, needs a permanent hint everywhere else
<LocutusOfBorg> and this https://code.launchpad.net/~till-kamppeter/britney/hints-ubuntu/+merge/379911
<LocutusOfBorg> its a matter of kick the can along
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.8 => 0.7.5-1ubuntu16.9] (core)
<xnox> vorlon:  there are two tests, make-check and build-examples. The build-examples autopkgtest depends on build-essential and after failing initially, it does use all-proposed and installs both libc6-dev and libc6. During the make-check test, it does not depend on build-essential and there is this gem in the log:
<xnox> Holding Back libc6-dev:i386 rather than change libc6:i386
<xnox> meaning that neither new libc6 got installed, nor libc6-dev got installed thus leading to
<xnox> naucompare.c:5: error: include file 'stdio.h' not found
<doko> vorlon: uwsgi-plugin-python3
<xnox> vorlon:  in an eoan i386 schroot, with manually installed libc6-dev & libc6 from proposed, ./debian/tests/make-check passes
<xnox> vorlon:  https://paste.ubuntu.com/p/X8mqs53rcs/
-queuebot:#ubuntu-release- New binary: kodi [s390x] (focal-proposed/universe) [2:18.5+dfsg1-0ubuntu2] (no packageset)
<rbalint> sil2100, ec2-instance-connect is now really verified
<bluca> can a build be done with a profile (say "nocheck") to break a build-time tie?
<vorlon> xnox: ah, right, this is the arch skew bug with the foreign-arch hinting, I think?  hmm I thought I had patched that?  anyway, if you retry it with all-proposed=1 I think it should pass
<vorlon> LocutusOfBorg: reposurgeon/armhf removed
<sil2100> rbalint: on it!
<vorlon> LocutusOfBorg: libqtpropertybrowser-dev is amd64-only?  that seems... weird
<vorlon> LocutusOfBorg: anyway, gazebo hinted
<rafaeldtinoco> there is a dead-lock in build-dependency among jruby and ruby-psych packages.. debian has done a binary upload to unlock this ..
<rafaeldtinoco> can I upload a binary for ruby-psych, build jruby, and upload ruby-psych in source again ?
<rafaeldtinoco> would that be possible ?
<rafaeldtinoco> to unlock this situation ?
<bluca> (same for azure-cli and azure-functions-devops-build which is the reason I asked about the nocheck profile build)
<rafaeldtinoco> for my case I would need "sid" binaries of libpsych-java_3.1.0+really3.1.0-1_all.deb AND ruby-psych_3.1.0+really3.1.0-1+b1_amd64.deb for amd64, arm64, armhf, ppc64el, s390x into -proposed
<rafaeldtinoco> that would allow be to build jruby
<rafaeldtinoco> and rebuild ruby-psych and libpsych-java would work
<rafaeldtinoco> just tested and it worked
<rafaeldtinoco> vorlon: ^ any comment on that ?
<rafaeldtinoco> would that be possible ?
<rafaeldtinoco> this would unlock the ruby transition
<rafaeldtinoco> https://people.canonical.com/~ubuntu-archive/transitions/html/html/ruby2.7-add.html
<rafaeldtinoco> kanashiro: fyi ^
<LocutusOfBorg> rafaeldtinoco, no
<LocutusOfBorg> you can't upload binaries
<rafaeldtinoco> yep, would it be possible for an AA to do it
<LocutusOfBorg> you can add a binary such as jruby into ruby-psych/debian directory and call it directly
<rafaeldtinoco> bringing from sid
<LocutusOfBorg> and then no change rebuild
<LocutusOfBorg> this is how I do it usually
<rafaeldtinoco> yep but there are multiple arches
<LocutusOfBorg> you add multiple binaries :p
<rafaeldtinoco> =o)
<LocutusOfBorg> and then call the one directly
<rafaeldtinoco> well, i can uncompress the debian binary
<rafaeldtinoco> from debian/ and do lots of things
<rafaeldtinoco> but syncing 2 binaries from sid
<rafaeldtinoco> seem easier, no ?
<rafaeldtinoco> they will go away right after
<rafaeldtinoco> as soon as the first (jruby) is compiled
-queuebot:#ubuntu-release- New binary: kodi [amd64] (focal-proposed/universe) [2:18.5+dfsg1-0ubuntu2] (no packageset)
<LocutusOfBorg> rafaeldtinoco, if possible, yes
<LocutusOfBorg> :)
<rafaeldtinoco> let's see
-queuebot:#ubuntu-release- New binary: kodi [ppc64el] (focal-proposed/universe) [2:18.5+dfsg1-0ubuntu2] (no packageset)
<vorlon> doko: I think I heard you mention gnat earlier, what's the analysis here on plplot vs gnat-8 vs gnat-9? why is it depending on gnat+gnat-9?
<vorlon> doko: ah because there's a new gnat metapackage in -proposed, ignore me
<bluca> LocutusOfBorg: no profiles either? I'll do an upload to sid without the dependency then, and change it manually later - it's just for tests
<bluca> too bad we can't set nocheck or stage1 or whatev
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.15 => 1.173.16] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (eoan-proposed) [2.620.1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.620 => 2.620.1] (desktop-core)
-queuebot:#ubuntu-release- Packageset: Removed boost1.67 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed python3.7 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added amtk to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added mapbox-geometry to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added mapbox-variant to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added mapbox-wagyu to i386-whitelist in focal
<kanashiro> vorlon, could you please provide some feedback about rafaeldtinoco's proposal above regarding ruby-psych and jruby situation?
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1073.78]
<vorlon> rafaeldtinoco, kanashiro: "upload a binary" - no, that's not an option
<rafaeldtinoco> no no I know
<rafaeldtinoco> what about U copying from debian temporarily ?
<rafaeldtinoco> is that an option ?
<vorlon> rafaeldtinoco: we can't copy binaries from Debian, no
<rafaeldtinoco> ok
<rafaeldtinoco> trying to find alternatives =)
<vorlon> I mean, I could use a Debian binary in the bootstrap archive
<vorlon> if that's really the only way
<vorlon> but that requires an AA to do it
<rafaeldtinoco> let me explain to see if you can come up with any idea
<rafaeldtinoco> if I have libpsych-java and ruby-psych installed (from sid) I can compile jruby and then I can compile ruby-psych and libpsych-java
<rafaeldtinoco> somehow debian got itself in a build-dependency loop by copying binaries over the releases
<rafaeldtinoco> ruby-psych was turned into a dependency for jruby to yaml wrapping
<rafaeldtinoco> i can generate jruby without ruby-psych, but then it complains about not supporting it when trying to compile ruby-psych itself
<vorlon> rafaeldtinoco: is there an earlier, interim version of either package that was in Debian that didn't have the circular dep?
<rafaeldtinoco> yes but using ruby2.5
<vorlon> ah
<rafaeldtinoco> not ruby2.7
<vorlon> but would it build in Ubuntu against ruby2.7 if we synced it?
<rafaeldtinoco> kanashiro: ^ u know ?
<rafaeldtinoco> kanashiro: was the one working with debian ruby team
 * rafaeldtinoco checking git in salsa
<kanashiro> I have no idea
<kanashiro> need to try it
<rafaeldtinoco> debian has binary copied it also
<rafaeldtinoco> for sid, is that correct ?
<rafaeldtinoco> (over the releases I mean)
<rafaeldtinoco> and it contained 2.5 and 2.7
<kanashiro> debian sid now has ruby 2.5 and 2.7 enabled
<rafaeldtinoco> commit f7bfddd57
<rafaeldtinoco> Author: Miguel Landaeta <nomadium@debian.org>
<rafaeldtinoco> Date:   Sat Sep 16 20:41:24 2017
<rafaeldtinoco>     Fix dependencies on ruby-psych and add dependencies on libpsych-java
<rafaeldtinoco> debian/9.1.8.0-3
<rafaeldtinoco> this is the tag where it got included
<rafaeldtinoco> let me see if I can build that version
<kanashiro> that is before the current debian stable release, the chances are low of this jruby version builds fine against ruby 2.7
<rafaeldtinoco> -               ruby-json,
<rafaeldtinoco> it used ruby-json before
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [amd64] (focal-proposed/main) [20.2.1~0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [s390x] (focal-proposed/main) [20.2.1~0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [ppc64el] (focal-proposed/main) [20.2.1~0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [arm64] (focal-proposed/main) [20.2.1~0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [armhf] (focal-proposed/main) [20.2.1~0ubuntu1] (core)
<rafaeldtinoco> the version not depending on psych is so old
<rafaeldtinoco> i can't get it to build
<vorlon> ok
<vorlon> then we might have to resort to the bootstrap archive
<rafaeldtinoco> yes, sorry about that
<rafaeldtinoco> i really spent a bunch of time on this trying to avoid
<rafaeldtinoco> but ruby with java is really not my style to come up with some magick
<rafaeldtinoco> ill have a rebuild for both pkgs ready
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.40 => 2.525.41] (desktop-core)
<vorlon> xnox: o hey, all autopkgtests for glibc/eoan cleared
-queuebot:#ubuntu-release- New binary: libxml2 [s390x] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxml2 [i386] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxml2 [ppc64el] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxml2 [amd64] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxml2 [arm64] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libxml2 [armhf] (focal-proposed/main) [2.9.10+dfsg-4] (core, i386-whitelist)
#ubuntu-release 2020-02-28
<LocutusOfBorg> vorlon, is it possible to badtest therion/i386 please? autopkgtest for therion/5.4.4ds1-5ubuntu1: amd64: Pass, arm64: Test in progress, armhf: Pass, i386: Regression â» , ppc64el: Pass, s390x: Pass
<LocutusOfBorg> it is NBS there
-queuebot:#ubuntu-release- New: accepted libxml2 [amd64] (focal-proposed) [2.9.10+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libxml2 [armhf] (focal-proposed) [2.9.10+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libxml2 [ppc64el] (focal-proposed) [2.9.10+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libxml2 [arm64] (focal-proposed) [2.9.10+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libxml2 [s390x] (focal-proposed) [2.9.10+dfsg-4]
-queuebot:#ubuntu-release- New: accepted libxml2 [i386] (focal-proposed) [2.9.10+dfsg-4]
<vorlon> LocutusOfBorg: committed before you asked
<vorlon> LocutusOfBorg: everything not in the i386 whitelist is an automatic badtest on i386, but I don't have a complete list of what needs hinting so they only get added when I see them in update_excuses
<xnox> vorlon: Yeap, I did do retry with all-proposed=1 and it did work. We can start new glibc srus!
-queuebot:#ubuntu-release- New binary: kodi [arm64] (focal-proposed/universe) [2:18.5+dfsg1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: azure-functions-devops-build [amd64] (focal-proposed/universe) [0.0.22-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rubydns [amd64] (focal-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.16]
-queuebot:#ubuntu-release- New binary: trilinos [s390x] (focal-proposed/universe) [12.14.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: trilinos [amd64] (focal-proposed/universe) [12.14.1-3] (no packageset)
<cpaelzer> Hiho, trying to clean up a tail of a set of packages that got uploaded to Debian recently to complete and get unstuck
<cpaelzer> I've found that https://launchpad.net/ubuntu/+source/azure-functions-devops-build/0.0.22-3 is stuck in the new queue (passed in Debian a bit ago)
<cpaelzer> that holds back https://launchpad.net/ubuntu/+source/azure-devops-cli-extension/0.17.0-2 and https://launchpad.net/ubuntu/+source/azure-cli/2.0.81+ds-2 for build dependencies
<cpaelzer> if the former could eb accepted in the new queue all of that should get out of our way completely I'd hope
<cpaelzer> therefore if an AA is around ^^ vorlon: apw: doko:
<vorlon> cpaelzer: done
-queuebot:#ubuntu-release- New: accepted trilinos [amd64] (focal-proposed) [12.14.1-3]
-queuebot:#ubuntu-release- New: accepted azure-functions-devops-build [amd64] (focal-proposed) [0.0.22-3]
-queuebot:#ubuntu-release- New: accepted trilinos [s390x] (focal-proposed) [12.14.1-3]
-queuebot:#ubuntu-release- New: accepted ruby-rubydns [amd64] (focal-proposed) [1.0.3-3]
<cpaelzer> thank you so much vorlon
<cpaelzer> vorlon: I was searching my inbox for the freeze mail just minutes ago and wondered, and now here it is :-)
<vorlon> magic
<cpaelzer> vorlon: it is late for you right as it says "eoan-proposed" :-)
<vorlon> oops
<cpaelzer> I mean everybodey knows what is meant, but that way you can reply before ohters do :-)
<vorlon> nah, I'm not going to bother replying
<cpaelzer> k, I also see yesterday ocaml and python seem to have moved as things depending on them migrated
<cpaelzer> this is a good start of the day
<vorlon> yes indeed
<vorlon> now, php and ruby
<vorlon> which are intertwined
<vorlon> do we need some retries of these ruby tests with --all-proposed?  and should we dump the arm64 ones from the queue that don't have it?
<cpaelzer> kanashiro: was not giving me any details on ruyb-* yesterday so I can only guess
<cpaelzer> but I assume yes
<cpaelzer> he was going for a next-stage in the transition and maybe that is what you see
<cpaelzer> those would most likely indeed need all-proposed to pick up the new defaults
<ginggs> vorlon: if you have a chance, please LP: #1863596
<ubot5> Launchpad bug 1863596 in satpy (Ubuntu) "satpy: autopkgtests run out of memory" [Undecided,New] https://launchpad.net/bugs/1863596
<vorlon> ginggs: done and deployed, feel free to resubmit the tests
<ginggs> vorlon: thanks!
<vorlon> rafaeldtinoco, kanashiro: what is the version of jruby you're trying to build?  because the only one I see in Debian is the one we have in focal
<vorlon> ah, same version but different dependencies
-queuebot:#ubuntu-release- New binary: azure-cli [amd64] (focal-proposed/universe) [2.0.81+ds-2] (no packageset)
<cpaelzer> umm, https://launchpad.net/ubuntu/+source/azure-cli/2.0.81+ds-2 is now the next in the new queue to be stuck
<cpaelzer> same context as above and yesterday
<cpaelzer> they resolve biuld deps once the former one passes
<cpaelzer> and then the next one hits new queue
<cpaelzer> vorlon: ^^ if you are still around
<cpaelzer> the enxt one to follow later (the last one) will then be https://launchpad.net/ubuntu/+source/azure-devops-cli-extension/0.17.0-2
<cpaelzer> might be offline now, pinging the other AAs that come to mind and being around now apw: doko: didrocks: ^^
<didrocks> hey cpaelzer
<cpaelzer> o/
<didrocks> cpaelzer: if I get you you need a NEW BIN review of azure-cli (amd64)?
<cpaelzer> yes it is in the new queue atm
<didrocks> downloading and looking
<didrocks> cpaelzer: done (in universe)! bonus point if you get the small lintian warning (not the manpage one but the package description) in next upload :p
-queuebot:#ubuntu-release- New: accepted azure-cli [amd64] (focal-proposed) [2.0.81+ds-2]
<cpaelzer> I know someone who can do that ... :-)
<didrocks> heh :p
<cpaelzer> thank you didrocks
<didrocks> yw
<LocutusOfBorg> ocaml is done <3
<LocutusOfBorg> vorlon, the I think we should bootstrap it, I can copy the binaries and do it on bileto
<LocutusOfBorg> rafaeldtinoco, ^^ will you do it?
-queuebot:#ubuntu-release- New: accepted kodi [amd64] (focal-proposed) [2:18.5+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kodi [ppc64el] (focal-proposed) [2:18.5+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [amd64] (focal-proposed) [20.2.1~0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [armhf] (focal-proposed) [20.2.1~0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [s390x] (focal-proposed) [20.2.1~0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kodi [arm64] (focal-proposed) [2:18.5+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [arm64] (focal-proposed) [20.2.1~0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kodi [s390x] (focal-proposed) [2:18.5+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [ppc64el] (focal-proposed) [20.2.1~0ubuntu1]
<juliank> Laney: I'm confused why _everything_ on arm64 is in huge queues
<Laney> juliank: that's what proposed-migration does, you can find the logic in the code there
<juliank> hmm
<Laney> It's if there are more than 20(?) triggers for a migration item
<juliank> I see
<juliank> it seems to be somewhere around there, yes
<Laney> so now if some smaller things come in, the idea is that they will not be starved out by the big stuff
 * Laney smacks bileto
-queuebot:#ubuntu-release- New binary: azure-devops-cli-extension [amd64] (focal-proposed/universe) [0.17.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe-tools [amd64] (focal-proposed/universe) [1:7.2.7.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe-tools [armhf] (focal-proposed/universe) [1:7.2.7.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe-tools [s390x] (focal-proposed/universe) [1:7.2.7.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe-tools [arm64] (focal-proposed/universe) [1:7.2.7.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe-tools [ppc64el] (focal-proposed/universe) [1:7.2.7.2-4ubuntu1] (no packageset)
<mvo> is 1865055 on someones radar? file-overwrite issue when upgrading to focal in iptables
<Laney> jdstrand: ^- your upload (probably)
<rafaeldtinoco> release team, I still got: https://people.canonical.com/~ubuntu-archive/transitions/html/html/ruby2.7-add.html to finish
<rafaeldtinoco> they're all no-change rebuilds so I guess its fine
<rafaeldtinoco> vorlon: With the binaries ruby-psych and libpsych-java (from sid) I can submit a new rebuild for Jruby. After that, ruby-psych and libpsych-java will get rebuilt based on latest upload and dead lock is gone for ruby2.7.
<bluca> azure-devops-cli-extension mentioned above in NEW is the very last in the azure-cli rigamarole. Phew!
<cpaelzer> HI AAs (again) to finish the azure-* packages now the last one finally built and is now itself stuck in the new queue https://launchpad.net/ubuntu/+source/azure-devops-cli-extension/0.17.0-2
<cpaelzer> didrocks: FYI I got a confirmation that the lintian warning of the one this morning will be looked at
<cpaelzer> seb128: didrocks: doko: apw: if anyone of you has time to accept that from the new queue that would be great
<cpaelzer> bluca: ^^ FYI
-queuebot:#ubuntu-release- New: accepted azure-devops-cli-extension [amd64] (focal-proposed) [0.17.0-2]
-queuebot:#ubuntu-release- New: accepted ipe-tools [arm64] (focal-proposed) [1:7.2.7.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipe-tools [ppc64el] (focal-proposed) [1:7.2.7.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipe-tools [amd64] (focal-proposed) [1:7.2.7.2-4ubuntu1]
<bluca> thank you!
-queuebot:#ubuntu-release- New: accepted ipe-tools [s390x] (focal-proposed) [1:7.2.7.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted ipe-tools [armhf] (focal-proposed) [1:7.2.7.2-4ubuntu1]
<locutus_> rafaeldtinoco, are you working on it?
<locutus_> I can do it
<rafaeldtinoco> locutus_: on what, sorry
<rafaeldtinoco> locutus_: the transition ?
<rafaeldtinoco> missing a few rebuilds and blocked by jruby / ruby psych
<rafaeldtinoco> will be in about 1hr to continue
<kanashiro> rafaeldtinoco, I think locutus_ is talking about jruby and ruby-psych
<rafaeldtinoco> oh I'd love that, yep
<rafaeldtinoco> having both pkgs for all arches coming from Sid would allow us to rebuild jruby and unblock them
<locutus_> yes sure
<locutus_> https://bileto.ubuntu.com/log/3957/build/1/
<locutus_> I prepared a bileto
<locutus_> rafaeldtinoco, I'll rebuild jruby without psych support
<locutus_> rebuild psych
<locutus_> rebuild jruby with the support
<locutus_> rebuild psych
<locutus_> publish
<locutus_> end
<kanashiro> thanks for tackling this locutus_ :)
<locutus_> you can see progresses here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3957/+packages
<locutus_> please avoid uploads unrelated to them until I say that is green to go
<locutus_> I want a no-change rebuild of them after they publish in the archive
<kanashiro> locutus_, ack
<ginggs> satpy now has a test dependency on python3-zarr which is non-installable on s390x due to python3-numcodecs not being available there, what's the way forward?
<Laney> would be nice if someone could nbs-cleanup mutter in focal-proposed
<Laney> seb128: ^?
<seb128> Laney, k
<Laney> thanks!
<seb128> np!
<seb128> we will need a libreoffice rebuild and to clear gnome-desktop/poppler for things to migrate though
<seb128> so probably not going to be this week :/
<seb128> well, maybe better to not risk breaking focal before w.e/travelling :)
<jdstrand> mvo, Laney: https://launchpad.net/ubuntu/+source/iptables/1.8.4-3ubuntu2 (and submittodebian'd)
<mvo> jdstrand: \o/
<rafaeldtinoco> LocutusOfBorg:
<rafaeldtinoco> +	tar xvf debian/data.tar.xz -C debian
<rafaeldtinoco> +	cp debian/usr/share/java/psych.jar lib/psych.jar
<rafaeldtinoco> i see your technique now
<rafaeldtinoco> loved it
<rafaeldtinoco> and thanks for doing it
<Laney> jdstrand: thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1057.61] (kernel)
<locutus_> rafaeldtinoco, I feel dirty :D
<rafaeldtinoco> haha its like cheating
<locutus_> I started doing that with nodejs stuff
<locutus_> embedding the node_modules.tar.gz and unpacking it :p
<rafaeldtinoco> whatever it takes!
<rafaeldtinoco> im just glad this will be unlocked, thx a lot
<locutus_> I'm uploading a ruby-psych that hopefully will build fine
<rafaeldtinoco> cool! kanashiro ^
<locutus_> if it builds on the ppa, two rebuilds and publish in 1h or so
<locutus_> so, before tonight, I'll give green light
<rafaeldtinoco> sounds great.
<rafaeldtinoco> ruby transition almost finishing
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1057.61]
<kanashiro> awesome, thanks again locutus_
<ahasenack> vorlon: thanks for the bind-dyndb-ldap rebuild, I was going to trigger that today
<ahasenack> vorlon: I'll check update_output.txt to see what's left
<vorlon> ahasenack: debian-installer is all that's left, and it needs linux-meta to drop the snapdragon metapackages for a kernel flavor we're no longer building
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.41]
<ahasenack> I checked its build logs the other day, it did seem to have picked up the new bind9-libs, but also some old udebs
<vorlon> right
<vorlon> I reuploaded debian-installer too to fix that
<ahasenack> vorlon: can you please reject https://code.launchpad.net/~ahasenack/britney/bind9-i386-dnsutils/+merge/379886 ?
<vorlon> ahasenack: done, thanks
<ahasenack> o/
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.40 => 2.525.41] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-176.206] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-176.206]
<seb128> could an archive admin nbs mutter from focal-proposed?
<seb128> I forgot to do it this afternoon and I'm on a laptop without my credentials to do it atm...
<seb128> vorlon, ^ if you are around today?
<vorlon> looking
<vorlon> seb128: done
<seb128> vorlon, thanks
-queuebot:#ubuntu-release- Unapproved: crash (eoan-proposed/main) [7.2.6-1build1 => 7.2.8-1ubuntu0.19.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: crash (bionic-proposed/main) [7.2.1-1ubuntu2 => 7.2.8-1ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (eoan-proposed) [19.03.6-0ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-91.92] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-42.34] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-42.34] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-42.34] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1005.5] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-91.92] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-42.34] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (bionic-proposed) [19.03.6-0ubuntu1~18.04.1]
#ubuntu-release 2020-02-29
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-42.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-42.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-42.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-42.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-91.92]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-91.92]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1005.5]
<vorlon> seb128: fyi I notice gnome-books is going to hold up the gnome-desktop3 transition, the Debian maintainer added a dep on tracker-miners which is not a binary package anywhere
<vorlon> seb128: ah and Debian bug #950644 was reopened; I'll just upload the right fix
<ubot5> Debian bug 950644 in gnome-books "gnome-books: Should depend on tracker-extract" [Serious,Open] http://bugs.debian.org/950644
<vorlon> also you're not here, thanks irc client desync
-queuebot:#ubuntu-release- New binary: gr-osmosdr [amd64] (focal-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-osmosdr [s390x] (focal-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-osmosdr [ppc64el] (focal-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-osmosdr [armhf] (focal-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-osmosdr [arm64] (focal-proposed/universe) [0.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gr-osmosdr [amd64] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted gr-osmosdr [armhf] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted gr-osmosdr [s390x] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted gr-osmosdr [arm64] (focal-proposed) [0.2.0-2]
-queuebot:#ubuntu-release- New: accepted gr-osmosdr [ppc64el] (focal-proposed) [0.2.0-2]
<LocutusOfBorg> rafaeldtinoco, kanashiro all is ok
<LocutusOfBorg> jruby is in release, the other one in proposed with green autopkgtests
<LocutusOfBorg> now please fix the test failures :D
-queuebot:#ubuntu-release- New binary: plplot [s390x] (focal-proposed/universe) [5.15.0+dfsg-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [amd64] (focal-proposed/universe) [5.15.0+dfsg-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [ppc64el] (focal-proposed/universe) [5.15.0+dfsg-12ubuntu1] (no packageset)
<LocutusOfBorg> kanashiro, just FTR you added both ruby support in unstable, so next time, to avoid this chicken and egg nightmare, just sync the unstable version, rebuild jruby and psych and then sync from experimental
<LocutusOfBorg> so we should avoid that loop, right?
-queuebot:#ubuntu-release- New binary: plplot [arm64] (focal-proposed/universe) [5.15.0+dfsg-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plplot [armhf] (focal-proposed/universe) [5.15.0+dfsg-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted plplot [amd64] (focal-proposed) [5.15.0+dfsg-12ubuntu1]
-queuebot:#ubuntu-release- New: accepted plplot [armhf] (focal-proposed) [5.15.0+dfsg-12ubuntu1]
-queuebot:#ubuntu-release- New: accepted plplot [s390x] (focal-proposed) [5.15.0+dfsg-12ubuntu1]
-queuebot:#ubuntu-release- New: accepted plplot [arm64] (focal-proposed) [5.15.0+dfsg-12ubuntu1]
-queuebot:#ubuntu-release- New: accepted plplot [ppc64el] (focal-proposed) [5.15.0+dfsg-12ubuntu1]
<RikMills> vorlon: you skiptested libx11. great & thanks, as Kubuntu CI had some build fails due to headers removed from xorgproto -dev packages in -release, moved to libx11 in proposed
-queuebot:#ubuntu-release- New binary: rustc [s390x] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
<vorlon> RikMills: well, headers moving around like that is something that ought to be accompanied by versioned depends or breaks :/
-queuebot:#ubuntu-release- New binary: rustc [i386] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (focal-proposed/universe) [1.40.0+dfsg1+llvm-5ubuntu1] (i386-whitelist)
#ubuntu-release 2020-03-01
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-17.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-17.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-17.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-17.21] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-17.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-17.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-17.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-17.21]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-91.92~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-42.34~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-91.92~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-42.34~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-42.34~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-42.34~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-42.34~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-42.34~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-91.92~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-91.92~16.04.1]
