#ubuntu-release 2011-02-22
<hggdh> someone please have a look at bug 723148
<ubot4> Launchpad bug 723148 in debian-installer (Ubuntu) "Natty server ISO images fail to install (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/723148
<cjwatson> hggdh: I'll sort it out now
<cjwatson> actually, WTF, d-i already moved to 2.6.38-4
<cjwatson> did you check the server CD build logs?
<cjwatson> looks ok though
<cjwatson> oh, of course, d-i failed to build
 * cjwatson goes to hassle the utouch guys again
<cjwatson> actually, I can sort it out for myself now
<hggdh> cjwatson: thank you, and sorry, I was out on a dr. appointment
<davmor2> hggdh: it's okay cjwatson loves one sided arguments he wins them :D
<hggdh> heh
<charlie-tca> Is it known that the alternate images are failing to install - No kernel modules were found ?
<charlie-tca> no errors in todays logs
<cjwatson> yes
<cjwatson> bug 723148
<ubot4> Launchpad bug 723148 in debian-installer (Ubuntu) "Natty server ISO images fail to install (affects: 2) (dups: 1) (heat: 14)" [High,New] https://launchpad.net/bugs/723148
<charlie-tca> Thanks
<charlie-tca> I won't file a duplicate then
<cjwatson> could an archive admin please look at utouch-frame in NEW?
<slangasek> looking
<cjwatson> slangasek: thanks
<slangasek> n/p
 * cjwatson uploads the fixed utouch-grail; d-i should be retriable after that
#ubuntu-release 2011-02-23
<stgraber> hmm http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/latest/livecd-20110223-amd64.out is still failing though I can't reproduce the issue on my laptop
<stgraber> anyone knows what's wrong ? (doing an apt-get install with all the mentioned packages work fine on up to date natty amd64)
<stgraber> hmm, actually I can reproduce the ghostscript part of it, but not the rest
<stgraber> nevermind, it's fixed
<stgraber> for some reason we had two packages in our seeds that came are in multiverse
<stgraber> I just removed them, daily should be fine again tomorrow, though it'd be nice if we could get a respin so we can test our new installer plugin :)
 * ogra tickles skaet_ 
 * skaet_ giggles
<ogra> skaet_, when do you plan to make FF take effect tomorrow ?
<ogra> the unity-2d guys just let me know they might be late with their last upstream version tomorrow (and i then still need to package it)
<ogra> (taking about UTC times here)
<skaet_> ogra,  I was planning to send it out around my lunch time, which should be the end of your day.
<ogra> ah, perfect, that should fit fine then, thanks
<skaet_> :)
<hggdh> may I get anyone interested in https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/723482 ?
<ubot4> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22 (affects: 2) (heat: 14)" [High,New]
<ev> robbiew, skaet_ feature freeze exception request: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/723849
<ubot4> Launchpad bug 723849 in ubiquity (Ubuntu) "Feature freeze exception for ask page remodeling and package preservation option (affects: 1) (heat: 8)" [Undecided,New]
<robbiew> ev: ack
<ScottK> ev: It would be useful to know when you think you can land the changes you're requesting FFe for (best to put it in the bug).
<ev> ScottK: updated
<skaet_> ev, which milestone are you targetting with this?  alpha 3 or beta?
 * cjwatson would appreciate NEWage of libpci3-udeb and biosdevname, if anyone has some time
<skaet_> reminder:  Feature Freeze for Natty will be at 1600 UTC on Feb 24th.
<skaet_> s/1600/1800/
<skaet_> ev,  by the way,  very nice new interface for the partitioner.   :)
#ubuntu-release 2011-02-24
<ev> skaet_: alpha 3, and thanks!
<jibel> cjwatson, Hi, alternate and server fail to install this morning, I filed bug 724242.
<ubot4> Launchpad bug 724242 in debian-installer (Ubuntu Natty) (and 1 other project) "alternate and server images fail to install: d-i stops with "Your installation CD-ROM couldn't be mounted" (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/724242
<cjwatson> noted
 * cjwatson waits for jigdo
<lamont> someone want to sync over bind9 from sid to clear the ~build1 from the version string?
<lamont> ditto for postfix
<cjwatson> lamont: done
<ev> I'd like to capitalize natty in lsb-release. Any objections?
<cjwatson> I'm concerned that that will break existing scripts
<cjwatson> consumers that want to present it in title-case should do that themselves IMO
<cjwatson> unless you mean in DISTRIB_DESCRIPTION
<ev> in this case indeed I do
<cjwatson> ah, right.  it's fine to change DISTRIB_DESCRIPTION, but DISTRIB_CODENAME needs to stay the way it is
<ev> (context: os-prober)
<ev> hooray
<cjwatson> DISTRIB_DESCRIPTION only uses the codename during development anyway :)
<ev> indeed
<ev> done. base-files 5.0.0ubuntu27.  Thanks, cjwatson.
<cjwatson> could anyone look at libpci3-udeb and biosdevname in NEW, please?
<micahg> hi, I was looking at merge requests for cairo-dock (2.2.x -> 2.3.0~rc1), cairo-dock-plug-ins (2.2.x -> 2.3.0~rc1), and latexilla (0.2.0 -> 2.0.5), I'd actually like to spend a little more time with the proposer regarding the packaging changes, would I be able to get a freeze exceptions for these, I can provide the bug numbers as well
<skaet_> Riddell,  cjwatson, pitti - soft freeze for alpha 3 next week on Monday 1800 UTC ok?  That give enough time to have images for QA/testing on Tues AM?
<cjwatson> we could afford a bit later to let the US have a bit more of a day's work
<cjwatson> say 2300 UTC?
<skaet_> cjwatson,  cool.   will use that then.
<micahg> skaet_: can I get an exception for the above ^^, they're all leaf packages
<ScottK> micahg: leaf packages on images?
<skaet_> micahg, if they're leaf packages in terms of other packages not having dependencies on them, that should be ok.   Please subscribe me to the bug, when you set it up so I can track.
<micahg> ScottK: the ones I asked for are not on images
<micahg> skaet_: will do, thanks, I'll update the bugs asking for the FFe
<ScottK> If they're in Universe, the freeze doesn't apply.
<ScottK> (may still need FFe)
<micahg> ScottK: they're in universe, but I was asking for FFe :)
<ScottK> Ah.  OK.  I thought it was about the Alpha 3 freeze.  Nevermind.
 * micahg thought that was Tuesday
<micahg> skaet_: can I just subscribe ubuntu-release or do you want an individual subscription?
<skaet_> individual please,  not sure its of general interest.
<micahg> skaet_: ok, thanks!
<skaet_> thanks micahg!  :)
<jdstrand> skaet_: so, when is the FF now?
<jdstrand> skaet_: the time that is. 15 mintues or 23:00 UTC?
<skaet_> jdstrand,  I'll be sending out the announce of FF in about 15 minutes.
<jdstrand> skaet_: ack
<skaet_> 2300 UTC is for alpha 3 soft freeze on monday.  :)
<ogra> phew, monday ?
 * ogra hasnt had working images since two weeks
<ogra> thanks to nux being broken on armel and upstream not reacting to patches
 * ogra senses some weekend and nightshifts after returning from cambridge tomorrow
<cjwatson> ogra: my Cambridge?
<ogra> cjwatson, heh, yeah
<ogra> its lovely !
<cjwatson> ogra: if you're free this evening, I'm going to be in the Salisbury Arms later
 * ogra is sitting in the arm headquaters, between kinnison and wookey
<cjwatson> they'll probably know where it is, it's near the rail station
<cjwatson> oh man, the emdebian sprint, I completely forgot about that
<ogra> yeah
 * iulian is probably going to Cambridge on Saturday.
<iulian> skaet_: There's no motu-release anymore.
<skaet_> iulian,  thanks.  didn't know.   Any replacement?
<iulian> Just ubuntu-release.
<ScottK> The teams were merged.
<skaet_> micahg,  on the bug,  can you please subscribe ubuntu-release.   That's the better thing to do.
<iulian> Indeed.
#ubuntu-release 2011-02-25
<jibel> cjwatson, alternate and server images fails to install this morning. Corrupted files on the iso. I reported bug 724822
<ubot4> Launchpad bug 724822 in debian-installer (Ubuntu) "d-i installer fails for server/alternate i386/amd64: Corrupted deb files on iso (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/724822
<jibel> ara, ^
<cjwatson> jibel: fixed
<jibel> cjwatson, thanks. btw there's no ubuntu daily-live since Feb 23rd, is it normal ?
<cjwatson> jibel: don't know, have you checked the logs?
<jibel> cjwatson, where are the logs ?
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ and http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<jibel> I'll check
<cjwatson> live filesystems fail to build for all kinds of reasons - building a live CD requires the distribution to be consistent enough that you can install ubuntu-desktop, etc.
<cjwatson> so it is fairly normal for them to fail to build for days at a time
<cjwatson> we get mailed when they fail
<cjwatson> also pitti said earlier on #ubuntu-devel:
<cjwatson> 08:13  * pitti fixes python-aptdaemon-gtk component to fix CD builds
<jibel> yeah, aptdaemon is fixed, I'm looking at empathy on amd64
<stgraber> could someone respin edubuntu ? we haven't had a working build in a while and would like to do some testing. Last build failed because of unity-2d which seems to be fixed now.
<stgraber> cjwatson, skaet_: ^
<cjwatson> stgraber: rebuilding, though I have no idea whether it will work
<skaet_> cjwatson, thanks
<skaet_> stgraber, lots of dependency issues getting cleaned up right now, with the packages landing for FF yesterday.
<smoser> skaet_, around ?
<skaet_> smoker, yup
<smoser> smoker, no
<smoser> :)
 * skaet_ was just about to head out for some lunch
<skaet_> and can't type.
<smoser> skaet_, https://bugs.launchpad.net/ubuntu/+bug/725127 . thats my FFE request
<ubot4> Launchpad bug 725127 in ubuntu "FFE: add 'cloud-initramfs-tools' package and cloud-utils update (affects: 1) (heat: 10)" [Undecided,New]
 * cjwatson kicks off yet another server CD build in the hope that it will actually pick up the new bootstrap-base this time
<stgraber> cjwatson: thanks
<skaet_> smoser,  timing wise, I think we should be good to include it still.
<smoser> its realatively simple new function that is ready to go.
<smoser> skaet_, how/when would i find out if its ok to go forward?
<skaet_> smoser, no chance of causing regressions then?
<smoser> no. its all new function.
<smoser> broadscale inclusion of the initramfs module would be not recommended, but for the targetted use in our UEC images, it should be fine.
<skaet_> ok by me then.   cjwatson ^^ do you know any reason not to upload then?
<cjwatson> don't see a problem, it seems contained
<skaet_> smoser,  upload away.
<smoser> thank you.
<bjf> skaet_, it's friday and i can only seem to remember to ask this on fridays, why do the links on: http://cdimage.ubuntu.com/releases/8.04.4/release/   point at 8.04.1 isos and not at 8.04.4 ones ?
<skaet_> bjf, agree thats weird,  i was looking the server, and it looks like it should be pointing to 8.04.4 so not sure what's happening in the translation.
<skaet_> bjf,  dug a bit deeper, and it looks like there's been an stomp at some point in the past.    Yeah,  I see it now on the server.
<skaet_> bjf,  turns out there weren't any 8.04.04 DVD builds, so 8.04.01 was put there. :P
<bjf> skaet_, were there any point releases other than .01 done ?
<skaet_> bjf, for DVD's not sure.
<skaet_> for 8.04.3 it points to 8.04.1 as well.
<jdstrand> for some reason I am not 100% certain about this. aiui, universe and multiverse are also under FF, so they need a FFe bug-- correct?
<jdstrand> skaet_: ^
<jdstrand> (I'm looking at ArchiveAdministration, FeatureFreeze and FreezeExceptionProcess
<jdstrand> )
<cjwatson> bjf: not everything always got rebuilt for all point releases, so we just carried over the old images in those cases.
<bjf> cjwatson, that's cool, it looks odd and i just wanted to make sure something hadn't gone wrong
#ubuntu-release 2011-02-26
<bigon> hi, gnome pkg get auto exceptions for feature freeze right?
<ScottK> Did anyone re-invoke DealingWithCrisis after wgrant discovered more corrupted builds?
<ScottK> cjwatson, skaet_: ^^^ ?
<ScottK> It's not clear to me it's being addressed (it may be, dunno).
<cjwatson> it's not a crisis (the impact is fairly low, according to wgrant), but the buildds for affected arches are on manual until sysadmins reappear from plane flights etc.
<cjwatson> the build queues were empty when we went onto manual, so I don't think this should be too huge a problem
<ScottK> OK.
<ScottK> I guess my major concer was there was an "it's over" email sent and with no followup when it wasn't.
<ScottK> concer/concern
<ScottK> Also any idea of the timeline for correction?  We were looking at doing a qt4-x11 upload this weekend to get ready for Alpha 3.
<cjwatson> you should upload.  I'm hoping today - the conjecture is that some of the buildd processes just weren't restarted with the fixed umask
<cjwatson> wgrant turned them all off just to be safe.
<ScottK> OK.  We're waiting on a local armel test build to make sure, so sometime today ...
<slangasek> ScottK: so speaking of qt4-x11, I think there's a general agreement that the package should switch from opengl to gles2 on armel; this would require a freeze exception, and will break a certain number of opengl-using reverse-dependencies as detailed in bug #707794 (on armel only); if I were to push a patch for that, would that be of interest for alpha3?
<ubot4> Launchpad bug 707794 in qt4-x11 (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support (affects: 1) (heat: 119)" [Undecided,Confirmed] https://launchpad.net/bugs/707794
<ScottK> slangasek: I think python-qt4 gets entangled with opengl too.  That could have a number of knock on impacts as well.
<ScottK> I think we want to switch, but I'm slightly nervous about do we fully understand the impacts.
<slangasek> if I manage to quantify that risk?
<ScottK> And it's not insane, yes.  Would you please join us in #kubuntu-devel as we're coordinating the next qt4-x11 upload there.
<slangasek> (only three reverse-deps to python-qt4-gl in the archive, fwiw)
<ScottK> Right, but it also means changes to python-qt4 for armel to build it there.
<slangasek> does it?  That surprises me
<slangasek> python-qt4 only build-depends on libqt4-opengl-dev, not directly on any of the mesa libraries, and switching to gles2 isn't supposed to break ABI for qt4-opengl
<ScottK> OK.
<ScottK> So maybe it's fine then.
<slangasek> I can certainly check it out here
<slangasek> just to be sure
<bigon> 10:55 < bigon> hi, gnome pkg get auto exceptions for feature freeze right?
#ubuntu-release 2011-02-27
<wgrant> ScottK: Hi.
<ScottK> Hello wgrant.
<wgrant> ScottK: All the builders are back now.
<wgrant> Hopefully for real this time.
<ScottK> wgrant: Cool.  Would you please reply to that effect in ubuntu-devel?
<wgrant> I didn't judge this to be critical, so I didn't invoke the incident process again. I should, however, have replied to the ubuntu-devel email.
<wgrant> Will do so now.
<ScottK> You might add that to the lessons learned in the report.
<wgrant> Incident report updated, and it looks like fpc was the only misbuilt package this time.
 * wgrant reuploads.
<ScottK> Aha!
<ScottK> "2011-02-27 00:42 James realises that he bounced the slave on ross and adare, which were both in auto and building at the time."
<ScottK> No wonder my build restarted out of nowhere.
<wgrant> ScottK: yeah, sorry about that. Although it was only 3 hours of qt4-x11 that was wasted.
<ScottK> Stuff happens.
<ScottK> I'm actually very glad to know why it happened.
<ScottK> I was afraid of some kind of hard to reproduce soyuz bug.
<wgrant> Fortunately not.
<wgrant> Come on ross...
<wgrant> Excellent, done.
<hggdh> folks, yet another ISO issue: 726131
<hggdh> bug 726131
<ubot4> Launchpad bug 726131 in debian-installer (Ubuntu) "alternate ISO: installation freezes when starting partman (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/726131
<charlie-tca> I haven't gotten any install to work this week
<hggdh> heh. I have been unable also. Even worse, I have been unable to recover my laptop
<charlie-tca> Managed to keep my natty going, but no desktop or alternate installs all week for Ubuntu and Xubuntu
<charlie-tca> and I don't get to partman, either, my alternate installs fails trying to mount the existing drives, for some reason.
<charlie-tca> They insist there is no valid filesystems
<charlie-tca> desktop just spins on "Preparing to install" ; choose download updates and 3rd party software. doesn't matter what I choose
<hggdh> yes, this is what I have just found when I downloaded & tried the DVD
<charlie-tca> Well, enough ranting. I am just really frustrated with the latest firefox now. ff4.0b12
<hggdh> the install is hanging like on my bug
<charlie-tca> this new bug or the other one?
<hggdh> I wish I could be frustrated also on ffox...
<charlie-tca> sorry
<hggdh> this new bug, 726131
<hggdh> right now I am running maverick on a laptop that would not install natty
<charlie-tca> ouch
<paultag> hey u-r. I'd like to request a FFe on Fluxbox, we have an upstream fix release. I'm working on pushing it to Debian as we speak. Who do I have to talk with?
<charlie-tca> hggdh: you make me feel better
<hggdh> charlie-tca: I am glad for that :-)
<charlie-tca> If you try the install again, take a look at Alt+F4 for the messages.
<hggdh> will do, when I get back
<charlie-tca> I am still trying to figure out why it has to mount any existing filesystems
<hggdh> charlie-tca: well, it has to find out what you have; I am not sure it is actually mounting the filesystems, but at least it has to look at the partition table
<charlie-tca> Oh, I guess that does make sense
<charlie-tca> but then, it looked like it hung because it could not determine anything about them
<charlie-tca> and it stated they were not mountable
<hggdh> might be, yes
<hggdh> <sigh/>
<hggdh> interesting is that on Hudson, using preseeds, it seems to work (at least for the server ISOs)
<charlie-tca> weird
<charlie-tca> I guess I just want images that work again.
<hggdh> :-)
<hggdh> hey
<hggdh> I just replaced the HD with a brand new one (never used), and... it seems to be working
<hggdh> now THAT is interesting
<charlie-tca> Maybe it is a bug that refuses to partition if there are existing partitions in the system?
<hggdh> sounds like, now
<charlie-tca> both drives I use are partitioned already
<charlie-tca> and VBox in natty is broken, too, waiting for the kernel
<hggdh> I thought there was a bypass to vBox, all you needed was to set a soft link
<charlie-tca> really?
<hggdh> yeah, let me see if I find it
<charlie-tca> well, let it be. It started in terminal this time. I give up
<hggdh> sudo ln -s
<hggdh> /usr/src/linux-headers-2.6.38-1-generic/include/generated/autoconf.h
<hggdh> /usr/src/linux-headers-2.6.38-1-generic/include/linux/
<hggdh> of course, change the kernel version
<hggdh> an one single line
<charlie-tca> Well, that's easy enough. thanks
<hggdh> charlie-tca: what importasnce should we give to this bug (installation fails on partman)
<hggdh> ?
<hggdh> I set it as high, but I am starting to think it should be critical
<charlie-tca> It has to be high at least, but if it is stopping all installs, it probably should be critical
<charlie-tca> you want me to set it?
<hggdh> yes, please. I am tainted, I opened it
<charlie-tca> I can do that.
<hggdh> sigh. Now it hangs, also, before (to my knowledge) any changes to the partition table
<charlie-tca> That's where mine hang, too
<charlie-tca> and, apparently, if we don't work together on these bugs, they tend to sit and stagnate
<charlie-tca> That was on the new drive, too, right?
<hggdh> correct. Still virgin
<charlie-tca> shouldn't there be, like, about 5 of us testing these things, anyway?
<hggdh> indeed
<charlie-tca> I know jibel does it, and he keeps reporting a bug a day, too
<hggdh> I know, for certain, of three ;-)
<hggdh> yeah. I give up, also.
<charlie-tca> hm, I guess that is enough, too :-)
<hggdh> I will watch the superbike race
<charlie-tca> Nascar sprint cup on FOX
<hggdh> bah. Nascar.... boring ;-) bikes are more fun
<charlie-tca> :-)
#ubuntu-release 2012-02-20
<cjwatson> Daviey: right, it's that way for performance
<cjwatson> checksumming a directory full of ISOs takes a while ...
<cjwatson> if somebody wants to change it, maybe testing whether a file is newer than the checksums file itself would be a good idea
<micahg> does gdb-mingw-w64 need an FFe since it's being built against gdb 7.4 instead of 7.3 now?
<doko> I won't think so
<micahg> ok, syncing then :)
<Riddell> cjwatson: I'm going to get rid of kubuntu-common seed unless you can think of a reason for it, it's not needed now that desktop and netbook is one image for kubuntu
<Laney> what shall we do about tesseract?
<Laney> it seems to be having a bit of a shaky start; in some ways I think the situation will be better in Q-cycle
<Laney> but the developers clearly want it
<tumbleweed> Laney: ocropus has "never had a stable release" (in their words) so maybe we should go for it?
<tumbleweed> it'll need some archive-admin review for all the new language-support packages
<Laney> possibly
<Laney> jwilk is clearly not happy though
<tumbleweed> no, he's very grumpy
<Laney> so i assume he doesn't find ocropus that bad
<tumbleweed> one assumes he likes it :)
<tumbleweed> also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658478#23
<Laney> yeah saw it
<tumbleweed> there isn't an obvious answer here
<jamespage> Daviey: as we discussed last week can I get a FFe for bug 930422 please
<jamespage> hmm - no bot - https://bugs.launchpad.net/ubuntu/+bug/930422
 * tumbleweed goes looking for a bot
<nigelb> jpds: ^^
<nigelb> jpds: ubot died
<Daviey> jamespage: looking
<Daviey> jamespage: No plans for main, right?
<jamespage> Daviey: no
<Daviey> jamespage: is the packager interested in trying to get it into Debian?
<jamespage> Daviey: I don't think so
<jamespage> but TBH I've not had the conversation with him
<Daviey> jamespage: ack'd
<jamespage> Daviey: ta
<mdeslaur> Is the publisher working? Why isn't libcryptui published to the archive yet?
<infinity> mdeslaur: Because it's in NEW.
 * infinity pokes.
<mdeslaur> oh! right, there's a new binary package!
<mdeslaur> duh :)
 * infinity nods.
<mdeslaur> infinity: can you denew it please&?
<infinity> Already done.
<mdeslaur> infinity: thanks!
<mdeslaur> Could someone please grant me a FFe for LP: #862609...I need to upload a new package in Precise to fix it.
<tumbleweed> ^ any archive-admin volunteers?
<seb128> tumbleweed, I'm not sure archive admin can grant ffe, you need a rt member, though they might be hard to find today as it's an U.S holiday
<tumbleweed> seb128: NEW packages need archive-admins to agree to review them
 * tumbleweed is RT, but not an archive-admin
<seb128> well, I'm fine reviewed it as an archive admin if somebody grants a ffe
 * tumbleweed looks
<tumbleweed> ah, ScottK beat me to it
<ScottK> ;-)
<cyphermox> Could someone please review bug 829673, I'd like an exception for this small UI change :)
<ubot2`> Launchpad bug 829673 in network-manager-applet "FFE: No easy way to turn the network menu on/off" [Wishlist,In progress] https://launchpad.net/bugs/829673
<stgraber> ScottK: wow, I think it's the first time I got a FFe approved that quickly ;) thanks!
<ScottK> No problem.  Seemed like an easy one.
<stgraber> ScottK: I'll send the call for testing now. I already have the client and the relay tested, will run the tests on the server now and planning to upload on Wednesday.
<ScottK> Great.
<mdeslaur> ScottK: thanks for the ffe for seahorse-nautilus
<ScottK> mdeslaur: You're welcome.
<mdeslaur> seb128: I uploaded seahorse-nautilus now, could you please review and denew it?
<seb128> mdeslaur, looking
<mdeslaur> seb128: thanks
<seb128> mdeslaur, thank you for working on that!
<seb128> mdeslaur, that's not going to do it sorry :-(
<seb128> mdeslaur, let's move to #ubuntu-desktop to not flood spam this channel
<mdeslaur> seb128: sure
<micahg> ScottK: that ipv6 thing for gimp looked like a feature :)
<ScottK> micahg: OK. I read bugfix release.
<ScottK> micahg: Go for it.
<micahg> thanks
#ubuntu-release 2012-02-21
<pitti> Daviey, Laney, ScottK, slangasek: do you still consider multiarching libraries FFE material? (I'd like to merge poppler with Debian to get multiarch)
<ScottK> At this point I'd say the more the better, but the big question is how it affects rdepends.
<pitti> my feeling was that it was FFE material for natty, but now we are confident enough with it
<pitti> ScottK: how could it affect rdepends? It's not a special case like gstreamer or gio, it's just a simple .so
<ScottK> I know when Qt was multiarched since the libraries were it different locations, some of the rdepends installed files in different locations.
<ScottK> This meant .install files needed updating.
<ScottK> Usually it was minor (changing a / to /*/), but the trick was finding them.
<ScottK> I'm not sure if that would be a concern for other libraries or not.
<seb128> it's not for standard libs
<pitti> we certainly did have this case for e. g. gstreamer plugins
<seb128> qt and gtk are special that they have optional .so they can load
<seb128> or gst
<pitti> or input methods
<seb128> but popple doesn't have anything like that
<ScottK> OK.
<ScottK> I think it's ok then.
<pitti> thanks
<Daviey> pitti: A core library, *maybe*.. an optiional library doesn't concern me.
<Laney> pitti: are you ok with doing GHC ~
<Laney> ~now?
<Laney> builders seem as quiet as they'll get
<pitti> Laney: seems fine, yes
<pitti> the test rebuild is done
<Laney> k
<Laney> iulian: want to fire ze missiles?
<Laney> i'll mail letting everyone to know that it should be done by syncs whenever possible
<bjf> pitti: (FYI) bug 931813 reports firewire modules copied to universe instead of main (i verified)
<ubot2`> Launchpad bug 931813 in kernel-sru-workflow "linux-lts-backport-oneiric: 3.0.0-16.29~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/931813
<pitti> bjf: fixed, thanks
<slangasek> pitti: even for standard libs, revdeps that are Doing It Wrong can FTBFS because of the path change
<pitti> slangasek: certainly
<pitti> slangasek: so would you think we rather stop multiarchification at this point?
<slangasek> pitti: I think it's subject to FFe :)
<pitti> ok
<slangasek> for things like merges where it's already done in Debian and it would otherwise go in, if it's done early I think we can reasonably make an exception
<iulian> Laney: I'd appreciate it if you could take care of uploading GHC. If you're busy, then I can deal with it on Thursday when I get back home.
<Laney> iulian: OK I will see what I can do, but I do not think I will have the energy to carry the transition completely through so help is appreciated. I'll mail devel probably.
<Laney> the Debian graph is still a fair bit more red than I expected
<Laney> http://pkg-haskell.alioth.debian.org/haskell-pkg-graph.pdf
<iulian> Laney: I will do as many uploads as I can in the weekend. I just don't have time to work on GHC right now.
<Laney> the weekend is pretty bad for me
<Laney> running these transitions is pretty emotionally tiresome; I wish computers could just take care of it already
<Laney> of course I should put up and implement binNMU in Launchpad rather than complaining
<iulian> Indeed. :)
<iulian> No worries, we'll be done in no time.
<Laney> until the next time
<iulian> Only if the buildds can keep up with me.
<Laney> fish and chips for dinner will perk me up
 * Laney bikes off into the sunset
<Laney> (bbl)
<iulian> Later!
<infinity> Laney: I'm sure I can help with a GHC transition (and I'm not sure how binNMUs make it particularly simpler, except when someone screws up timing)
<Laney> infinity: not having to rev the source revision, build, sign, upload manually
<Laney> infinity: smarter depwait would probably help more, granted
<infinity> Laney: Yeah, I've never found the uploading bit onerous.  Maybe I'm weird.
<Laney> having looked at the Debian graph, I think that would be a good place for me to focus my efforts if somebody else will do the merge and initial sync pass(es)
<infinity> Laney: If you have a list of what needs merging/uploading, I can certainly help.  I've not really been paying attention to GHC since the last transition.
<Laney> infinity: merge ghc, haskell-devscripts and then sync everything else in the standard order
<Laney> it should really all be syncs in this case because we needed arch:all rebuilds this time
<infinity> Do we actually need a ton of syncs, or will rebuilds do?
<infinity> Anyhow, the "merge GHC" bit might be touchy (unless it's a simple merge?), but happy to do the rest.
<Laney> some will have required patches, but in general either is fine
<infinity> If it's not a rocket surgery merge, I'll poke at that this afternoon.
<Laney> the GHC diff should not be too hard, some linker stuff from doko
<infinity> Oh, the linker stuff is right up my alley. :P
<Laney> quite :-)
<infinity> It's mostly a "do I have to speak fluent haskell?" thing.  Cause Haskell gives me aneurysms.
<Laney> oh, no, it's m4 I think
<infinity> Sold!
 * micahg can help with rebuilds also
<Laney> you saints!
<iulian> Uh oh!
<cyphermox> can someone please confirm that the fix for bug 176125 is alright to upload now that we're in FF -- I already included the necessary patch but had forgotten to reset the default value for enabling privacy extensions to TRUE
<ubot2`> Launchpad bug 176125 in network-manager "Ubuntu should activate the IPv6 privacy extension by default (echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr)" [Wishlist,Confirmed] https://launchpad.net/bugs/176125
<stgraber> it's a regression from what we had a few weeks ago isn't it?
<ScottK> cyphermox: Please fix it.
<cyphermox> stgraber: yes
<ScottK> Either way, I think lack of privacy extensions is a bug.
<slangasek> cyphermox: I agree, bug -> squash it
<cyphermox> it is indeed a regression, with just procps this was already set to use privacy extensions since at least january, perhaps earlier
<cyphermox> cool, just being thorough
<cyphermox> so this I'll upload in a minute with a few other fixes
#ubuntu-release 2012-02-22
<Riddell> cjwatson: how's this? https://code.launchpad.net/~jr/livecd-rootfs/kubuntu-active/+merge/94135
<Riddell> cjwatson: also https://code.launchpad.net/~jr/ubuntu-cdimage/kubuntu-active/+merge/94138
<cjwatson> Riddell: can you get somebody who isn't on leave to review it? :)
<Riddell> oh, sorry
<cjwatson> if you're changing tasks you might need to do a tasksel update too, there's lillypilly:~ubuntu-archive/bin/update-{seeds,*germinate}, maybe a few other places
<cjwatson> new seed collections that generate tasks require landing a Launchpad change
<cjwatson> ./cronscripts/publishing/cron.germinate:18:FLAVOURS="ubuntu kubuntu kubuntu-mobile edubuntu xubuntu mythbuntu lubuntu"
 * cjwatson disappears again, need to head off to hospital soon
<Riddell> gotcha, thanks
<Riddell> ScottK: do my merges above look like what you remember doing in the past?
<ScottK> Riddell: They look right to me.
<Riddell> good enough I suppose :)
<Riddell> pitti: is antimony still the machine to log into for cd builds?
<pitti> Riddell: no, that's "nusakan" now
<pitti> Host cdimage
<pitti>     HostName nusakan.canonical.com
 * pitti uses ^ in his .ssh/config
<pitti> I can never remember our funny host names
<pitti> I have "archive", "people", "cdimage", etc.
<infinity> pitti: You're missing out on the joy of typing lillypilly, then!
<infinity> (Terrible one-handed mess, if you're a "true" touch-typist)
<pitti> my keyboard forces me to be :)
<pitti> infinity: but indeed, that's even worse than "database", which as a psql maintainer I tend to type quite often :)
<pitti> another reason to put Mr. Qwerty and Mr. Caps Lock into a sack and hit them really hard
<infinity> Heh.
<pitti> but I never got fluent enough with Dvorak to actually use it
<Riddell> thanks pitti
<infinity> Yeah, I've been typing qwerty for so long that I don't much care if there are better options.
<stgraber> pitti: not using qwertz? :) (not that it'd make much difference in that case though)
<Riddell> pitti, infinity: who remembers the right way to update cdimage scripts on nusakan ?
<pitti> Riddell: I'm afraid I never did that
<Riddell> there's a bzr branch in /srv/cdimage.ubuntu.com/ another in /srv/cdimage.ubuntu.com/bzr/private/cdimage and the public one at lp:cdimage-ubuntu
<infinity> Riddell: Commit to private, pull from cdimage.
<pitti> stgraber: no; German layout is a nuisance
<Riddell> infinity: so commit to /srv/cdimage.ubuntu.com/bzr/private/cdimage and pull from there to /srv/cdimage.ubuntu.com/ ?
<pitti> stgraber: in fact, when using C, vim, or LaTeX, anything but "us" is a nuisance
<infinity> Riddell: I check out a copy of /srv/cdimage.ubuntu.com/bzr/private/cdimage in my ~, hack on it, commit, and then as cdimage, cd to /srv/cdimage.ubuntu.com/ and bzr pull.
<Riddell> infinity: ok and how does lp:ubuntu-cdimage get updated?
<infinity> Riddell: Don't worry overly about the public branch, Colin merges bi-directionally occasionally.
<stgraber> pitti: yeah, I also found qwerty to work a lot better when coding than qwertz, having to use altgr half the time was a bit annoying. Though having $ directly mapped to a key was kind of nice ;)
<Riddell> infinity: ok, wish me luck
<infinity> Riddell: There's a hope that, at some point, the pirvate branch might go away, and the public one will become authoritative, but we still need to put some work into making that a sane reality.
<infinity> Riddell: If you need anything reviewed before you do the commit/pull dance, let me know.
<Riddell> infinity: https://code.launchpad.net/~jr/ubuntu-cdimage/kubuntu-active/+merge/94138
<infinity> Riddell: What's the "active" stand for? :P
<Riddell> infinity: upstream KDE's brand for "tablet and touch UI stuff"
<infinity> Ahh.
<infinity> Riddell: Looks good, assuming you got every instance of 'mobile' in the source.
<Riddell> grep says I did :)
<infinity> ;)
<Riddell> infinity: how does nusakan:/srv/cdimage.ubuntu.com look to you?
<Riddell> infinity: for livecd-rootfs I just update the branch and upload as a package to ubuntu?
<infinity> Riddell: Yep.
<infinity> Riddell: None of these images were ever supported, right?
<infinity> Riddell: (ie: we'll never need to respin them for a previous release?)
<Riddell> no, kubuntu-mobile never was and is dead
<Riddell> kubuntu-netbook likewise
<Riddell> and kubuntu-kde4 has been dead of even longer
 * skaet notes we need to make sure to change this in the iso tracker.
<infinity> No need to have ARCHES="i386" in crontab if etc/default-arches is correct.
<Riddell> infinity: ok, fixing
<infinity> Riddell: You could probably also ditch the "mobile" and "preinstalled-mobile" cruft from make0web-indices, since you've killed those types.
<infinity> But meh, that list needs more cruft-checking anyway.
<infinity> We really need to kill moblin and netbook and mid... And...
<infinity> So, perhaps another day. :P
<Riddell> yeah I think it's cruft left over from an ubuntu-mobile not a kubuntu-mobile :)
<infinity> Potentially.
<infinity> I'll go through that all with a fine-toothed comb another time.
<infinity> Now that ARM images have settled on sane names.
<infinity> Riddell: Oh, you'll also want to hand-apply your etc/crontab changes to the actual crontab.
<infinity> Riddell: (perhaps commented out, for now, while you're working on livecd-rootfs changes, etc)
<Riddell> infinity: livecd-rootfs is uploaded this morning to ubuntu, will the server magically pick those up?
<infinity> Riddell: The live builders apt-get upgrade chroots before every build.
<Riddell> infinity: err could you edit the crontab or tell me how to convince crontab -e  to use emacs and not vi? :)
<infinity> Riddell: VISUAL=emacs crontab -e
<infinity> (assuming emacs is installed, you might try nano)
<infinity> Oh, hey, emacs is installed.
<infinity> Wow.
<Riddell> yeah because I asked for it once upon a time :)
<infinity> Heh.
<Riddell> ok updated.  never heard of using VISUAL I was assuming it was EDITOR like every other command
<Riddell> infinity: anything else you can think of that needs changed for new images to appear?
<infinity> Off the top of my head, no, but something will probably explode. ;)
<infinity> (There are launchpad changes needed too, if you were introducting a new task)
<Riddell> infinity: hmm so I should go to wgrant or bigjooles about that I guess
<infinity> You could have just reused the mobile tasks. ;)
<infinity> But yeah, if you're renaming a task, that needs manual mangling in LP.
<infinity> 05:49 < cjwatson> if you're changing tasks you might need to do a tasksel update too, there's lillypilly:~ubuntu-archive/bin/update-{seeds,*germinate}, maybe a few other places
<infinity> 05:49 < cjwatson> new seed collections that generate tasks require landing a Launchpad change
<infinity> 05:49 < cjwatson> ./cronscripts/publishing/cron.germinate:18:FLAVOURS="ubuntu kubuntu kubuntu-mobile edubuntu xubuntu mythbuntu lubuntu"
<Riddell> oh yes
<infinity> Riddell: Sorting out the relevant cron.germinate change should be trivial, you just need someone in the committers group to review and land it for you.
<infinity> Riddell: And then get it cherrypicked or queued up for the next LP NDT.
<infinity> Riddell: I recommend canonical/#launchpad-ops to try to get that sorted.
<Riddell> thanks
<skaet> hmm...   https://wiki.ubuntu.com/StandingFeatureFreeze is looking rather stale in terms of usage.
<Laney> indeed
<highvoltage> isn't that a good thing? :)
<stgraber> looks like it'd need some updating
<stgraber> "have been approved for Hardy:"
<stgraber> then listing a Jaunty FFe ;)
<Laney> kill it
<Laney> have we used standing FFes recently?
<stgraber> seems like a lot of that became useless with bugfix only new releases being allowed, instead people tend to develop in PPA and ask for a single FFe when actually landing a feature which seems better
<ScottK> Agreed.
<skaet> ok,  will go clean up the page that points to it,  and update this page to indicate stale.
<Laney> can you delete it?
<Laney> i assume the wiki lets you resurrect deleted pages
<skaet> Laney,  I'll just update it to reflect there are no standing Freeze Exceptions,  and process has changed.   Will look into deleting later
<skaet> (after I know I check what the history story is)
<skaet> done
<stgraber> skaet: can you do some priority bumping of https://bugs.launchpad.net/ubuntu/+source/nux/+bug/926859?
<ubot2`> Launchpad bug 926859 in nux "llvmpipe software rendering needs blacklisting in unity-support-test" [High,Triaged]
<stgraber> skaet: this is making working with live images a major pain for me as I can't switch to unity-2d and am stuck with the VM using 50% of my CPU to do 3D stuff in software
<stgraber> not to mention 80% of the time I don't even see ubiquity because of it ...
<skaet> stgraber,  will ask at any rate...
<stgraber> I'm surprised we haven't heard more about it as it's making ISO testing in kvm pretty much impossible
<stgraber> Virtualbox/Vmware might work as they actually have 3D drivers
<broder> i couldn't get the vmware 3d driver to work, fwiw - i ended up with llvmpipe
<stgraber> llvmpipe is very nice to have, but I don't think we're going to have a working compiz on llvmpipe for 12.04 and even if we did, I don't think we want that to be the default
<wgrant> infinity, Riddell: cocoplum deployments aren't in NDT, since they still require downtime, but it's pretty trivial, yeah.
 * ScottK wonders if the uTouch team has any idea of feature freeze?
<ScottK> (beyond, oh, I have to do more paperwork now)
<GrueMaster> Feature Freeze?  What's that?  :P
<ScottK> Yeah.  Not funny.
<ScottK> I think I'll just approve everything.  That way it's fair.
<stgraber> reverting the upload until they have the paperwork done would be fair though it takes quite a bit of effort to do, it's not like we have a "revert" button on LP
<ScottK> I've done reverts before, but not in awhile.
<slangasek> stgraber: the iso tracker seems to link to the rootfs tarballs for the wubi test cases; that doesn't make a lot of sense to me, since users will need to download the .exe and the .exe downloads the tarball? http://iso.qa.ubuntu.com/qatracker/milestones/206/builds/11165/downloads
<stgraber> indeed, I guess it still makes sense to use the rootfs version for the builds though, just point to wherever the matching wubi is (people.ubuntu.com?)
<slangasek> yeah, I think so
<slangasek> should be http://people.canonical.com/~evand/wubi/precise/stable ?
<stgraber> slangasek: fixed
<slangasek> cheers :)
<stgraber> slangasek: I pointed to the directory instead of a specific file, having "stable" as filename looks weird. we probably should have a wubi-latest.exe as symlink to whatever is latest (probably identical to stable)
<slangasek> fair enough
#ubuntu-release 2012-02-23
<nessita> hello everyone! I'm about to do an update to a package in universe, and wanted to confirm something regarding feature freeze vs UI freeze. I want to upload some changes that do a refactoring to part of the UI... the info displayed is the same as before (no new feature there), but is re-organized and simplified for the user benefit. This does not require a FFe, right?
<slangasek> nessita: this is borderline; the purpose of the UI freeze is to lock things down so that there are *no* further changes to the UI that would invalidate screenshots, it doesn't mean that changes to the UI in general aren't considered features.  Could you please file a FFe bug with the details, so we know what's being changed?
<nessita> slangasek: I already have a bug for this, shall I follow the FFe procedure with it?
<nessita> FYI, bug is bug #818217
<ubot2`> Launchpad bug 818217 in magicicada "Redesign the top part of the main window" [High,In progress] https://launchpad.net/bugs/818217
<slangasek> (it's likely to be approved as an exception even if it would be considered feature work; but "refactor" is a trigger word for me that tells me we should probably know what's going on :)
<nessita> slangasek: even for apps in universe?
<slangasek> yes
<slangasek> the feature freeze isn't exclusive to main
<nessita> yes, I understand that... but perhaps the limits were a little greyer for universe apps :-)
<slangasek> so that looks pretty straightforward to me
<slangasek> and I'm happy to give you an informal approval
<slangasek> no more paperwork required
<nessita> slangasek: yey, thanks!
 * nessita is glad she asked
<micahg> nessita: it can be easier to get an exception for a leaf application in universe than other things, but that's about it WRT the difference
<nessita> micahg: duly noted
<nessita> so, when in doubt... is there any doc that will make clearer what's the "definition" of feature when talking about FF?
<slangasek> https://wiki.ubuntu.com/FeatureFreeze is the closest there is, but it's implicit
<slangasek> as I said, the above is borderline
<nessita> ack, thanks
<skaet> Riddell,  I've reset http://pad.ubuntu.com/ubuntu-release for Beta 1.
<skaet> Could you please add the runes for building kubuntu-active for i386 into the commandlines at the bottom of the page.
<skaet> ?
<skaet> infinity,  could you review to make sure I've got the armhf images are correct?
<pitti> skaet: FYI, the langpack export landed earlier, as it had to be kicked off manually; all langpacks which are on CDs are uploaded now
<pitti> I'll upload the others, too
<pitti> buildds are nicely quiet right now
<Riddell> skaet: kubuntu active added to http://pad.ubuntu.com/ubuntu-release I think
<Riddell> infinity (or cjwatson if not on holiday): could you check lillypilly:ubuntu-archive/bin and merge it into /home/ubuntu-archive/bin ?
<Riddell> I don't have access to ~ubuntu-archive as far as I know
<pitti> Riddell: you should, I just checked getent
<pitti> sudo -u ubuntu-archive -i
<Riddell> pitti: ooh I feel the power :)
<Riddell> ooh beta next week
<Riddell> but no skeat
<Riddell> slangasek: you're the last milestone release guy, what can you tell me about what needs done
<Riddell> I don't know the split between me and skeat on this stuff https://wiki.ubuntu.com/BetaProcess
<pitti> Riddell: usually you would do the engineering tasks such as archive admin, CD rebuilds, publishing images and such
<pitti> Riddell: and skaet would do release notes, web/mail announcement etc.
<Riddell> pitti: but as a random example "Contact Ara Pulido to check if any critical certification bugs remain to be resolved "  who does that?
<pitti> Riddell: this usually falls in skaet's area
<pitti> but it's a bit fuzzy of course
 * ara waves :)
<Riddell> ara: don't mind me, I'm just using you as an example :)
<pitti> I used to garden the milestoned bugs
<pitti> postponing non-critial stuff, chasing people for getting them fixed, etc.
<Riddell> pitti: this also says it needs to be frozen 7 days before, is that still the case for betas?
<pitti> Riddell: yes; that's why the freeze is tomorrow evening
<pitti> err, today
<pitti> usually at 2100 UTC
<Riddell> pitti: has that been announced?
<pitti> not that I can see
<pitti> I guess skaet is on holiday or so?
<pitti> usually she does
<pitti> so I guess it falls to you now :)
<Riddell> or just a US timezone?
<pitti> she's not even on IRC, usually she's connected 24/
<pitti> 7
<Riddell> nothing about her on the holiday calendar
<pitti> hm
<pitti> US power outage?
<Riddell> yes, her connection dropped late at night, could well be just a disconnect
<Riddell> anyway, I can do the announce
<Riddell> pitti: how's this? http://paste.kde.org/427646/
<pitti> Riddell: looks fine, thanks!
<Riddell> pitti: there's nobody to approve it on the list
<Riddell> who's got super powers on the mailman lists?
<pitti> Riddell: I just moderated it
<Riddell> ok, thanks
<Riddell> it must not have listed the moderators only admins of the list
<Riddell> https://launchpad.net/ubuntu/+milestone/ubuntu-12.04-beta-1  only 112, they'll get fixed in the next 8 hours no problem
<pitti> actually, we only consider release-targetted ones
<pitti> https://launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=44327
<pitti> still looks challenging, of course
<Riddell> ara: any critical certification bugs remain to be resolved ?
<Riddell> pitti: "Notify DavidPlanella to coordinate a fresh set of language packs which will be exported, uploaded, and built in time for beta. "  is that already done?
<pitti> done
<pitti> Riddell: ^
<pitti> the last ones are built now
<pitti> I am currently rebuilding the ubuntu desktop/alternate images to see how much of a size difference it makes
<Riddell> pitti: you said mvo is on holiday but he's not on the calendar, do you know how long he's away?
<pitti> Riddell: I don't know, I just guessed based on him not being on IRC
<Riddell> pitti: I could phone him to find out, do you know what happens to his tasks if he's not around?
<pitti> I don't know :/
<Riddell> let me phone and ask
<pitti> Riddell: btw, mup can send SMS, you could start with that
<Riddell> 13:52 <mup> SMS is on the way!
<Riddell> let's see if that helps
<ara> Riddell, no critical ones, no
<pitti> Riddell: FYI, I think there's a deeper problem with germinate somewhere; it hasn't updated on cocoplum for three days now
<pitti> Riddell: so any seed change since then hasn't been picked up
<pitti> it's not clear to me how to debug this yet
<pitti> Riddell: just in case you wonder about thsi
<pitti> or component-mismatching not updating (same cause)
<Riddell> mm, thanks
<ara> Lovely release team, could any of you review this FFe, please?
<ara> https://bugs.launchpad.net/checkbox/+bug/937657
<ubot2`> Launchpad bug 937657 in checkbox "[FFe] Non graphical UIs don't display test results" [Medium,Fix committed]
<ara> we are trying to have it in an upload later today before BetaFreeze (and UIFreeze)
<bdrung> hi, do i need a FFe for syncing audacious?
<bdrung> (3.2-1 to 3.2.1-1)
<Riddell> skaet: I started on the beta tasks
<skaet> Riddell,  Thanks!  :)
<ogra_> skaet, !!!
<pitti> hey skaet, how are you?
<skaet> hiya pitti, ogra_   fine,  looks like my machine crashed overnight,  so just ramping back into connectivity mode now.
<ogra_> skaet, i have something to discuss with you ... but later today, first i have the final ubuntu-arm meeting before we shut down the team :)
<skaet> ogra_  sure,  just ping when you're ready.
 * skaet has a couple of calls this morning, but will be around.
<Riddell> ok mvo has just gone to bed so I've no idea what his status is but he'll get back to me when he's awake
<Laney> bdrung: you know the deal â depends on whether there are new features
<bdrung> Laney: should be mostly bug fixes
<Laney> check the upstream changelog / news file
<bdrung> Laney: both files are missing, but: http://www.audacious-media-player.org/news/9-audacious-3-2-1-released
<Laney> looks fine
<Riddell> mvo is alive but sick, he will check the e-mails I sent him and let us know if he needs help
<Riddell> mvo will need help from the foundations team for upgrade tests, how can I contact them?
<Riddell> do they have a manager yet?
<stgraber> Riddell: slangasek is our manager
<Riddell> slangasek: nudge, get your minions to help poor mvo with https://wiki.ubuntu.com/UpgradeTestingProcess
<stgraber> Riddell: in the case of upgrade testing, QA are running daily automated testing for Ubuntu (jibel is in charge of that I believe) and I'm running daily upgrades of the flavours (edubuntu, kubuntu, mythbuntu and xubuntu at the moment)
<stgraber> though for the flavours I only have 11.10 => 12.04, I'm not running LTS-to-LTS yet but I believe jibel does for Ubuntu itself
<Riddell> stgraber: using the KDE frontend to release upgrade tool?
<stgraber> Riddell: it's using the automated upgrade tester, so no, it's roughly the equivalent of running "do-release-upgrade" from a terminal
<pitti> skaet: btw, houston, we have a problem
<Riddell> right, thanks stgraber
<pitti> skaet: http://cdimage.ubuntu.com/daily-live/20120223.1/ is with fresh langpacks
<pitti> skaet: as I feared, squashfs is actually clever enough, i. e. the langpack refresh only helped the alternates, not the desktops (much)
<jibel> Riddell, daily results are posted there https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
<stgraber> pitti: so we saved ~ 2MB (comparing to 20120220)? or was that some other savings
<pitti> stgraber: mostly due to dropping some obsolete translations
<pitti> chrisccoulson figured out how to put tbird/ffox on a diet, should buy some 5 MB
<pitti> and we could potentially drop python3 again by switching back lsb-release
<pitti> (4.5 MB)
 * pitti is a bit stunned on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> libwayland0/armhf is published, no idea what's wrong here
<skaet> pitti, otp, breaking now.
<pitti> skaet: (not urgent)
 * skaet off the call.   backscrolling...
<Riddell> pitti: kde bits not looking too good there, I wonder who I can blame for that
 * skaet is a bit stunned by the armhf increased probs now showing up too...
<pitti> Riddell: it seems to root in mesa not being installable due to libwayland0 missing on armhf
<pitti> but I don't understand it
<pitti> yesterday it was "just" the 111 packages due to the missing libo armhf build
<Riddell> pitti: that also seems to affect i386 looking at the mesa report on precise_probs.html
<pitti> have a call now, looking later
<superm1> can someone help me to understand why mythbuntu ISOs are still pulling in default-jre-headless (and a java stack)?  it's not referenced in the desktop or live germinate output.
<Riddell> superm1: tried an apt-get remove as a quick way to check?
<superm1> Riddell: i'm just fetching today's ISO to try that now
<Riddell> default-jre-headless                                        | java-common                        | yui-compressor
<superm1> which we don't have yui-compressor in the image
<superm1> http://cdimages.ubuntu.com/mythbuntu/daily-live/20120223/precise-desktop-i386.manifest
<superm1> it does look like default-jre-headless has a task of a bunch of the mythbuntu stuff set though: http://paste.ubuntu.com/854140/
<superm1> i'm not sure how that happened
<Riddell> a bit of a mystery right enough
<skaet> ev,  has the disclaimer been removed from Ubiquity's first page (Beta process starting)
<ev> skaet: yes, just sorting an upload now
<skaet> thanks ev
<Riddell> skaet: I already poked him :)
<skaet> thanks Riddell :)
 * skaet needs to go check those logs after all
<superm1> Riddell: so could this possible be some sort of bug in the archive apt list generation then?  because from what i gather that task stuff in apt-cache show comes directly from /var/lib/apt/lists/$(mirror)_ubuntu_dists_precise_main_binary-i386_Packages
<infinity> ev: So, looks like I'll have to back out the wubi-ext4 changes for now, unless we can get IS to upgrade the x86 livefs buildds to something newer than hardy ASAP.
<Riddell> skaet: I think I've done most or all of the 10 days before tasks
<Riddell> and 7 days before can be later tonight for me or you can do them in 5 hours
<Riddell> actually probably will be tomorrow morning for me
<ev> infinity: eep, okay
<infinity> ev: Yeah, eep indeed.
<infinity> ev: I'll try to get it escalated so we can switch back after beta, but I think we're SOL for having ext4 this week.
<skaet> Riddell, thanks.   let me know what's still left when you go off line,  and I'll handle it in 5 hours
<ev> okay
<jamespage> Daviey or infinity: please could you review the FFe for bug 889644 - I think its ready to roll now
<ubot2`> Launchpad bug 889644 in openmpi "[FFe] Please provide OpenMPI 1.5 packages" [Wishlist,Confirmed] https://launchpad.net/bugs/889644
<Daviey> jamespage: can you clarify, we are *not* jumping to 1.5 and rebuilding rdepends?
<Daviey> this is a versioned package, right?  So it's just a NEW?
<jamespage> Daviey: its just a NEW - no transition
<jamespage> to risky
<infinity> Though, this essentially means that installing openmpi1.5 removes all openmpi rdeps?
<infinity> That doesn't sound all that pleasant either.
<infinity> Unless those rdeps are largely "useles" to most people, it's not much of an evaluation.
<bdrung> do i need to file a FFe for the debian-policy? it's just a documentation package
<infinity> bdrung: No.
<infinity> bdrung: Up-to-date policy gets a free pass from me. :P
<bdrung> infinity: and lintian?
<infinity> bdrung: lintain needs to be lockstep with policy in a sane world.
<infinity> bdrung: (So yeah)
 * bdrung synced debian-policy.
<infinity> jamespage: Was rdeps testing a miserable failure, or was it just deemed too much work to validate?
<jamespage> infinity, not a miserable failure (most things rebuild OK) - I discussed with the Debian maintainer and we where both uncomfortable about the beta/feature status that upstream assign the 1.5.x branch being the default
<infinity> Mmkay, fair enough.
<infinity> Then yeah, dump it in NEW, and we'll find time to give it a once-over.
<stgraber> I'm planning a LTSP upload of 5.3.1, upstream is technically in feature freeze, so 5.3.1 is supposed to be bugfix only, changelog is here: http://paste.ubuntu.com/854191/
<stgraber> can someone from the release team confirm it looks like bugfix only?
<jamespage> infinity, ack - wilco
<infinity> stgraber: Assuming your changelog is accurate, it looks fine. :P
<stgraber> infinity: the changelog was made from copy/paste of the upstream bzr log, excluding everything starting by "Debian:", so it should be
<stgraber> infinity: apparently there are a few extra bugfixes in trunk that we need, so I'll be tagging 5.3.2 once it's tested and push that before beta freeze (also need to fix the udeb in there as there's a milestoned bug for it ...)
<stgraber> thanks for the review
<infinity> stgraber: That's a pretty broad interpretation of the word "review". :P
<Daviey> bdrung: How about you merge ubuntu-policy :)
<Daviey> bdrung: that would close, bug 817264.
<ubot2`> Launchpad bug 817264 in ubuntu-policy "Policy should be reviewed and/or merged with latest debian-policy" [Medium,Triaged] https://launchpad.net/bugs/817264
<bdrung> Daviey: -ENOTIME
<bdrung> Daviey: feel free to do the merge yourself. :)
 * bdrung has to write a Bachelor thesis.
<slangasek> Riddell: https://wiki.ubuntu.com/UpgradeTestingProcess - that should all be automated now through the QA team?
<slangasek> Riddell: I believe last milestone skaet said this would be taken off the checklist
<Daviey> bdrung: gah, priorities all wrong!
<bdrung> Daviey: sadly and i get too easily distracted
<skaet> jibel,  can you confirm the UpgradeTestingProcess steps are now all automated?
 * skaet will remove from all the checklists if thats the case... (Milestone, Beta, etc....)
<jibel> skaet, yes, excepted cdrom upgrades that I run manually
<skaet> jibel,  thanks.    When do you do the cdrom upgrades manually?   can we check them first thing tomorrow with the new images?
 * skaet going to do some checklist editing now...
<infinity> Daviey: I really wish Ubuntu Policy had just been implemented as an appendix to Debian Policy, would have made "merging" somewhat trivial. :/
<Daviey> infinity: right!
<infinity> Daviey: Perhaps not too late to rearrange it to be so. :P
<infinity> Daviey: I always thought that having inline diffs to debian-policy was silly anyway, cause it means diffing the two to know how Ubuntu is, well, different.
<infinity> An appendix would just spell out "Ubuntu Policy *is* Debian Policy, with these exceptions/additions".
<Daviey> infinity: well, whilst Colin is away.. why not change everything? :)
<Daviey> (not serious.)
<infinity> Daviey: *twirl moustache*
<infinity> Daviey: It's been a long time since it was discussed, but I think the current inline implementation was mdz's idea.  I may actually put a tiny bit of effort into convincing people that it's not actually sane.
<infinity> Daviey: (As it stands, I suspect almost no one actually reads "ubuntu policy", but just skips right over to debian policy, which is always up-to-date, and that sort of defeats the whole point)
<Daviey> infinity: I think it was mdz.
<Daviey> infinity: well, i find going to people.ubuntu.com/~$developer/ for looking at ubuntu offical policy a very elegant and official thing :)
<infinity> *smirk*
<infinity> www.debian.org/devel is muscle memory.
<jibel> skaet, usually on Friday the week before a milestone I do cdrom upgrades and manual installation smoke tests.
<skaet> jibel,  perfect.   I'll put something on the checklist to check with QA on the status then with you on that day.
<stgraber> skaet: I bumped the priority of bug 813837 to high, wasn't sure if it should be critical as I only did a couple of test installs
<ubot2`> Launchpad bug 813837 in ltsp "ltsp client not able to load boot file: ltsp/amd64.tmp/pxelinux.0" [High,Triaged] https://launchpad.net/bugs/813837
<stgraber> skaet: I'm working on the fix now (reworking the d-i module to stop assuming an install time and instead just wait until the install is done)
<ampelbein_> Hi! Could some member of the release team have a look at bug #939689 and say if it contains every information you need?
<ubot2`> Launchpad bug 939689 in gnomescan "FFe: Remove gnomescan binary and source package and import gnome-scan package from Debian" [Wishlist,New] https://launchpad.net/bugs/939689
<infinity> ampelbein_: The obvious "regression" is that people won't get upgraded from the old to the new.
<infinity> ampelbein_: If this package has users, they'll never know that it's changed names.
<ampelbein_> Oh. Right.
<infinity> ampelbein_: And I haven't looked, but I assume the Debian one doesn't replace gnomescan?
<infinity> Nor conflict?
<infinity> So, trying to install B if A was installed will explode.
<ampelbein_> Yeah, right, didn't think of this. debian doesn't know about the gnomescan package at all.
<infinity> ampelbein_: My recommendation would be to take the Debian sources, add some versioned conflict/replace magic to gnome-scan, and build a gnomescan transitional package from that source.
<infinity> ampelbein_: After precise releases, you can dump that Ubuntu diff, and just sync with Debian.
<infinity> ampelbein_: Sound reasonable?
<infinity> ampelbein_: So, basically, "Package: gnome-scan\nConflicts: gnomescan (<= last-version-in-Ubuntu)\nReplaces: gnomescan (<= last-version-in-Ubuntu)" and "Package: gnomescan\nDepends: gnome-scan (= Source-Version)\nDescription: Transitional package to upgrade from gnomescan to gnome-scan"
<ampelbein_> infinity: Yes, though there is actually more to it, looking another time with more open eyes. There isn't a single "gnomescan" package, it's more than 1 binary. So needs a little more magic.
<infinity> Oh, I see.  Libraries too.
<infinity> Did those not get named the same in Debian?
<infinity> They did, thankfully.
<infinity> But flegita-gimp is now gimp-flegita.
<infinity> For the most part, it should be fairly easily sortable with a couple of transitional packages, but yeah, it'll need a bit of testing and review.
<ampelbein_> Yeah, I'm gonna go and apply the patches from debian to the ubuntu package for precise.
<infinity> ampelbein_: If you're willing to put the one-time effort in (like I said, you can drop it post-precise), I'll happily review it for an FFe, since I think it's crazy to stay forked.
<ampelbein_> Should target that for Querulant Quillboar.
<infinity> Ideally not. :/
<infinity> Cause transitions that happen POST-precise need to stick around for two years until the next LTS.
<infinity> (So LTS->LTS upgrades work).
<infinity> Whereas, if you land it now, you can drop it in 3 months. :P
<ampelbein_> Argh.
<ampelbein_> Ok, I'll get it done over the weekend.
<infinity> Well, there's a third option.
<infinity> Which is "not caring".
<infinity> Cause I'm not sure where you're looking, but the Debian package isn't really maintained.
<infinity> (Yes, it had an NMU upload recently to fix an FTBFS, but the last maintainer upload before that was years ago)
<infinity> Still, being gratuitously forked on package names is unpleasant.  So, meh.  Your call. :)
<infinity> But if you want to transition, do it now, not later.
<ampelbein_> infinity: To be honest, I accidently looked at the bugs package of the library, not the source package and didn't even see the 2 RC bugs open now.
<ampelbein_> (In the debian BTS)
<infinity> http://packages.qa.debian.org/g/gnome-scan.html shows all the "not really maintained" picture I need.
<ampelbein_> Yeah, see that now too. I was careless.
<ampelbein_> And  now Scott acked and synced the new package.... Damn my too fast requesting of a FFe.
<infinity> Fun.
<infinity> Well, if it really had no rdeps, there's always the possibility that no one really cares. :P
<infinity> ScottK: You completely missed the gnome-scan conversation going on here while you approved and synced. ;)
<ScottK> infinity: I did.
<ScottK> I just read the bug.
<infinity> Heh.
<pitti> simple-scan FTW?
<infinity> Oh well.
<infinity> Like I said, I suspect it might not actually have many (any?) users anyway, so maybe it's a moot point.
<ampelbein_> I'm honestly sorry for that mess. I really should have given more research into this.
<infinity> Still, a proper set of transitional dependency fields would be nice.
<infinity> ampelbein_: Still time to fix it in a -1.1ubuntu1 upload, and sync if and when Debian ever actually uploads again.
<ScottK> Yes.  I think taht would be best.
<ampelbein_> Ok, will work on that ASAP.
<infinity> ampelbein_: Thanks.  ScottK will send you a cookie to apologize for forcing your hand. ;)
<ScottK> The moral here is don't subscribe the release team unless you really mean it.
<infinity> He meant it, until another member of the release team pointed out that he didn't. ;)
<infinity> But yeah, I should have commented on the bug as soon as I spotted the problem.
<infinity> Oh well.
<infinity> Life's like that.
<ScottK> Yep.
<micahg> can the flavors just upload new meta packages now, I wasn't planning on working on the lightdm-gtk-greeter until this evening
<skaet> stgraber,  thanks for the head's up on 813837.  ok.
<ampelbein_> infinity, ScottK: I prepared a new gnome-scan upload, http://paste.ubuntu.com/854404/ is the debdiff, tested the upgrade in a chroot. There isn't a gnomescan package anymore, it was only a virtual package that depended on flegita (the standalone interface) and debian never had that.
<infinity> ampelbein_: By virtual package, you mean metapackage?
<ampelbein_> infinity: erm, yes.
<ampelbein_> it had no "own" content, just depended on flegita, flegita-gimp.
<infinity> ampelbein_: You might also need a flegita-gimp that depends on gimp-flegita?
<infinity> ampelbein_: Otherwise, I don't see how the upgrade would ever happen.
<ampelbein_> No, as gnome-scan-common depends already on flegita-gimp.
<infinity> ampelbein_: (Replaces doesn't mean "upgrade to this package", it means "files from this package overwrite the other")
<infinity> Err, -common depends on the gimp plugin?  That's... Odd.
<ampelbein_> infinity: Let me check again the upgrade.
<infinity> ampelbein_: Do it with apt, if you're not already.
<infinity> ie: install all the old packages, "apt-ftparchive packages . > Packages" in a directory with the new debs, and point sources.list to a "deb file:/foo/bar/ ./" URI.
<ampelbein_> Ok, I used dpkg -i *.deb.
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<pitti> now, that looks MUCH better
<pitti> armhf dropped from 801 to 9
<skaet> pitti, :D
<skaet> or rather... *\o/*
 * pitti gives back compiz builds, sohuld work now
<micahg> pitti: would you mind if i just reuploaded the ubuntustudio and xubuntu metas, I can't work on the greeter until this evening
<ogra_> yeah, its all didiers fault !
<pitti> no, it was wayland's fault :)
<ogra_> heh
<pitti> micahg: uh, what for? the greeter should still be in the archive, even if it is NBS?
<micahg> pitti: yes, but the meta packages have been removed :)
<ogra_> and NCommander shoudl fix linux-meta-armadaxp
<micahg> so, no xubuntu-desktop or ubuntustudio-desktop
 * NCommander groans
<ogra_> :)
<pitti> micahg: err?
<ogra_> NCommander, well, not milestone critical
<pitti> micahg: yes, please do reupload; that sounds all wrong
<micahg> pitti: riddell went removal happy :(
<pitti> micahg: now I know why there are suddenly no rdepends any more
<pitti> micahg: please do; we must avoid that any archive admin spots that on teh NBS page and runs the removal
<NCommander> pitti: deleting packages will do that :-)
<micahg> oh, he just removed the binaries but not the source, that's a little beta
<micahg> *better
<pitti> micahg: also, there's nothing wrong with -meta; there is no real reason to remove its binaries
<pitti> micahg: i. e. reuploading now is fine either way
<micahg> exactly :)
<ampelbein_> infinity: ok, got it now. http://paste.ubuntu.com/854465/ (debdiff), http://paste.ubuntu.com/854461/ (upgrade-log)
<gilir> is someone know why lubuntu-default-settings and lubuntu-desktop have just disappeared from precise repositories ?
<gilir> they just ... disappeared, and I can't see any notice about this
<skaet> *blink* ???
<skaet> infinity, ^ can you look into it?
 * skaet wants logging....
<skaet> or slangasek, ^?
<micahg> gilir: riddell removed them earlier this morning since they depended on NBS which was wrong
<micahg> gilir: you can reupload them
<micahg> but you'll have to get the default-settings package through NEW before the meta is uploaded or it won't pick it up
<skaet> thanks micahg
<gilir> micahg, ok thanks, I need to update them :)
<micahg> can someone please binNEW xubuntu-default-settings
<micahg> skaet: I'm going to need to upload a few ubuntustudio packages after the beta freeze to clean up the NBS removal mess from this morning
<micahg> skaet: they were also planning on switching icon themes for beta 1 as well (which will hopefully get in these uploads)
<skaet> micahg,  ack.
<infinity> micahg: xubuntu-default-settings processed.
<micahg> infinity: thanks, rerunning meta
<infinity> ampelbein_: I'll have a poke at that when I get home from a much-needed late lunch.
<infinity> (Unless someone else has been following the discussion and wants to help out ampelbein_? :P)
<micahg> hmm, I better wait until the publisher runs
 * infinity runs off for a bit; back later in the afternoon.
<ampelbein_> infinity: Thanks, it's not urgent. I'll be out in a few minutes to get some sleep.
<slangasek> micahg, Riddell, gilir: strange, why would we ever *remove* binary packages that depend on NBS packages?
<slangasek> that seems very wrong to me
<micahg> slangasek: it is wrong, ask Riddell why he did it :)
<slangasek> we've always just left the binaries in the archive but uninstallable, so we don't have to go through a NEW roundtrip
<slangasek> micahg: heh, ok
<gilir> lubuntu-default-settings uploaded
<micahg> we just needed lightdm-gtk-greeter uploaded, but I was having trouble with svn-buildpackage last night, I hope to get that ready tonight
<slangasek> cjwatson: are you around enough to launch a queue bot for us? :)
<infinity> Is it running out of ~cjwatson?
<slangasek> last I knew, it was running out of cjwatson.broken-telco.uk
<infinity> Hah, right.  Special.
<infinity> Oh, I should reject the gnome-scan binaries from NEW before something goes pear-shaped there.
<infinity> ampelbein_: If you're heading to bed, I'll review your upload, and just upload for you if it looks sane, and fix it if not.
 * infinity really runs off to lunch now.
<slangasek> Riddell: were there other binary removals because of NBS?  That really concerns me, we should almost never remove binaries from the archive unless they themselves are NBS, or the source package is FTBFS (in which case all the binaries should be removed)
<slangasek> Riddell: removing some of the binaries due to dependencies leaves us with no sane way for account for this having been done
<seb128> micahg, you don't need snv-buildpackage, just copy the debian dir over in an unpacked tarball directory...
<micahg> seb128: yes, I could've done that too now that I think about it, but it was 3AM :)
<seb128> micahg, that is a valid reason indeed ;-)
<skaet> Riddell,  -7 days,  steps 2 & 3 done.  (archive frozen,  email sent and topics changed. )
 * skaet needs to step out to pick up dog from vet,  back in an hour or so
 * iulian is thinking of uploading GHC.
<iulian> Could you please let me know when the best time to do that is?
<slangasek> iulian: I don't think there's a time that's better than others - is there more to the question? :)
 * micahg would think after beta 1 unless it's needed beforehand
<slangasek> it's universe
<micahg> yes, but the people doing rebuilds can be fixing things for beta 1 :)
<slangasek> so not impacted by the beta freeze, except in a mechanical sense
<slangasek> all other things being equal, sure
<Laney> it starts a huge transition :-)
<slangasek> oh, another one of /those/ ghc uploads
<slangasek> (i.e., an even-numbered one)
<iulian> :)
<Laney> that could be annoying given the freeze, indeed
<slangasek> yeah, in that case you might find it more enjoyable to wait until after beta-1, so you're not in a perpetual holding pattern
 * iulian nods.
<stgraber> skaet: a new ubiquity-slideshow package will be uploaded in a few minutes, sorry for missing the deadline, been fighting to get all the flavours to at least show the right version of Ubuntu ;)
<stgraber> alright, uploaded the new ubiquity slideshow now
<stgraber> hopefully the only update we'll see for that one are translation updates
<slangasek> someone want to wave my activity-log-manager update through unapproved?
<slangasek> (otherwise I'll do it myself)
<stgraber> can someone wave ubiquity-slideshow-ubuntu through the unapproved? would be great to have it built before the first dailies
<slangasek> yep, am processing the lot
<stgraber> oh, I guess I also should upload a new d-i to get the new netcfg. Will do that in a few minutes
<stgraber> new d-i in the queue, no change rebuild for the new netcfg
<stgraber> do we have queuebot's code somewhere? I have plenty of servers with very reliable access to IRC where that one could run (assuming it just requires access to IRC and LP)
<skaet> stgraber, if we can find the source,  that would be most welcome.
 * skaet thinking this needs to be part of the infrastructure that gets turned on whenever archive gets frozen.
<skaet> stgraber,  just checked queue,  not quite there yet.   ubiquity slideshow was, so let it through.
<stgraber> skaet: I got the waiting for approval mail a while ago, weird
<stgraber> skaet: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= now shows both d-i (no change rebuild) and ubiquity (switching to beta and starting ibus)
<skaet> stgraber,  yup.  handling
<skaet> stgraber,  debian-installer through
<stgraber> thanks
 * skaet looking at ubiquity now
<skaet> stgraber,  ubiquity through
<skaet> slangasek,  activity-log-manager approved.
 * skaet likes simple changes... ;)
<slangasek> skaet: thanks :)
#ubuntu-release 2012-02-24
<NCommander> skaet: you around? I need to confirm some things for precise SRU hardware enabelement
<skaet> NCommander,  yup
<NCommander> skaet: would this be a good time for a call?
<skaet> NCommander, sure
<skaet> slangasek, have updated MilestoneProcess and BetaProcess with the results of today's IRC discussions - could you (and any other member of the release team who's interested ;) ) give it a review?
<micahg> could someone please let xubuntu-meta through?
<infinity> micahg: Again?
<micahg> this is the first upload today :)
<infinity> micahg: Didn't I NEW... Oh, that was defaults.
<micahg> yeah
<micahg> it'll need binNEW in a while also
<Riddell> hmm, I screwed up on my removals?
<Riddell> sorry about that
<infinity> Riddell: A lot. :P
<infinity> micahg: Yeah, I'm watching for it.
<micahg> infinity: thanks
<infinity> Riddell: Do you have a list of everything you removed, perchance?
<infinity> Riddell: Failing that, it's raw SQL to try to figure it all out.  Or guesswork.
<micahg> infinity: how much longer will you be around?  I need to upload 2 ubuntustudio sources in a few hours before I can upload the meta again
<Riddell> infinity: all that http://paste.kde.org/428138/
<Riddell> hmm whyever did I do that?
<infinity> micahg: I'll be idling.
 * micahg pokes superm1 or Daviey to reupload mythbuntu-lightdm-theme
<infinity> Riddell: Was it possible there was meth involved?
<micahg> gilir took care of lubuntu and I've got xubuntu and ubuntustudio, so I think we'll be good
<Riddell> infinity: no, just severe head trauma
 * Riddell hangs head in shame
<infinity> We'll get you a new skull.
<infinity> I'll gift-wrap one for you for UDS.
<Riddell> thanks
<Riddell> I'm going to sleep, if you notice any other mess ups I've made do text (SMS) me
<infinity> Riddell: Letting you sleep seems slightly less cruel.
<infinity> Riddell: G'night.
<superm1> micahg: what needs to be changed and uploaded?
<micahg> superm1: just a no change rebuild unless you need other changes, the binaries were removed accidentally this morning
<superm1> micahg: oh i see.
<superm1> okay i'll take care of it
<micahg> thanks
<jbicha> I think I need to go to bed, making mistakes now, could someone go ahead and reject gnome-disk-utility?
<skaet> mythbuntu-lightdm-theme no change rebuild passed through.
 * skaet --> zzz time.
<slangasek> skaet: process page changes look good to me
<superm1> no change rebuild on mythbuntu-lightdm-theme is still in NEW?
<micahg> superm1: the binaries were removed, so it needed binNEWing
<superm1> oh, that's annoying
<micahg> superm1: that was the whole point of the upload :)
<superm1> i didn't realize they'd have to go through NEW again, but yeah makes sense
<micahg> binary not in archive in release it's uploaded to requires binNEW
<stgraber> ok, let's see how long that python script will work until it crashes ;) that's basically a 50 lines long script poking at the LP API and doing almost raw IRC (well, python-irclib), minimal but might do the trick
<stgraber> actually, I'll add some more exception handling around the LP code, just in case LP doesn't answer for some reason ;)
<stgraber> now it should be ready to deal with LP going offline sometimes
<stgraber> will see if it's still around tomorrow morning ;)
<stgraber> ok, and now we have package sets too
 * micahg wonders who uploaded a PPA version to precise :)
<ScottK> of?
<micahg> gnome-disk-utility
<stgraber> micahg: "02:49 < jbicha> I think I need to go to bed, making mistakes now, could someone go ahead and reject gnome-disk-utility?"
<micahg> ah, right, I  actually saw that :)
 * micahg figured someone would've done it by now :)
<ScottK> Rejected then.
<stgraber> I guess it'd be nice to put some of that germinate magic into the bot so instead of package sets it can tell you if it's on a media or if it's seeded or if it's a build-dep of something seeded
<micahg> stgraber: we do have the seeded-in-ubuntu and reverse-dependency tools
<micahg> *reverse-depends
<stgraber> micahg: yep, would just need to make some caching as seeded-in-ubuntu takes longer than parsing the whole queue does ;)
<micahg> if you check before posting it, does it matter with the amount of packages we gets?
<stgraber> probably doesn't if run in a separate thread. Currently the function looking at the queue is fast enough that I shouldn't be missing any of the IRC PING/PONG but if it gets much slower, then the bot might get disconnected depending on the server's configuration
<Riddell> that queue is filling up :)
<pitti> I did a review round about two hours  or so ago
 * pitti has another look
<pitti> couple of nice FTBFS fixes
<pitti> the other fixes look ok as well, and all unseeded/universe
<pitti> ^ CVE fix, accepting too
<ajmitch> pitti: sorry for filling up the queue, just trying to go for important fixes for unseeded packages :)
<Riddell> pitti: when doing a review what are you looking for?
<Riddell> working out if packages aren't on CDs?
<Riddell> then of the ones that are what do you look for?
<pitti> Riddell: mostly that it's safe at this point, i. e. very cautious for packages on install images
<pitti> and not introducing new libraries/transitions etc. for universe
<pitti> bug fixes, FTBFS fixes etc. are fine for universe
<pitti> (and very welcome in fact)
<Riddell> precise_probs.html looking so much nicer, thanks pitti :)
<ajmitch> pitti: so something like augeas, which I think is seeded - should I sponsor the upload & have it sit in the queue until after beta 1?
<pitti> ajmitch: depends on the kind of changes
<pitti> the CDs are by far not finalized yet
<pitti> for one, the ubuntu ones are all oversized
<pitti> we might get a ffox/tbird upload to help there
<ajmitch> just an added depends on the -dev package to libxml2-dev
<ajmitch> change is by Laney, so I think it's sensible :)
<pitti> ajmitch: that sounds like it'd fix FTBFS of other packages, and thus sonuds fine
<pitti> anythign which doesn't change the structure of the packaging, library transisions, etc.
<pitti> (or break FF/UIF, of course)
<ajmitch> I'll upload & let you check then, I've test-built it
<Laney> what is the 'daily' seed?
<pitti> Laney: uh?
<Laney> I ran: $ seeded-in-ubuntu augeas
<Laney> augeas-lenses (from augeas) is seeded in: ubuntu-server: daily
<pitti> nice tool
<pitti> I ususally look at the Task: header in apt-cache show
<Laney> yeah, tumbleweed wrote it
<Laney> it can take a source package, which is helpful
<pitti> Laney: so I guess it means it's on the alternate CD (daily-live is desktop)
<Laney> ah
<pitti> Laney: corresponding to http://cdimage.ubuntu.com/daily-live/
<ajmitch> really, queuebot? ubuntu-desktop for augeas? :)
<Laney> it's true
<pitti> it's not on any image
<pitti> not libaugeas0, anyway
<ajmitch> ok
<Riddell> pitti: you expect to get rid of the oversizing for this beta?
<pitti> Riddell: we'll discuss it in today's release meeting
<pitti> I hope we can land ffox/tbird, then it's either python3 or yet another langpack
<pitti> I think we still have two
<ajmitch> that looks a bit broken
 * ajmitch wonders where it got that version info from, mana was 0.6.0-1, and in universe
<infinity> Weird.
<infinity> Maybe queuebot has issues parsing syncs sanely.
<infinity> (That apr is just a revert of the previous upload)
<ogasawara> skaet et al:  Hi, I'd like to request a beta freeze exception for the kernel...
<ogasawara> Upstream notified us of a patch yesterday evening to fix up a bug with their original RC6 patch we have applied.  The RC6 patch in it's current form is incorrect and disables the wrong RC6 states.  This fix has been tested and confirmed to fix bug 935965 and will hopefully also resolve bug 937378 (testing feedback still pending).  I do consider this fix critical for the release and would like to see it make Beta.  Addition
<ogasawara> ally, without the fix, all the testing we will receive for RC6 will be invalid.  The upload will only contain this single fix.
<ubot2`> Launchpad bug 935965 in linux "RC6 enabled causes severe graphics corruption" [High,Triaged] https://launchpad.net/bugs/935965
<ubot2`> Launchpad bug 937378 in linux "Patched kernel with rc6 enabled shutdowns" [High,Triaged] https://launchpad.net/bugs/937378
 * stgraber looks at what happened with queuebot and mana's version...
<ScottK> Is this OK for Restricted (I'm thinking not):
<ScottK> + * This is UNPUBLISHED PROPRIETARY SOURCE CODE of Broadcom Corporation;
<ScottK> + * the contents of this file may not be disclosed to third parties, copied
<ScottK> + * or duplicated in any form, in whole or in part, without the prior
<ScottK> + * written permission of Broadcom Corporation.
<ScottK> In which case, the bcmwl upload in queue may be problematic.
<ScottK> slangasek: ^^^
<stgraber> ok, something is really wrong with my version number handling ;)
<skaet> ogasawara, approved.     Can you get it in today?
<ogasawara> skaet: I can do it now in fact
<skaet> ogasawara, please do.
<ogasawara> skaet: uploaded
 * skaet continues on with the backscroll... :)
<skaet> ScottK,  yeah those licensing terms make it a concern. :P
<ScottK> skaet: I'll go ahead and reject it.  Would you please talk to Alberto about it so we can get it fixed post-beta?
<stgraber> version handling in queuebot should be fixed now
<Riddell> hmm, linux
<ogra_> i think leann asked for a freeze exception before
<ogra_> (like 10 lines above :) )
<skaet> ScottK,  email sent,  couple of pings initiated.
<ScottK> Thanks.
<ScottK> Accepted lintian since it got an FFe and isn't on any images.
<Riddell> ogasawara: that's the linux build you want?
<ogasawara> Riddell: for the linux-3.2.0-17.27 package, contains a critical fix for RC6 enablement
<Riddell> ooh you've got your buzzwords sorted, critical and enablement :)
<ogra_> haha
<pitti> Riddell: ok to upload a new LibO to fix the component-mismatches madness?
<pitti> build time is < 2 days on arm, so well within the margin IMHO
<ogra_> pitti, LibO isnt seeded on arm
<pitti> ogra_: anyway, it's installable now
<Riddell> pitti: sweetshark is happy that's the final fix?
<ogra_> no worries about buildtime wrt images
<Riddell> ogasawara: "SAUCE: drm/i915: fix operator precedence when enabling RC6p"?
<pitti> Riddell: asking
<ogasawara> Riddell: yep, that's it.  without the patch the RC6 states which we want enabled, aren't
<Riddell> ogra_: yeah you guys want to get into calligra instead :)
<Riddell> ogasawara: accepted!
<ogasawara> Riddell: thanks!
 * Riddell is taking archive admin stuff slowly for fear of another mess like yesterday
<pitti> Riddell: yes; it mostly reverts to ubuntu2, except for the approved MIRs which are now in main
<Riddell> pitti: cool, go for it
<pitti> ooh, ffox/tbird in the queue
<pitti> thanks chrisccoulson
<ogra_> to keep the arm buildds busy :)
<ogra_> and if Riddell lets my alsa-lib upload in, they can play music while building ;)
<Riddell> ogra_: is that a hint? :)
<ogra_> heh, just a small one ...
<ogra_> its not super urgent though
<Riddell> ogra_: /pandaES-naming-changes.patch the patch headers need fixed
<ogra_> oh, i used edit-patch
<ogra_> why doesnt that DTRT !
<Riddell> ogra_: it needs you to use emacs too :)
<Riddell> ogra_: can you fix those and reupload?
<ogra_> geez !
<ogra_> sigh, seriously, it should just dump my name in if i call edit-patch ... tsk... yeah, will re-upload
<pitti> I keep the others in the queue for now until they get diffy
<jdstrand> skaet: hi! I am preparing the apparmor userspace upload
<ScottK> jdstrand: I think Riddell is driving today.
<jdstrand> ok
<jdstrand> Riddell: ^
<skaet> jdstrand, ack.  :)
<Riddell> skaet is too, you can either convince me or her
<Riddell> jdstrand: what is it and why do we want it?
<jdstrand> skaet, Riddell: I am preparing the FFe now, but this is in support of apparmor/LXC and is on the landing page
<Riddell> jdstrand: but why is it important for the beta?
<stgraber> Riddell: it's making stuff stop crashing in containers
<stgraber> (where stuff currently is mostly udev upgrades and localegen for me, but I know there are more)
<jdstrand> Riddell: there is that, and we would like to have as many people testing it as possible. It was supposed to be in before FF, but there were some last minute bugs that prevented that. it passes all upstream regression tests as well as our distro tests
<Riddell> jdstrand: ok, get the FFe and upload and we'll see if it's suitable for beta (probably will be today but getting less so as the beta progresses)
<jdstrand> Riddell: thanks
<stgraber> skaet: it can't, I don't think we have an audit trail for these or if we do, it's not accessible over the API
<stgraber> skaet: I also wanted to print the irc nick of whoever uploaded the package but that's also something missing in LP, I'd have to parse the .changes file for that which would be pretty ugly ;)
<skaet> stgraber,  ah well.  Was hoping.   Thanks for getting it going.   Big help. :)
<Riddell> Daviey: it's zul's uploads for swift and nova
<Riddell> Daviey: all fine, what's the reason to upload during beta freeze?
<Daviey> Riddell: As i said, in retrospect it could have been held back.
<Riddell> pitti: hold out for longer and you'll get more beer!
<Daviey> Riddell: i will not be upset if it's rejected.
<pitti> Riddell: darn, missed my chance
<jdstrand> skaet, ScottK, Riddell: fyi, apparmor FFe: bug #940422
<ubot2`> Launchpad bug 940422 in apparmor "FFe for apparmor 2.8beta1" [High,Confirmed] https://launchpad.net/bugs/940422
<ScottK> Right.
<ScottK> I'd lean towards putting it in now, but will leave the decision to Riddell or skaet.
<Riddell> skaet: the apparmour change?
<Riddell> ScottK rather ^^
<ScottK> Riddell: Yes.
<skaet> Riddell, jdstrand I'd rather it go in now, if its tested and ready too.
<jdstrand> it is ready
<jdstrand> and tested
<Riddell> skaet: ScottK: it needs the FFe reviewed in general, then we can decide on beta goodness
<ScottK> I read the FFe.  I think it should go in and better now than later.
<Riddell> jdstrand: just upload if it's ready, worst we can do is reject :)
<jdstrand> Riddell: ok. it will need a binary deNEW for the dh-apparmor package, which I shouldn't do
 * Riddell looks
<jdstrand> Riddell: basically, this includes a merge with debian (as explained in the bug)
<jdstrand> Riddell: debian didn't want our debhelper patch for dh_apparmor, so we created the dh-apparmor package as a part of the apparmor packaging
<jdstrand> Riddell: on its own, it does nothing because nothing depends on it
<Riddell> jdstrand: I don't see dh-apparmor in New
<jdstrand> sometime after beta1 I will pursue uploading a debhelper which removes our apparmor delta and Depends on dh-apparmor
<ScottK> Riddell: I think it'll just be binary New.
<jdstrand> Riddell: well, I only did the source upload a moment ago
<ScottK> After the source is accepted/built.
<jdstrand> (what ScottK said)
<Riddell> ok, I'm going out for the next three hours so you probably need to convince ScottK to do it
<pitti> Riddell: ^ reversion to python2, if you are so kind? it's a straight patch -R from http://launchpadlibrarian.net/86333969/lsb_4.0-0ubuntu16_4.0-0ubuntu17.diff.gz
<pitti> and I tested that lsb-release still works
 * Riddell looks
<ScottK> skaet: Any objection to apparmor?
<ScottK> If not, I'll approve/accept it.
<Riddell> ScottK: good with me
<skaet> ScottK,  no objections
<ScottK> OK.
<Riddell> pitti: accepted!
<pitti> cheer!
<ScottK> jdstrand: Accepted.
<jdstrand> \o/
<jdstrand> skaet, ScottK, Riddell: thanks
<jdstrand> ScottK: so, for the dh-apparmor binary deNEW, will you handle that or are you comfortable with me doing it since you reviewed it?
<ScottK> I'll look at it.
<jdstrand> cool thanks
<seb128> so, question for you r-t people ;-)
<ScottK> !ask
<ubot2`> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<seb128> we want to drop a public api from gtk2 (distro specific api added in natty) for the lts
<seb128> ScottK, sorry I'm typing and thinking how to formulate the question ;-)
<ScottK> Sure.  No problem.
<seb128> the api is the one for grip handles in the corner to resize windows
<seb128> I expect that has a few rdepends
<seb128> would it be reasonable to drop the public includes for beta1 which will ftbfs the stuff that use it, or better to try to fix rdepends first?
<debfx> jdstrand: dh-apparmor Breaks: debhelper (<< 9.20120115ubuntu2) but ubuntu2 still contains dh_apparmor
<seb128> also would you be ok with an upload which turns the function to a nop basically today or better after beta?
<jdstrand> debfx: that's fine. nothing pulls in dh-apparmor yet
<jdstrand> debfx: I will be doing a debhelper upload after beta1 to remove the apparmor delta
<jdstrand> (but add a temporary Depends until everything that needs it Build-Depends on dh-apparmor, at which point we can drop the debhelper Depends)
<jdstrand> that will happen probably in the 12.10 time-frame
<debfx> jdstrand: hm still the breaks should be "<=", no?
<jdstrand> debfx: I see what you mean. I can adjust that-- I guess 9.20120115ubuntu2 snuck in since kees' upload
<jdstrand> (it still isn't a problem though, since nothing depends on dh-apparmor)
<debfx> right, it's fine as long as it's done before the debhelper upload
<jdstrand> ScottK, skaet: should I upload ubuntu2 based on debfx comment or wait til after beta1?
<jdstrand> debfx: yes
 * skaet looking
<jdstrand> skaet: the new dh-apparmor Breaks/Replaces with the version of debhelper that is in the archive now. This isn't a problem unless someone Build-Depends on dh-apparmor, which nothing does
<jdstrand> skaet: (a new debhelper upload snuck into Ubuntu since kees' Debian apparmor upload)
<jdstrand> imho, it isn't needed until I update debhelper, which I won't do until after beta1
<jdstrand> that said, I am ready to upload a new apparmor if you want
 * skaet being slow -- sorry jdstrand
<jdstrand> skaet: actually I said that wrong. dh-apparmor should Breaks/Replaces on what is in the archive now, but it doesn't (it does on the previous ubuntu version of debhelper)
<jdstrand> skaet: but again. nothing in Ubuntu knows about dh-apparmor, so there is no problem until I upload debhelper, which I won't do until next week, at which time I would upload apparmor before
<skaet> jdstrand,  ok,  thanks for clarifying.   lets leave it alone then for now.   If a critical bug shows up,  fold it in please.
<jdstrand> skaet: sure, but that won't happen :)
<jdstrand> skaet: thanks :)
<skaet> thanks jdstrand :)
<seb128> slangasek, there?
<seb128> slangasek, I want to discuss gtk2 changes and strategy to get them out with you when you will be around ;-)
<ScottK> seb128: My suggestion would be the best way is to fix the rdepends first.
<seb128> ScottK, before or after beta?
<ScottK> How many packages?
<seb128> there is probably a couple of those only, I will need to grep through the archive to figure which ones though
<ScottK> I'd think probably after, but until we know which/how many it's hard to say.
<tumbleweed> stgraber: re the bot discussion earlier, seeded-in-ubuntu does use cached data, it's the source->binaries lookup that's slow
 * skaet --> lunch,  biab.
<stgraber> tumbleweed: yeah, I noticed that a bit later on, importing seeded-in-ubuntu from the bot would be really quick when then querying the binary packages
<stgraber> tumbleweed: the build-dep part is tricky though as I didn't find a way of making it fast ;)
<tumbleweed> yup, so if you have a local cache of those mappings...
<stgraber> tumbleweed: the LP API give me these already I believe, so that part is fine
<tumbleweed> build-dep part?
<stgraber> tumbleweed: checking if a source package in the queue produces a binary that's a build-dep of something seeded
<tumbleweed> ah
<tumbleweed> that's not an enourmous amount of data either
<tumbleweed> I almost made reverse-depensd use a similar pre-calculated json dump. But it was useful to have a lot more data than just build-deps, and that meant it had to be a webservice
<slangasek> ScottK: hrmmmm, if that's the effective license then yes it's a problem; but I've seen that particular message before, I think it may not mean what it says?  No clarifications anywhere to be seen?
<slangasek> seb128: hey, what's up with gtk2?
<ScottK> slangasek: Not that I saw.  I rejected it and skaet emailed Alberto to look into it.
<ScottK> If it's all good we can still get it in later.
<slangasek> ok
<ScottK> I get really nervous about leaving apparently undistributable stuff in the queue.
 * slangasek nods
<ScottK> jdstrand: apparmor accepted.
<jdstrand> ScottK: thanks! :)
<ScottK> You're welcome.
<seb128> slangasek, I want to drop public apis we distro added in natty and which probably have a few rdepends, I was wondering the best way to deal with it
<ralsina> nessita, gatox, dobey: maybe a couple of reviews? https://code.launchpad.net/~ralsina/ubuntuone-control-panel/opt-parsing/+merge/94599
<ralsina> oops, wrong channel, sorry!
<seb128> slangasek, well first I wanted to check if you think it's fine dropping distro specific apis if we fix our rdepends
<seb128> slangasek, then I wanted to see if fixing the rdepends before beta1 is ok (there is probably a few) or if better after
<seb128> slangasek, I was pondering dropping the includes so the test rebuild catch the api users, but we could as well grep through the archive in some way
<slangasek> seb128: as long as the package dependencies properly tend to the upgrade path, and you're sure no one outside of Ubuntu is using them, I'm ok with them being dropped
<seb128> slangasek, I've also a patch that turn those api to no-op for now to not break abi which might be another way to deal with it
<slangasek> there's a community lintian lab running somewhere now, right?  That might be the quickest / most reliable way to locate packages using those symbols
<seb128> ok
<seb128> the functions are
<seb128> gtk_window_get_resize_grip_area
<seb128> gtk_window_resize_grip_is_visible
<seb128> gtk_window_get_has_resize_grip
<seb128> gtk_window_set_has_resize_grip
<seb128>  
<seb128> slangasek, do you know who I can talk to who is running the community lintian?
<slangasek> broder knows
<seb128> ok, thanks
<seb128> no hurry to drop those I think I will wait after beta1
<seb128> slangasek, they are basically the resize handle added in the bottom right corner of windows
<seb128> the api is used by a few things to turn them off
 * slangasek nods
<broder> seb128: what's up?
<seb128> broder, hey
<seb128> broder, is there any way the lintian community install could be used to find gtk2 users of the "resize_grip" apis?
<broder> seb128: yeah, probably. my guess is that grepping the binaries would be most reliable. i'll kick it off
<broder> (will probably take a few hours)
<seb128> broder, thanks
<slangasek> objdump -T $allbinaries | grep gtk_window.*resize_grip, preferably
<seb128> broder, gtk2 rdepends only would be good, that's a valid api in gtk3 and we will keep it there
<broder> seb128: do you know of an example package that's using it currently so i can double-check my search is working, or has everything you know about been converted?
<seb128> broder, I'm trying to think about one...
<seb128> broder, I don't find any off hand, that's good sign for the rdepends that will need to be fixed but doesn't help you...
<seb128>  
<broder> seb128: ok. i'll just go ahead and start searching and we'll see what comes up
<seb128> btw I just uploaded a gneary and smplayer reverting the unity quickly added earlier today, I talked to mhall119 and dholbach about that
<seb128> they agreed to not patch universe things with new strings this cycle, we will have a session at UDS on how to deal with those
<seb128>  
<seb128> broder, thanks
<dobey> can i get an upload approval to be able to fix bug #939797 for the beta?
<ubot2`> Launchpad bug 939797 in ubuntuone-installer/trunk "Failed to execute child process "ubuntuone-control-panel-qt"" [High,In progress] https://launchpad.net/bugs/939797
 * micahg hugs seb128
 * seb128 hugs micahg back
<broder> oh hey, we have hits. i guess it is working
<seb128> broder, which ones?
<broder> seb128: lxdm and lxlauncher so far. note that it's running in filesystem order, not alphabetical
<seb128> broder, indeed, those are valid hits, great ;-)
<seb128> broder, not sure how long the grepping will take but I closed IRC can you email me the result when it's done?
<broder> seb128: sure, no problem
<seb128> thanks
<broder> seb128: oh, that actually finished much faster than expected
<broder> seb128: lxdm, lxlauncher, and xfdesktop4 were the only hits
<dobey> maybe i should e-mail or sub ~ubuntu-release to the bug instead?
<slangasek> dobey: please go ahead
<slangasek> dobey: fwiw, best practice during a milestone hard freeze (i.e., beta + final release) is to Just Upload and let the changes be reviewed in the freeze queue
<dobey> slangasek: ok. thanks
<seb128> broder, oh, excellent, thanks!
<slangasek> pitti: do you know why procps/lucid doesn't show up green on http://people.canonical.com/~ubuntu-archive/pending-sru.html ?  the bug is tagged verification-done-lucid
<slangasek> and has been for a while
<micahg> FYI, I won't be able to get lightdm-gtk-greeter uploaded until Sat night
<seb128> micahg, what's the issue with it?
<seb128> micahg, it should basically be copying the debian dir from debian and uploading?
<micahg> seb128: we were missing a diff for the flavors to override settings (I got the Debian version working last night, but mr_pouit caught this thing missing, so he updated the old lightdm packaging for the greeter, I'm going to try to consolidate the 2
<seb128> micahg, ok, I was just wondering if there was an upstream issue
<seb128> micahg, so mostly packaging
<seb128> micahg, you guys should be able to handle it I guess ;-)
<micahg> yeah, I'd like this to mainly be maintained in Debian, so I want to get us as close as possible to that
<skaet> Riddell,  am not seeing the Precise Beta 1 milestone on the tracker,  just the dailies.    We probably should set up the milestone, and put a copy of the current dailies there, so folks can kick at them over the weekend.   thoughts?
<skaet> or at least start redirecting dailies there once the new kernel is built into some images...
<stgraber> skaet: whenever we have our first beta1 candidates someone should indeed update ~/.isotracker.conf, disable the Daily milestone on the tracker, create the Beta 1 milestone and mark it as "testing" (ideally before any auto-publishing happens of a beta 1 candidate, or manual work would be needed ...)
<skaet> Riddell,  NCommander, http://pad.ubuntu.com/ubuntu-release  has been set up - please record any bugs that might trigger rebuilds on it,  and indicate which images affected.
<skaet> stgraber,  if we don't hear back from Riddell in next hour or so,  I'll take a pass at switching it over (while folks are still around to help ;) ).
 * skaet would like the images with the new kernel to start getting tested...
<broder> slangasek: i think it needs to be verification-done - i think verification-done-lucid is an unofficial helper tag
<slangasek> broder: well, that's unhelpful ;)
<slangasek> because it's not verification-done everywhere yet, but we ought to get it published for lucid anyway...
<stgraber> hmm, I guess I need to fix that packageset ^
<stgraber> slangasek: moving resolvconf to core sounds good to you?
<infinity> stgraber: Sounds right.
<stgraber> done
 * infinity loves that "beta freeze" means "upload every package with a build time >= $some_large_number"
 * micahg is glad there's not another chromium upload pending
<micahg> although, if we figure out armhf, I'm happy to do one
<infinity> Well, I have a failed build tree sitting on my QuickStart.  Maybe I'll prod it with a stick over the weekend if I don't find a social life and/or nap.
<NCommander> skaet: thanks, got the link handy
<skaet> http://pad.ubuntu.com/ubuntu-release
<skaet> :)
 * skaet not sure to parse "got the link handy" as question or affirmation - so erring on side of overcommunicating it.  ;)
<micahg> skaet: should I add the Ubuntustudio information to the pad?
<skaet> micahg,  yes please
<Riddell> evening
<micahg> skaet: done
<slangasek> the resolvconf in the queue would be very good to have before beta
<slangasek> high-impact for upgrades from oneiric in some circumstances
<Riddell> skaet: I can review it in 30 mins
<skaet> Riddell,  thanks.
<Riddell> um that was for slangasek
<skaet> yup
<slangasek> Riddell: ok, cheers :)
 * skaet really likes seeing the package sets from the queuebot!
<stgraber> will be even better once I get to add seeded-in-ubuntu and reverse build depends support to it
<stgraber> so we'll have a magic "that package is affecting something that we ship" flag on IRC
<infinity> ^-- fixes FTBFS with new libreoffice.
<infinity> And syncpackage lies and thinks nlpsolver doesn't exist in Debian.  Grr.
<infinity> Oh, or maybe the experimental upload is still in incoming.
<micahg> infinity: probably, it's only been 3 hours :)
<infinity> micahg: Yeah, yeah.
<infinity> micahg: Rene's other upload made dinstall, I didn't really think about it.
<micahg> openclipart?
<infinity> (jodconverter and openclipart are both fixes to work with the new libreoffice, if someone other than me wants to accept them)
<infinity> slangasek: Did you decide not to support "inet6 dhcp" intentionally?
<infinity> slangasek: (Seems not, since your dns-ns regex looks for hex and colons...)
<slangasek> infinity: didn't actually think about it too deeply - noticed when I was prepping the upload that inet6 wasn't in there, but this was just cleanup for the previous netcfg breakage
<slangasek> stgraber: ^^ do you think resolvconf's "should tail be linked" handling needs to treat inet6 dhcp the same as inet dhcp?
<infinity> slangasek: Alright.  Well, looks fine other than that.  Just seems like it's worth having the regex cover inet6, in case we care later and no one remembers why it doesn't work. :P
<slangasek> there are rich bzr histories and bug logs ;)
<slangasek> but yes, we can fix that quickly enough
<stgraber> slangasek: "20:58 < stgraber> I think we could extend to cover "inet6 dhcp" too but it's not going to be a common use case"
<stgraber> slangasek: I think it's easy enough to add and it should behave exactly like "inet dhcp" so that makes sense
<slangasek> ah, missed that comment before, sorry
<slangasek> ok, I'll stage that fix in bzr
<Riddell> stgraber, skaet: uh oh, I broke the iso tracker http://iso.qa.ubuntu.com/qatracker/milestones/208/builds
<skaet> Riddell,  define broke please
<stgraber> Riddell: no you didn't ;) that's just my bad
<stgraber> Riddell: it'll be all fine once the first build lands
<stgraber> Riddell: I could actually just post the upgrade products that'll fix it
<Riddell> stgraber: php error on that page
<Riddell> stgraber: ok
<stgraber> Riddell: fixed
<stgraber> well, more like, fixed the reason why you were getting the crash ;)
<stgraber> I'll fix the crash for good in trunk
<stgraber> I thought I actually fixed that one, maybe I messed up or IS didn't pull the right version of the branch :)
<Riddell> stgraber: voila
<Riddell> stgraber: what's it written in?
<stgraber> it's a Drupal plugin, so PHP
<stgraber> or rather it's written in Drupal ;) considering how little raw PHP functions are actually called (kind of C++ vs Qt4-C++)
<Riddell> I've done drupal modules before, it's all good until you can't work out the drupal way to do it and you're not sure if the raw PHP way is good enough
<Riddell> which is just like drupal vs raw HTML for editing websites really
<Riddell> ok who removed the trousers?  I know it's friday night but there's no call for that
<infinity> Err, who mangled the preinstalled pipeline on the pad?
<infinity> And dropped omap completely?
 * infinity grumbles.
<slangasek> not I
 * Riddell is innocent this time
 * infinity fixes.
<stgraber> Riddell: yeah, the previous version of the tracker was meant for Drupal 4/5 and was an horrible mess with mixed raw html and raw php code ...
<stgraber> Riddell: the new one is clean Drupal 7 using only Drupal functions and Drupal templating
<stgraber> Riddell: so there's very very little html in the code and when that's the case, it's only as some prepend/append of some block in a standard Drupal form
<stgraber> also the old Drupal didn't have an ORM so you had to do pretty much raw SQL :( that's all been dropped now and the current tracker is doing clean SQL queries through the ORM :)
<Riddell> stgraber: ORM?
<slangasek> object request manager
<slangasek> not to be confused with ORLY
<slangasek> oh, no, that's "object-relational mapping" in this context, isn't it :)
<stgraber> yep
<skaet> infinity,  I'm guilty
<infinity> skaet: Tsk.
<infinity> skaet: All fixed.
<stgraber> Riddell: so that's basically something that gives you nice complete objects from database entries, doing all the joining for you
<Riddell> skaet: pst, just blame it on brain damage, works every time for me
<Riddell> infinity: how do I know if the live rootfs server has the latest livecd-rootfs ?
<stgraber> Riddell: Drupal's isn't great to be honnest, I much prefer python-storm but it's still nice to have the abstraction layer and not have to care about the different DB engine or copy/pasting huge chunks of raw SQL :)
<infinity> Riddell: They always do.
<skaet> infinity,  omap images are in the manifest for this release, based on what I was hearing 2 days ago -- only for a couple of images,  and given the speed of the arm builds - fewer we're doing the better for the respins. :P
<Riddell> infinity: hmm it's saying "bad project: kubuntu-active"
<infinity> Riddell: Except if you had to update BuildLiveCD.
<infinity> Riddell: Which you did. :)
<infinity> Riddell: That requires manual intervention, since it lives outside the chroots.
<Riddell> infinity: aah
<Riddell> infinity: are you able to intervene manually?
<infinity> Riddell: -> canonical/#{webops,is}
<skaet> s/omap images/omap images for Ubuntu aren't/
<Riddell> ok thanks
<infinity> Riddell: I don't have access to those machines anymore.
<infinity> skaet: I suspect there may have been some miscommunication.
 * skaet was only aware of omap for ac100...
<skaet> infinity,  likely
<infinity> skaet: We dropped two images (armel+omap4 and armel+mx5), the rest are still being built currently.
<slangasek> ac100 is not omap at all
<skaet> slangasek, you're right.
<infinity> Well, that amounts to 3 images, since it also affects ubuntu-server.
<skaet> was thinking armel.... sigh.
<slangasek> and my understanding is that we're keeping omap for now
<infinity> armel+omap will be the one and only armel image we keep down the road.
<infinity> Since the kernel comes from mainline, it's a decent one to keep for baseline smoketesting.
<skaet> slangasek, inifinity,   stand by for an email to circulate amongst the parties so we can get the manifest cleaned up.
 * skaet adds it to the todo
<skaet> thanks for fixing inifinity - I won't touch until we get the manifest signed off on.
<slangasek> note that the current pipeline there spits out images about as fast as they can get tested, anyway :)
<infinity> skaet: This might be partially my fault.  I keep forgetting there's wiki documentation and manifests and such, as I just consider nusaskan's crontab to be authoritative. :/
 * skaet chuckles and agrees
<skaet> with slangasek's comments.
<skaet> infinity,  np,  should have checked with you first before showing initiative.  ;)
 * infinity goes to print a new t-shirt with "You should have checked with me before showing initiative."
<infinity> It will go nicely with my "Let's assume I'm right, it'll save time."
<slangasek> who here approved nova, swift, python-novaclient?  It looks like glance is supposed to go with that set
<infinity> Not I.
 * infinity wonders how that escalation of queue audit trails is going.
<Riddell> slangasek: pitti I think, it was discussed at the release team meeting
 * skaet is encouraging folks to comment on https://bugs.launchpad.net/launchpad/+bug/885739 and has pinged flacoste on it today
<ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
<Riddell> can he fix the speed of queue while he's at it? :)
<slangasek> Riddell: ah yes, thanks,
<skaet> infinity,  looking forward to seeing you in those shirts.  :)
<infinity> skaet: We have stakeholders from a few directions championing that bug, I'm a bit irked that it not gone past triaged since November.
<skaet> infinity,  agreed
<skaet> see comments encouraging other stakeholders to comment on the bug directly so the heat goes up.
 * skaet plans on monitoring it daily now
<skaet> slangasek,  any objections to a request to the rest of the release team members to start broadcasting in the channel when they approve something?
<slangasek> seems reasonable tome
<skaet> I see some do it,  and others not.   and agree its an overhead, but not sure we have other short term option for sanity.
<Riddell> skaet: you mean when we queue accept something?
<skaet> Riddell,  yes.
<skaet> from unapproved or new
<Riddell> skaet: just so you know who to blame?
<skaet> Riddell,  so we can figure out who to ask questions of.
<Riddell> that's a more polite way to put it :)
<skaet> :)
<Riddell> skaet: fine for beta freezes but I think general new processing has enough overhead as it is (as shown by nobody doing it for the last two weeks)
<skaet> Riddell,  yes, its during the beta freezes and final freezes its important.
<skaet> or rather most important/time critical
<Riddell> that's fine
<skaet> ScottK,  infinity, ^ any concerns?
<infinity> Works for me.
<skaet> NCommander, ^^ ?
 * ScottK thought that's what the queuebot was for.
<infinity> ScottK: Except the queuebot doesn't tell you who did the accept.
<skaet> ScottK,  https://bugs.launchpad.net/launchpad/+bug/885739
<ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
<ScottK> Sure.
<infinity> (because it can't)
<infinity> When it can, no more need to broadcast. ;)
<skaet> +1
<slangasek> skaet: oh, I agree with Riddell that we don't want to impose that overhead on NEW processing
 * Riddell accepts alsa-utils
<slangasek> since that's really quite separate from the freeze
<slangasek> oh, and the glance accept above was me btw ;)
<infinity> slangasek: Well, except for NEW during freezes, which can relate. :)
 * ScottK doesn't understand why we need to know.
<slangasek> infinity: the only way new can impact anything during a freeze is if it's an existing CD-affecting source that adds new binary packages, and in those cases we want the packages up-to-date for the milestone anyway
<slangasek> ScottK: well, the triggering example was 4 related packages 3 of which were accepted
<slangasek> and I was trying to figure out if that was intentional or accidental
#ubuntu-release 2012-02-25
<ScottK> Is that common enough it's worth it to comment on every accept?
<ScottK> Could we just ping on the problem cases and people reply?
<infinity> We've been doing that, but it's a bit problematic when the accept was out of your timezone.
 * infinity shrugs.
<infinity> I'm not wildly picky, but it can be irritating to hunt down rationale, or even a person to ask about rationale.
 * ScottK finds adding overhead to commonly performed operations to solve rare problems annoying.
 * Riddell snoozes
<ScottK> JFTR, New has been done.  I've done it for packages that were related to FFE's I approved.
<skaet> Thanks ScottK
<skaet> Riddell,  if still around,  are things set for the next set of dailies to show up as beta 1 - or still some things pending to do there?
<Riddell> skaet: iso tracker should be done
<nessita> hello everyone! I was wondering if someone can help me defining if a given bug requires a FFe or not
<Riddell> skaet: just ticking the boxes and pressing the button when the isos appear I think
<skaet> Riddell,  coolio.  nusakan switched?
<nessita> the bug is https://bugs.launchpad.net/ubuntuone-client/+bug/930716 (please note that there is a branch attached to the bug report that shows all the changes that would be needed to solve it)
<ubot2`> Launchpad bug 930716 in ubuntuone-client/trunk "ubuntuone.credentials is not preferring the SSO Qt UI for auth" [High,In progress]
<Riddell> skaet: hmm let me see
<Riddell> skaet: hmm how do I do that again?
<Riddell> nessita: so it's ubuntuone.credentials making use of a new API to show a given frontend?
<ScottK> Is either one shipped on the CD?
<nessita> Riddell: yes, the new API and new frontend are already in Ubuntu, the branch onle makes ubuntuone.credentials "prefer" that
 * ScottK votes bug fix (no FFe), but only barely.
<nessita> ScottK: ubuntuone.credentials is shipped on the CD, sso as well (but not the Qt bits). SSO will fallback to the GTK+ UI if the requested UI is not available
<ScottK> OK.
<ScottK> Unless Riddell disagrees, I think you can call it a bug fix.
<Riddell> fine with me
<nessita> thanks! :-)
<Riddell> skaet: sorry I need to sleep, you'll need to do whatever nusakan needs yourself
<ScottK> I bet we could do a release team meeting really fast and well with trello
<skaet> Riddell,  ack.  ok,  will handle.
<skaet> or at least will try.  ;)
<skaet> default_milestone=Precise Beta 1 has been set in .isotracker.conf
 * skaet notes that edubuntu-dvd appear to be be building,  will see if it now shows up under Beta 1.
<skaet> Edubuntu DVD has now appeared under Precise Beta 1... *\o/*
<skaet> Framework for gathering release note information for Beta 1 is now up at https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<skaet> gnomescan is a FTBFS fix, have approved
<skaet> the unapproved queue is now empty, and so on that note,  time to go for dinner.
<infinity> skaet: gnomescan was being replaced with gnome-scan anyway.  I need to review and upload that this weekend.
<infinity> skaet: But oh well. :)
<skaet> infinity, :)  beer-o-clock!
<infinity> If crimsun swings by asking why his gnomescan builds are failing to upload, that's why.  And I'm on it (later).
<infinity> Oh, or Ampelbein may have already uploaded gnome-scan, even better.
 * infinity will clean up gnomescan later.
<ScottK> Wow.  Powerpc caught up.
<skaet> Riddell, NCommander, pitti, slangasek - since we've got a first set of images up under Beta 1 on the iso tracker,  I went ahead and disabled the crontab for now, so they have a chance to gather some test results.
<NCommander> skaet: great, I'll keep an eye on it over the weekend
<skaet> Thanks NCommander  :)
<tumbleweed> incoming tesseract spam
<skaet> NCommander,  could you and see if you can figure out why the ubuntu-server images for i386/amd64 didn't get built/posted?   also xubuntu-alternate appear missing.
<NCommander> skaet: will smack it
<skaet> :)  Thanks!
<tumbleweed> ScottK: thanks! you made quick work of that
<ScottK> ;-)
<ScottK> skaet: I accepted a kde4libs update today for a milestoned bug, so the Kubuntu images need rebuilding.
<skaet> ScottK,  which bug?
 * ScottK looks
<ScottK> skaet: Bug #935521
<ubot2`> Launchpad bug 935521 in kde4libs "missing file in kdoctools.install script" [High,Fix released] https://launchpad.net/bugs/935521
<skaet> ScottK,  thanks.   have added needed to the pad.  Edubuntu affected as well?
<ScottK> I don't know. If they ship any kde apps, they are, so I'd assume so.
<skaet> NCommander, ^^ please add Edubuntu and Kubuntu rebuilds to the list after you finish looking at server/xubuntu-alterate
<skaet> ScottK,  just checked the manifest,  and yes - they're included.
<skaet> in Edubuntu
<skaet> stgraber, highvoltage ^^ fyi.
<NCommander> skaet: will do
<skaet> Thanks!  :)
<highvoltage> thanks skaet
<ScottK> tesseract storm is over.
<stgraber> skaet: indeed, we ship kdeedu so we'll probably need a rebuild then
<Riddell> thanks ScottK
#ubuntu-release 2012-02-26
<stgraber> hmm, just noticed wubi is missing from the Edubuntu DVD image... guess I'll have to figure out how to fix that
 * micahg wonders when the last chance to rebuild firefox to pick up powerpc for beta 1 would be (guessing late Monday)
<Riddell> micahg: depends how slow the ppc build severs are and how quickly people can test the ppc images
<Riddell> stgraber: needs magic in the ubuntu-cdimage scripts?
<Ampelbein> Hi! I think the upload of guile-pg should be rejected, the package build failure was caused and fixed in guile-1.6, see bug 935161.
<ubot2`> Launchpad bug 935161 in guile-pg "guile-pg version 0.16-5 FTBFS on i386 in precise" [High,Fix released] https://launchpad.net/bugs/935161
<infinity> Ampelbein: Thanks, rejected.
<Ampelbein> infinity: thank you! I mailed angel abad with an explanation.
<NCommander> infinity: alternate image builds seem to be broken; d-cd's deboostrap sanity check fails; python3/3.2{-minimal} isn't getting put on the CDs.
<NCommander> ideas?
<NCommander> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/precise/daily-20120225.log
<tumbleweed> python3 was dumped recently to make space, wasn't it?
<NCommander> tumbleweed: python has a bit of a weird history with the base system
<NCommander> I'm doing a manual respin to make sure it wasn't a transitory glitch, but I'm not hopeful
<tumbleweed> python3 shouldn't, IIRC it was only depended on by lsb
<NCommander> tumbleweed: seems it might have been a transitory hiccup. Didn't explode on a manual spin. Requeing ubuntu-server images now
<Riddell> NCommander: yes we dropped python 3 by changing lsb
<Riddell> so that sanity check needs fixed
<infinity> NCommander: At first guess, I'd assume that no one dropped the archive priority of python3 after dropping it out of the seeded set.
<infinity> NCommander: (since debootstrap only cares about priorities)
<infinity> NCommander: But if it's working now, I guess someone fixed it before I got to it. :P
<stgraber> Riddell: yeah, I guess so, not sure which part of the magic though, I'll have a look at the branches I have here see if I can figure it out
<stgraber> Riddell: cjwatson marked the work item as done so I assumed wubi.exe was already on the Edubuntu DVD image but I guess something's missing somewhere...
<NCommander> ubuntu-server and xubuntu-alternates respun
<NCommander> anyone else need anything respun ATM?
<micahg> Riddell: skaet: should I add a note to the pad about firefox/thunderbird on powerpc?
<Daviey> Ho Ho Hum
<Riddell> micahg: can't you just e-mail both our powerpc users?
#ubuntu-release 2013-02-18
<psivaa> cjwatson: There are no precise dailies yet after the .2 release. When will they start to arrive?
<cjwatson> psivaa: I hadn't remembered to turn them back on
<cjwatson> psivaa: re-enabled now and I'll edit the process to note this explicitly
<psivaa> cjwatson: ack, thank you
<jamespage> cjwatson, did you see my regression-alert ping re openvswitch?
<cjwatson> Not really, it was the weekend
<cjwatson> I assume the best thing to do is to accept the fix
<jamespage> cjwatson, I think so yes
<jamespage> cjwatson, appreciate it was the weekend; just wondered whether you had noticed this morning :-)
<cjwatson> Vaguely but I had a lot to catch up on :)
<cjwatson> There you go
<jamespage> cjwatson, thanks!
<shadeslayer> hi, I'm trying to setup the auto-upgrade-tester
<shadeslayer> but I get this : http://paste.kde.org/673916/
<shadeslayer> I do have cpuinfo on the host
<shadeslayer> and the host is kubuntu raring
<zequence> stgraber: Hi. Sorry to bother you again with the relase privileges. We decided to create a custom team for it, called ~ubuntustudio-release. The team is owned by ~ubuntustudio-core, and will include smartboyhw. So, if you could move the release privileges over to ~ubuntustudio-release, that would be great.
<xnox> bdmurray: can linux-lts-backport-natty please be part of kernel team on the http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html ?
<stgraber> zequence: ok, I'll do that in a bit
<shadeslayer> okay, I tried using the chrootbackend for auto-upgrade-tester but it still doesn't work, it's stuck at running do-release-upgrade -d -f DistUpgradeViewNonInteractive
<cjwatson> shadeslayer: #ubuntu-quality might know better
<shadeslayer> cjwatson: found the reason, do-release-upgrade expects a ~/.cache folder
<shadeslayer> and that's not present on the chroot that auto-upgrade-tester makes
<shadeslayer> thanks though :)
<cjwatson> shadeslayer: fixed in update-manager bzr now
<shadeslayer> \o/
<shadeslayer> yofel: ^
<yofel> \o/
<shadeslayer> does os.mkdir take into account whether parent dirs were created or not?
<cjwatson> no, it's just a syscall wrapper
<shadeslayer> ah, so that's going to be another issue then
<cjwatson> no
<cjwatson> at least afaics?
<shadeslayer> the tarball doesn't have /home/shadeslayer
<cjwatson> oh
<shadeslayer> the chroot itself has no users afaictl
<cjwatson> I couldn't use a 'mkdir -p' equivalent since .cache needed 0700 perms
<yofel> can't you fix the permissions after creating the folder?
<shadeslayer> but upgrade-tester inherits the env
<cjwatson> yofel: how about I just fix this rather than bikeshedding the details :)
<yofel> cjwatson++
<cjwatson> (I don't want to take your approach since I'd have to take special care about existing directories)
<yofel> ok, as you obviously know more about this than I do I'll be quiet and let you do the work :)
<shadeslayer> hm, so our automatic qa setup is now stalled until the update manager fixes land
<xnox> as per XDG Base directory specification if XDG_CACHE_HOME doesn't exist one should try to create it, and the parent dirs if necessory, making sure they stay at 700 permissions.
<xnox> and it's responsibility of the application to do so.
<xnox> but it would make a life much easier if the userdir skeleton had .config, .local and .cache out of the box.
<cjwatson> yofel: sorted now
<cjwatson> I'll upload u-m
<bdmurray> xnox: done
<xnox> bdmurray: thanks =)
<phillw> hi good people I'm trying to replicate bug 1128597 Using my KVM system, it hangs as "Starting crash report submission daemon" . I can instruct it to shut down and then see if there are logs left. Anyone have any other suggestions?
<ubot2> Launchpad bug 1128597 in ubiquity (Ubuntu) "ubiquity-dm crashed with TypeError in run(): Can't convert 'bool' object to str implicitly" [Medium,New] https://launchpad.net/bugs/1128597
<xnox> phillw: i have a fix locally. one needs to boot with visual a11y kernel argument option.
<xnox> don't worry about it, I will commit a fix in a minute.
<phillw> xnox: thanks, boss. We will be both be happy to test :)
#ubuntu-release 2013-02-19
<slangasek> infinity: hmm, where did we get to on the question of apt being made smarter in handling multiarch libs with cross-arch virtual package conflicts?
<jamespage> please could the openvswitch fixes for bug 1125611 be pushed to updates asap
<ubot2> Launchpad bug 1125611 in openvswitch (Ubuntu Quantal) "DKMS brcompat module circular dependency causes broken module" [Critical,Fix committed] https://launchpad.net/bugs/1125611
<jamespage> I know we normally do the 7 day settle
<cjwatson> jamespage: can you verify bug 1088160?
<ubot2> Launchpad bug 1088160 in openvswitch (Ubuntu Quantal) "module-assistant install of openvswitch-datapath fails on quantal due to drop of _mod postfix" [Medium,Fix committed] https://launchpad.net/bugs/1088160
<jamespage> cjwatson, doing it now
<jamespage> cjwatson, done
<cjwatson> jamespage: Thanks - released
<jamespage> cjwatson, ta
<infinity> slangasek: I think Colin suggested perhaps fiddling with resolver weights to make real packages less important, but I'm not sure we "got" anywhere, per se.  We identified the (obvious) misbehaviour, but not a solution.
<cjwatson> I think I also suggested Debug::pkgProblemResolver=1 as the next step
<phillw> cjwatson: are you about?
<rtg> infinity, do you know the name for the 12.04.2 desktop and server seeds ? I wanna find out for sure what kernel meta-packages were used.
<infinity> rtg: If you want to know, you don't want the seeds (they change over time), you want the actual ISOs.
<infinity> rtg: Nothing other than the ISO is "12.04.2", the archive moves on.
<infinity> rtg: http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-desktop-amd64.manifest
<rtg> infinity, surely the current seed is still the same ? I'll check the manifest.
<infinity> rtg: I haven't changed the current seed.  On the other hand, the seeds only dictate d-i images.  Desktop/live images don't pull by ABI at all.
<infinity> rtg: My point was that I'll be changing the seeds soon, and the images are the only authority on what made 12.04.2
<slangasek>  * Signed-Kernel-Stem: linux-signed linux-signed-image
<slangasek>  * ${Signed-Kernel-Stem}-generic-lts-quantal [amd64]
<slangasek> that's what's in the live seed
<rtg> infinity, so the issue is that linux-generic-lts-quantal was used as the meta-package. I was sure I had a bug open with a 12.04.2 milestone to make sure linux-image-hwe-generic was used.
<slangasek> which I think is probably what you're actually interested in
<infinity> rtg: Oh, fun.
<rtg> right, gonna make rolling forward awkward
<infinity> rtg: Not awkward if we just make lts-quantal depend on the next big thing later.
<rtg> infinity, correct, but that is going to be exception wrt to our kernel process.
<rtg> exceptional*
<infinity> See /msg
<utlemming> infinity: who might I ping over a neglected SRU? I put one in nearly two weeks ago, and it has sat with out any love.
<infinity> utlemming: Possibly me.
<utlemming> infinity: Bug #1111690 is the one.
<ubot2> Launchpad bug 1111690 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent IsPackaged() logic is broken, runs two instances of waagent" [High,New] https://launchpad.net/bugs/1111690
<infinity> utlemming: Ahh, the "ignoring" there is that no one uploaded it, yes?  You probably wanted ubuntu-sponsors subscribed for that to happen.
<infinity> utlemming: I can look at it, though.
<phillw> infinity: did you see the fix for bug 1128597 pass today? the little critter is still there.
<ubot2> Launchpad bug 1128597 in ubiquity (Ubuntu) "ubiquity-dm crashed with TypeError in run(): Can't convert 'bool' object to str implicitly" [Medium,In progress] https://launchpad.net/bugs/1128597
<utlemming> infinity: :) oh, I missed that part
<infinity> phillw: xnox said he'd commit a fix, didn't he?  These things aren't instant.
<phillw> infinity: (23:35:53) xnox: don't worry about it, I will commit a fix in a minute.
<infinity> phillw: Yes, I see that you posted that in the bug log an hour ago.
<phillw> as it stopping lubuntu desktop amd64 even trying to install, I had hoped it would be in for the next spin... :/7
<phillw> infinity: I was expecting a fix-released, so thought it would be in todays automatic re-spin. Hence my only now commenting on the bug. I thought it had been 'nailed to the cross' and vanquished.
<infinity> phillw: There's a branch linked to the bug.  xnox hasn't merged it and uploaded yet, hence it's not Fix Released.  Patience.
<phillw> infinity: okies, boss! Just that we cannot test the ISO's affected. :)
<slangasek> xnox: bug #1128597> doesn't look like the fix has been committed yet; you think you'll get to it yet today?
<ubot2> Launchpad bug 1128597 in ubiquity (Ubuntu) "ubiquity-dm crashed with TypeError in run(): Can't convert 'bool' object to str implicitly" [Medium,In progress] https://launchpad.net/bugs/1128597
<infinity> utlemming: Uploaded backports for P and Q for that bug.
<utlemming> infinity: awesome, thank you. I'll get to verifying those asap
<infinity> utlemming: Well, someone needs to accept them still.  But, if you verify my diffs match what you expect, I can self-accept, since it was basically your upload.
<utlemming> infinity: ack
<infinity> utlemming: Want to poke those in the queue and see if they're what you expect?
<utlemming> infinity: yeah, I'm looking at the queue now...still pending
<utlemming> infinity: I see the precise one, and its good, but I haven't seen quantal enter the queue
<infinity> utlemming: It's in unapproved.
<infinity> utlemming: You're probably looking at new.
<infinity> (They should be identical except for changelogs anyway)
<utlemming> infinity: and that one looks good
<utlemming> infinity: so the uploads both look good
<infinity> utlemming: Alright, will accept in a sec.
<phillw> infinity: I'm sorry to be a pain, but bug 1111690 is showing as
<phillw> Â Launchpad.netNot allowed hereSorry, you don't have permission to access this page or the information in this page is not shared with you.You are logged in asÂ Phill Whiteside.
<ubot2> Launchpad bug 1111690 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent IsPackaged() logic is broken, runs two instances of waagent" [High,Fix committed] https://launchpad.net/bugs/1111690
<phillw> I'm just trying to show some new comers about a bug being fixed and released, with the bug status being updated....
<infinity> phillw: It's not a private bug... If it was, the bot wouldn't be able to read it.
<infinity> phillw: Are you sure you didn't mistype it?
<SergioMeneses> hello infinity but I have the same issue
<infinity> https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1111690
<ubot2> Ubuntu bug 1111690 in walinuxagent (Ubuntu Quantal) "[SRU] walinuxagent IsPackaged() logic is broken, runs two instances of waagent" [High,Fix committed]
<infinity> ^--- That doesn't work for you?
<cjwatson> Apparently it's due to a private blueprint link
<SergioMeneses> infinity, no
<infinity> cjwatson: That's... Silly.  Really?
<cjwatson> The bug itself is public and information on it can be retrieved over the API
<SergioMeneses> it says: not allowed here
<cjwatson> But if you try to render the whole thing you hit the private bp
 * infinity just unlinks it.
<infinity> SergioMeneses: Better now?
<cjwatson> It really ought to, I don't know, just not render the bp link or something
<infinity> Ideally, yes.
<phillw> infinity: it allows access now,
<SergioMeneses> infinity, perfect!
<phillw> just something I was not expecting on a progress of a big.
<phillw> *bug*
<phillw> cjwatson: and infinity can we safely leave that 'bug' about the 'private bp' for you to sort out. I have inadvertantly picked a wrong bug to follow 'live'.
<infinity> phillw: It's unlinked from the blueprint now, should be fine.
<phillw> infinity: what is is this linking? I'm about up to speed on bugs being made private, but not for one vanishing with such a report.
<infinity> phillw: Bugs can be linked to blueprints.  When they are, the bug page shows a link to the blueprint.  If the blueprint is private, that causes the whole bug page to go kaboom.
<infinity> phillw: It's a misfeature, to be sure.  As Colin says, it should probably just not render the link.
<phillw> infinity: in the case of 'general bugs' going private, it is asked that they ask the bug-team. In this rare case, should they ask here?
<cjwatson> no.  probably #launchpad or something
<cjwatson> #ubuntu-release isn't generally a sensible bug escalation channel
<cjwatson> we've just occasionally used it as such for image showstoppers around release time
<phillw> cjwatson: and what should they inform them of? I know ubuntu-release is not the correct channel. You guys and gals have enough on your plate!
<phillw> Having the correct procedures in place means we can tell people 'where to go' (Which I'm sure you would like to tell me often :) )
<cjwatson> I can't give you a general answer to that because it sort of depends exactly what the problem is; I'm not prepared to state that all mysteriously private bugs are due to the same problem!
<cjwatson> somebody is going to have to work out that the bug appears to be private to the web UI and yet public over the API (e.g. to the bot that generates pending-sru.html)
<cjwatson> In general this sort of thing is likely to need somebody who at least moderately understands LP to apply a degree of creative thinking
<infinity> Or, at the very least, someone who can see the bug.
<cjwatson> I'm sure somebody in #ubuntu-bugs can be found who can manage that
<cjwatson> (Or similar channels)
<phillw> cjwatson: so, would it be reasonable to ask them to head to https://wiki.ubuntu.com/Lubuntu/Testing#My_Bug_went_Private
<cjwatson> that doesn't look like a sensible URL for general advice on these matters
<cjwatson> unless it's specifically for Lubuntu people
<cjwatson> But sure, the advice there is fine
<phillw> yeah, ditto. Thanks guys, I'll get things updated cjwatson it was the link as to where to go I was referring to :)
<cjwatson> #ubuntu-bugs may not be able to resolve everything but they should at least know whom to ask
<phillw> again, thanks. I'll leave you good people in peace. Just send out a hunting party for xnox :D
#ubuntu-release 2013-02-20
<xnox> why a hunting party?
<infinity> xnox: Because he really wants a bug fixed, apparently.
<infinity> xnox: 1128597
<xnox> infinity: well there is a branch attached to the bug already. It's just I happened to fix a few other things around there, while I was there and still testing will propose/merge tomorrow and we will do a ubiquity upload soon as we have a few fixes already.
<phillw> xnox: I do hope you have a sense of humour, if not.. I apologise.
<phillw> xnox: will these fixes be in the next re-spin?
<phillw> aka auto cron buikd
<phillw> *build
 * cjwatson sorts out the image build failures
<cjwatson> stgraber: OK, we'll start getting daily-checks mail about precise now too
 * cjwatson remembered to deploy
<cjwatson> slangasek,Riddell: are Kubuntu daily builds meant to still be commented out?
<cjwatson> (and Kubuntu active)
<Riddell> cjwatson: mm, no
<doko> https://launchpad.net/ubuntu/+source/zipl-installer/0.0.22 doesn't have any build records. why?
<doko> ahh, s390 only
<cjwatson> feel free to remove that source; it won't be autosynced any mre
<cjwatson> *more
<cjwatson> since the autosyncer is smart about this now
<cjwatson> Riddell: OK, re-enabled, thanks
<cjwatson> doko: you'll probably need to explicitly remove from both raring and raring-proposed
<Riddell> cjwatson: where should I start on getting nexus images for kubuntu-active made?
<Riddell> poke ogra?
<cjwatson> Riddell: talk to ogra, yeah
<doko> cjwatson, so no need for black-listing?
<cjwatson> doko: no
<doko> ok
<cjwatson> doko: most of the time you don't need to blacklist things any more
<ogra_> Riddell, is end of the week ok ?
<Riddell> ogra_: sure
<ogra_> we have a dedicated builder for n7 images now, thanks to infinity, so we should now be able to do it
<Riddell> ogra_: dedicated builder is a pandaboard or there's a nexus 7 in a datacentre somewhere?
<ogra_> a panda indeed
<ogra_> we dont want to have to send people to the DC to plug in power all 8h :)
<ogra_> (since you cant charge while an USB disk is attached)
<cjwatson> doko: for new sources, auto-sync avoids (a) anything that's blacklisted (b) anything already in NEW (c) anything not built on any architecture in the target distroseries (d) anything where an equal or higher version was already removed from the target (e) anything that was previously published in the target at a lower version (it mails me about these for manual resolution)
<cjwatson> this was enough intelligence to let it run from cron
<apw> ogra_, there are power pads for charging on the side of the N7, not that i know which of the 4 is which
<apw> infinity, you have debian-installed blocked, is that for the .2 or something else
<ogra_> apw, thats a lid switch, not power
<apw> ogra_, there are 4 pads on teh side for the dock, they let it charge and pipe out audio according to the dock spec
<ogra_> oh, i thought it was onlt the lid stuff
<apw> the dock says it charges and does audio and the pictures show it sitting on the side there, nothing in the USB
<apw> so i recon it has to have power in there to make any sense
<ogra_> well, i know that the "jackets" use these connectors for lid open/close events
<ogra_> anyway, happy to hear it can charge through it too
<ogra_> cjwatson, the meta upload will fix the libO uninstallability ?
 * ogra_ was wondering about it 
<cjwatson> ogra_: Yes
<ogra_> great
<didrocks> cjwatson: do you know if the hud it still publishing? I don't see it on the page, seb128 NEWed a little bit more than an hour ago
<cjwatson> didrocks: hmm, good question, it might have been caught by the librarian outage ...
 * cjwatson contemplates how to check
<didrocks> cjwatson: we'll be able to resync it from the ppa in case it's needed :)
<cjwatson> didrocks: Ah, it got rejected due to the librarian outage, and I can't resurrect rejected syncs.  Indeed, can you just sync it again?
<didrocks> cjwatson: sure sure, thanks for checking!
<cjwatson> It must have landed in accepted briefly and then been booted out
<seb128> didrocks, perfect timing :p
<didrocks> seb128: didn't I tell you that sometimes, I feel like the black cat? :)
<didrocks> ok, sounds go have created the metadata in the launchpad page now, thanks cjwatson. I'll promote it in main as soon as I can see the published version (the MIR is acked)
<cjwatson> Whoops.  Sorry for Lubuntu image build failure, fixing
<cjwatson> bzr DTWT when resolving conflicts in an executable
<cjwatson> ... and again
<cjwatson> Looking happier now
<Riddell> kubuntu 12.04.2 works on a secure boot system even though we didn't add any secure boot bits to it, 12.04.1 fails, that's unexpected
<infinity> Riddell: Really?  That's beyond unexpected, if it's an SB system that will only boot things signed with the MS key.
<xnox> Riddell: it may as well be a secure boot machine, maybe it's just UEFI machine where updated UEFI works and older one doesn't?
<xnox> are you sure secure boot is fully enabled and it doesn't e.g. fallback to normal uefi.
<Riddell> xnox: it does say enabled in the firmware settings.  it also doesn't boot 12.04.1 with the message "secure boot failure"
<xnox> ok. i rest my case, sir.
<xnox> Riddell: well, that mean kubuntu has secure boot now \o/
<Riddell> 12.04.1 http://www.flickr.com/photos/jriddell/8492018551
<Riddell> I'm not sure I trust a single data point on this issue
<cjwatson> Riddell: You may find that the image itself boots but it (a) doesn't have a signed kernel so won't work on all systems (b) won't install in such a way as to make a bootable installed system
<cjwatson> I think there's a shim + signed GRUB there unconditionally
<cjwatson> But only on the live image
 * cjwatson fixes another fairly arcane explosion due to the nusakan upgrade
<cjwatson> (Slight lzcat interface change)
<plars> cjwatson: I think we have a problem with the precise netboot images, they don't seem to be installing the 3.5 kernel.
<xnox> infinity: ^
<infinity> plars: Which ones?
<plars> infinity: current ones at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/20101020ubuntu136.9/images/netboot/
<plars> infinity: unless I'm looking in the wrong place, that should be the latest right?
<infinity> plars: Note the quantal-* directories.
<infinity> plars: images/netboot will always be the precise kernel, images/quantal-netboot is the lts-q kernel.
<cjwatson> Yep, what he said.
<plars> infinity: ok, so that's intentional... hggdh we need to teach cobbler to cope with that somehow though
<hggdh> ah
<cjwatson> I did the same for the backports to lucid.
<cjwatson> So if it's broken now it was probably broken then too ...
<infinity> I doubt they cobbled much with lucid.
<plars> cjwatson: yeah, it's just some automated jobs for kernel sru - not sure whether they existed that far back.
<plars> we were not seeing the 3.5 kernel come in with the new precise tests, but the iso seemed right, but we didn't notice that quantal directory
<cjwatson> plars: good sign that you noticed, anyway :)
<infinity> plars: Check.  And for SRU testing, of course, you need to test both.
<infinity> plars: So, good thing we provide two. ;)
<plars> infinity: yes, that's the idea that we want to make sure kernel SRUs are testing for both
<nuclearbob> it looks like the most recent daily live images have the initrd under casper/initrd instead of casper/initrd.lz  Is this intentional, and will the change be permanent?
<cjwatson> nuclearbob: No, I'm already in the process of fixing that bug
<cjwatson> It was a side-effect of upgrading nusakan to precise
<nuclearbob> cjwatson: cool, thanks
<cjwatson> Was wondering whether I'd manage to fix it before somebody noticed ;-)
<veebers> cjwatson: would you happen to have a bug number for that?
<cjwatson> I didn't bother
<cjwatson> Respins are already in progress
<cjwatson> And only a handful of images (albeit including Ubuntu desktop) were affected
<veebers> cjwatson: cool, thanks. How long does a respin take?
<cjwatson> Minutes
<veebers> awesome
<cjwatson> In this case, anyway, since I don't need to rebuild the live filesystem, just the ISO9660 container
<cjwatson> nuclearbob,veebers: 20130220.2 should be visible shortly; I've verified that its file list is back to normal
<nuclearbob> cjwatson: awesome, thanks
<veebers> cjwatson: noice, thanks
<cjwatson> (For the record, the problem was that lzcat's command-line syntax got stricter from lucid to precise, confusing cdimage)
<nuclearbob> that's inconvenient
<xnox> (well it used to be lzma but now it's xz that provides it ;-) )
<cjwatson> Yeah, that wasn't really the issue I think
<cjwatson> Using -S '' was always a bit of a hack
<nuclearbob> hmm, I think I'm using -S ''
<cjwatson> So I wasn't desperately surprised to have to prod it
<cjwatson> lzcat: : Invalid filename suffix
<cjwatson> Really lzcat has a stupid interface and shouldn't require that at all, because it doesn't use the target filename gained by stripping the suffix
<cjwatson> So (at least in raring) you can actually just pass any string as a suffix, AFAICS
<nuclearbob> that's handy
<cjwatson> As it happens I used a chunk from the end of the filename in question, but I think that was overengineered
 * antarus hates releases
<antarus> all the bugs I fixed ended up failing in release verification on weird edge cases :/
<slangasek> why does https://launchpad.net/ubuntu/raring/+source/libreoffice/1:4.0.0~beta2-0ubuntu1 say it's published in quantal?
<cjwatson> *blink*
<cjwatson> Oh, I think that means libreoffice in general is published in quantal and raring
<cjwatson> Daft presentation
<cjwatson> Hm, but https://launchpad.net/ubuntu/raring/+source/base-files/6.12ubuntu1 doesn't do that
<cjwatson> It's from a join between SPR and SPPH, so maybe there are copies into a PPA that are confusing it?
<cjwatson> I don't know, very confused
<antarus> I'm glad I'm not the only one that gets confused
<slangasek> cjwatson: ok
<slangasek> cjwatson: so I'm looking at this in the context of libreoffice-presenter-console, which you appear to have dispatched this morning
<stgraber> cjwatson: https://launchpad.net/~guido-iodice/+archive/testing2/+sourcepub/2986741/+listing-archive-extra ?
<slangasek> it's causing update-manager to display the dreaded 'partial upgrade' dialog and I'm not sure why
<stgraber> cjwatson: basically someone copied the raring build straight to a quantal PPA, then removed it. Could that cause what we're seeing?
<cjwatson> stgraber: Good catch, thanks, that would do it
<cjwatson> slangasek: Yes, I did - is there still some open fallout from that?
<slangasek> cjwatson: it's causing update-manager to display the dreaded 'partial upgrade' dialog and I'm not sure why
<stgraber> cjwatson: google with site:launchpad.net is handy for that kind of search (launchpad's own search engine, not so much ;))
<cjwatson> slangasek: Curious, an apt-get dist-upgrade this morning was pretty clean for me
<cjwatson> I don't suppose it's marked for manual install or something?
<slangasek> cjwatson: well, apt-get dist-upgrade is perfectly happy removing the package
<slangasek> but update-manager is more particular IIRC
<slangasek> cjwatson: remind me how to check the current mark status?
<cjwatson> apt-mark showauto | grep
<cjwatson> some day soon I suppose I'm going to have to actually understand how u-m works
<slangasek> the package is indeed marked manual
<slangasek> which, actually, is the expected behavior since it's an ubuntu-desktop Recommends: (or was)
<cjwatson> It might need to be quirked in u-m
<cjwatson> IIRC there's a list of packages that have been removed ...
<slangasek> hmm yes
<cjwatson> But I thought that was mainly for release upgraes
<cjwatson> +d
<cjwatson> I don't know whether it comes into play for normal u-m runs
#ubuntu-release 2013-02-21
 * slangasek scratches his head.  Why does Debian have a "new upstream release" of update-manager?
<doko> Binary only movements to multiverse
<doko>  -----------------------------------
<doko>  o nvidia-current-updates                {nvidia-graphics-drivers-304-updates}
<doko> ======================================================================
<doko>  Source only movements to multiverse
<doko>  -----------------------------------
<doko>  o nvidia-graphics-drivers
<doko>  o nvidia-graphics-drivers-updates
<doko> they are in restricted now ... is this correct?
<SergioMeneses> doko, I think so
<SergioMeneses> doko, https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia
<infinity> doko: They probably all want to be seeded, like the other nvidia-* junk is, so they can stay in restricted.
 * infinity fixes.
<cjwatson> ScottK: I'm attempting to fix up your plasma-mobile hint.  Looks like it managed to cause britney to crash.
<cjwatson> http://paste.ubuntu.com/1698252/
<cjwatson> Trying binaries is definitely wrong so I've gone back to source packages, only this time spelled correctly (s/plamsa/plasma/).  If that doesn't work I'll try with an explicit version.
<cjwatson> That didn't work.  Trying with a version
<cjwatson> ScottK: That worked now.
<cjwatson> ScottK: Hopefully by the time you see this it should have migrated and you can remove the hint.
<cjwatson> At some point I should really put the logs on the web
<cjwatson> ScottK: I assume you know it (apparently) breaks kubuntu-active, since that was the reason it didn't get auto-migrated ...
<cjwatson> Though it looks OK to me in chdist
<cjwatson> Maybe NBS
<cjwatson> Ah, yes, kubuntu-active Depends: plasma-active-keyboardcontainer which is no longer built
<doko> how do I have to understand https://launchpadlibrarian.net/131958853/buildlog_ubuntu-raring-armhf.binutils_2.23.52.20130221-0ubuntu1_FAILEDTOBUILD.txt.gz
<doko> dpkg-buildpackage: host architecture armhf
<doko> dpkg-checkbuilddeps: Unmet build dependencies: gettext:any
<doko> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
<cjwatson> doko: You shouldn't build-depend on gettext:any any more; I told you this for binutils a few weeks ago
<cjwatson> Just use gettext instead
<cjwatson> (It's M-A: foreign now rather than allowed)
<doko> ahh, I see, trunk build ...
<cjwatson> In fact back in November
<cjwatson> Ah, yes, and you acknowledged it immediately, so obviously building some different tree :)
<ScottK> cjwatson: Thanks.  Sorry for the crashing.
<xnox> Can I please have ubuntu & xubuntu, daily-live respun with new ubiquity.
<xnox> ?
<xnox> I want to test it, as I am away tomorrow.
<cjwatson> xnox: on their way
<xnox> thanks.
<jdstrand> infinity: can you kill these: https://launchpad.net/~ubuntu-security/+archive/ppa/+build/4317384 https://launchpad.net/~ubuntu-security/+archive/ppa/+build/4317385
<davmor2> cjwatson: is there an issue with 64bit?  https://pastebin.canonical.com/85263/
<davmor2> meh sorry I though I hit paste.ubuntu :(
<stgraber> davmor2: appears to be working here
<stgraber> davmor2: maybe you were unlucky and tried while the image was half-mirrored?
<davmor2> ah yeap working now thanks
<davmor2> stgraber: wouldn't surprise me
<pgraner> cjwatson, rickspencer3 is saying he's getting partial upgrades today with update manager do we have some broken pkgs?
<cjwatson> slangasek noticed something yesterday with libreoffice-presenter-console
<cjwatson> (which is supposed to be removed)
<cjwatson> I haven't seen a debugging trace as yet)
<cjwatson> unfortunately I upgraded my own system across that using apt-get and all was fine
<pgraner> cjohnston, hmmm, strange he had issues yesterday with that package, I'm wondering if is residual from that?
<slangasek> cjwatson: it removes fine under apt-get; u-m refuses to remove any packages in upgrade mode; there's a bug report from mvo that previously proposed the solution for this (bug #1038113)
<ubot2> Launchpad bug 1038113 in update-manager (Ubuntu) "support conflicts/provides/replaces and allow removal in this case" [High,Triaged] https://launchpad.net/bugs/1038113
<cjwatson> OK, so for now the correct answer is to use apt-get as we're going to need an update to deliver an upgrade-manager fix anyway
<cjwatson> I guess this needs to be fixed in UpdateManager.Core.MyCache.saveDistUpgrade ...
 * cjwatson targets that bug so that it goes onto the foundations list
<infinity> jdstrand: More openjdk builds?
<infinity> jdstrand: Oh, did you copy to your PPA from doko's before the builds were all done, is that what this is about?
<jdstrand> infinity: re copy> yes
<infinity> jdstrand: Oops. :)
<jdstrand> yeah, just 11.10. I thought it had a green check. I was wrong
<phillw> cjwatson: can I also request lubuntu desktop
<phillw> +be respun with new ubiquity.
<cjwatson> phillw: It already has been.  20130221
<cjwatson> i.e. the one from cron.
<phillw> cjwatson: thanks, just zsyncing up now :)
<phillw> I take it that xubuntu one got cron built before the new ubiquity landed? it shows as 20130221.1
<cjwatson> Yes
<cjwatson> 50 9 * * *      buildlive xubuntu daily-live && for-project xubuntu cron.daily-live
<cjwatson> 35 1 * * *      buildlive lubuntu daily-preinstalled && for-project lubuntu cron.daily-preinstalled
<cjwatson> Er ignore that second one
<cjwatson> 29 16 * * *     for-project lubuntu cron.daily; buildlive lubuntu daily-live && for-project lubuntu cron.daily-live
<phillw> again, thanks, I've been checking with xubuntu to ensure such a bug is purely lubuntu.
<bdmurray> I'm looking at the SRU for bug 1060262 and thre is a reference to it being rejected previously due a non SRUable commit.
<ubot2`> Launchpad bug 1060262 in unity-2d (Ubuntu Precise) "Unity-2D SRU-1 needs releasing" [Wishlist,In progress] https://launchpad.net/bugs/1060262
<bdmurray> However, I've no idea what that was and want to make sure it still isn't in there...
<bdmurray> Does anybody remember rejecting it before?
<ScottK> Wasn't me.
<infinity> bdmurray: Doesn't ring bells.
<phillw> Has anyone got any thoughts regarding a new bug 1131427 that was supposed to have been solved via bug 1128597
<ubot2`> Launchpad bug 1131427 in ubiquity (Ubuntu) "ubiquity fail" [Medium,New] https://launchpad.net/bugs/1131427
<ubot2`> Launchpad bug 1128597 in ubiquity (Ubuntu) "ubiquity-dm crashed with TypeError in run(): Can't convert 'bool' object to str implicitly" [Medium,Fix released] https://launchpad.net/bugs/1128597
 * xnox was able to reproduce 1128597 with images 20th or older. And it is fixed with 21.1 and newer.
 * xnox cannot reproduce 1131427 with any
#ubuntu-release 2013-02-22
<phillw> xnox: do you want me try again with xubuntu?
<phillw> xnox: very different splash screen in xubuntu to that I saw in lubuntu.
<phillw> xnox: as in totally different.
<phillw> Hi Guys, my apologies for taking my eye off the ball, but https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674 is still alive and casin g
<ubot2`> Ubuntu bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
<phillw> causing issues for testing
<gema> cjwatson: I see a bootspeed regression on Xorg between the 9th and the 13th of Feb
<gema> cjwatson: who should I talk to about it?
<gema> cjwatson: it's gone from under 6 seconds to over 25
<cjwatson> gema: Start with bryceh/mlankhorst/tjaalton, I guess
<gema> cjwatson: ack
<Laney> aka #ubuntu-x
<gema> Laney: ta x)
<gema> I was trying to find the appropriate channel x)
<gema> cjwatson: pitti has pointed me to bug 1124330
<ubot2`> Launchpad bug 1124330 in whoopsie (Ubuntu) "[raring] Latest whoopsie 0.2.13 slows down boot process by 29 seconds!" [Undecided,Confirmed] https://launchpad.net/bugs/1124330
<gema> xnox: I am seeing that delay in xorg, is that possible?
<gema> xnox: do you have an ETA for this bug?
<robru> seb128, why was unity-lens-friends rejected? also where's qml-friends?
<seb128> robru, not sure about qml-friends, ken did the uploads, I'm just doing the reviews
<seb128> robru, it's not in the queue, maybe he forgot to upload?
<robru> seb128, hmmmmmm
<robru> seb128, that's an important one for the phone...
<seb128> robru, well I guess we will get it in on monday
<seb128> was it needed today?
<robru> seb128, ok
<robru> seb128, I dunno
<robru> seb128, ok, I've uploaded new libfriends and unity-lens-friends into our ppa at https://launchpad.net/~super-friends/+archive/ppa
<seb128> robru, thanks
<robru> seb128, thanks!
<gema> slangasek: ping
<slangasek> gema: pong
<gema> slangasek: we found a regression in bootspeed and believe it to be due to whoopsie, bug 1124330... I just wanted to know if this should be on your radar or on someone else's?
<ubot2`> Launchpad bug 1124330 in whoopsie (Ubuntu) "[raring] Latest whoopsie 0.2.13 slows down boot process by 29 seconds!" [Undecided,Confirmed] https://launchpad.net/bugs/1124330
<slangasek> gema: has the bug been confirmed as present with the latest whoopsie (0.2.14)?
<slangasek> gema: the new whoopsie would also make the installer fail altogether in some cases, which was higher priority; we were hoping that fixing that would also fix the boot speed problems
<gema> slangasek: when did the latest whoopsie land?
<Laney> it wasn't fixed - it was just worked around
<Laney> that makes whoopsie not start if ubiquity-dm is running
<gema> Laney: when did you guys introduce that change?
<slangasek> Laney: no, whoopsie 0.2.14 has a fix for the crash.
<Laney> that's not /the/ crash
<Laney> (at least it's not the one we were having on the N7; certainly fixes a crash in some situations though)
<slangasek> right, it fixes the whoopsie crash - there's still the workaround in place for ubiquity-dm
<slangasek> gema: so the whoopsie crasher fix was in whoopsie 0.2.14, uploaded on the 20th
<slangasek> gema: that's been in the dailies starting 20130221
 * cjwatson fixes Lubuntu build failure
<slangasek> cjwatson: I notice that the http://www.ubuntu.com/getubuntu/releasenotes/12042 redirect points to a release notes landing page; didn't we once upon a time have per-flavor redirects that would be linked from the installer?  or am I hallucinating that?
<cjwatson> slangasek: We still do
<cjwatson> ./tools/add_live_filesystem:109:                                RELEASE_NOTES="http://www.ubuntu.com/getubuntu/releasenotes?os=$PROJECT&ver=${DEBVERSION%% *}&lang=\${LANG}"
<cjwatson> $ GET -E -S http://www.ubuntu.com/getubuntu/releasenotes?os=ubuntu\&ver=12.04\&lang=en | grep ^Location:
<cjwatson> Location: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes
<slangasek> which is the landing page
<slangasek> shouldn't that go to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop ?
<cjwatson> Oh, err, I see what you mean
<cjwatson> Possibly, yeah - I believe ubuntu-website-content is the LP project for bugs on that
<slangasek> ack, will file - thanks
<slangasek> bug #1131911
<antarus> cjwatson: slangasek either of you at SCALE?
<slangasek> antarus: nope
#ubuntu-release 2013-02-23
<slangasek> so I'm wondering if we should revert the whoopsie NM integration
<infinity> slangasek: I've only been half-heartedly following the whoopsie drama.
<infinity> slangasek: Is it pretty much past the point of "we should just effin' fix it" and deep down some "ngh, don't know how" rabbit hole?
<infinity> slangasek: If so, reverting seems sane.
<slangasek> it's clearly still not working right, as it's causing 20s boot speed regressions on some (but not all) systems
<infinity> Oh, so it's basically mountall, part 2. :P
<infinity> (I still get that /tmp thing, you need to step me through some debugging/logging sometime)
<infinity> Of course, when we try to debug it, it won't happen, just to spite me.
<slangasek> there's a workaround in place for ubiquity-dm, but that basically stops whoopsie from running at all in the live env, which isn't what we want either
<infinity> Right.
<slangasek> infinity: do you have a particularly full /tmp, which is a subdir of / rather than a separate mount point?
<infinity> Is there a clear "this version was fine", and no rdep issues with a straight revert?  If so, let's just do it.
<infinity> slangasek: My /tmp isn't a tmpfs, but my / isn't remotely full.
<slangasek> infinity: I think you have the same mountall issue as xnox, which we've tracked down to "wrong message presented when the system is actually busy cleaning /tmp"
<slangasek> full as in "full of stuff", not "out of disk"
<infinity> slangasek: And it's not ever all that full.  Maybe a few unpacked trees from aborted debdiffs here and there.  But then it does the "waiting 30s" thing, which is excessive, if the cleaning only takes 5.
<slangasek> infinity: there definitely is a "this version was fine" whoopsie - though given that there are other bug fixes intertwined, I'm inclined to revert just the libnm part
<slangasek> waiting 30s?
<slangasek> I don't know anything about that one
<infinity> slangasek: If the feature revert is clear and obvious to you, go for it. :)
<infinity> slangasek: As for mountall, yeah, it seems to just go into a timeout loop.  But this is all unscientific, I've not bootcharted or logged in any meaningful way, just watched it sit there for a $very_long_time that feels like an artificial delay.
<slangasek> hmm
<infinity> Cause if it was just waiting on an rm -rf, I'd expect it to flash the message for a few seconds, then carry on.
<infinity> And it's much, much longer than that.
<slangasek> infinity: well, you could try building from lp:ubuntu/mountall and see if the message goes away; that's the fix for xnox's bug
<slangasek> (committed, not yet uploaded)
<infinity> Sure.  I'll have to do a few reboots here first and make sure it's still reproducible, and see how often.
<infinity> So I have some data going into the test.
<infinity> I reboot, like, once a month, so my data's a bit suspect.
<infinity> (Uptime on laptops has become ridiculous since we actually started suspending and resuming properly...)
<infinity> slangasek: Anyhow, sorry to sidetrack.  If the feature revert is clean, clear, and obvious, JFDI, IMO.  If not, a full version revert might be sane to at least have things not borked over the weekend, and it can be revisited on Monday.
<slangasek> ack
<slangasek> I'm having a quick scan over the whole diff to make sure it is a severable change
<infinity> slangasek: Before I go deep into trying to sort out this mountall business, it wouldn't be weirdly confused by this bit in my fstab, would it?
<infinity> schroot        /var/lib/schroot/union/overlay/            tmpfs   size=75%          0       0
<infinity> Like, it doesn't seem tmpfses and just have a crazy?
<slangasek> it doesn't just have a crazy
<infinity> s/seem/see/
<infinity> Check. :)
<slangasek> it does automount them, and consider the "virtual filesystem" stage not done until they're all mounted
<cjwatson> fixed cdimage.germinate, rebuilding the images that failed due to that
<ogra_> heh
 * ogra_ just discovered it 
<cjwatson> ogra_: cdimage is up to nearly 3000 lines of Python now (and another >3000 of tests); it'd have been surprising if none of it was broken ...
<cjwatson> I think I'm ready to tackle build-image-set next
#ubuntu-release 2014-02-17
<darkxst> anyone able to bump the gjs binaries through NEW?
<infinity> darkxst: Lemme look.
<infinity> darkxst: Sorry, been crazy distracted with this ppc64el ABI bump and emergency world-rebuild.
<darkxst> infinity, thanks!
#ubuntu-release 2014-02-18
<psivaa> cjwatson: infinity: Don't see precise images since .3 release. Not that i need them but in case anyone looking at the dashboard was curious
<cjwatson> psivaa: Oh, I forgot to turn the cron jobs back on.  Done now
<psivaa> cjwatson: ack, thanks :)
<mlankhorst> can I copy libxcb 1.10 back to precise? :P
<mlankhorst> the diff is awful, but mesa 10 / xorg-server 1.15 need it.
<Riddell> "Builds: Kubuntu Desktop amd64 [Precise 12.04.4]" what's that about?
<Laney> Looks like the milestone didn't get marked as released, so new builds are going there
<xnox> Riddell: precise-daily started to be built, but the iso tracker didn't archive the milestone probably.
 * Laney WINS
<xnox> cjwatson: stgraber: can you mark 12.04.4 as released on the tracker?
<Laney> no need to ping them, anyone on the team can do it
<xnox> Laney: which team is that? ubuntu-release?
<Laney> yeah
<Laney> done
<Laney> Not quite sure how to wind back the kubuntu publication though
<jamespage> is there a reason why http://cdimages.ubuntu.com/releases/12.04.4/release/ does not have -server images?
<Laney> jamespage: because they're on http://releases.ubuntu.com/12.04.4/
<jamespage> Laney, sorry - I knew I was being stupid
<Laney> not stupid, it's not entirely obvious
<jamespage> Laney, next question - if I want an original 12.04.0 iso where can I find that?  I just got asked and could not find it
<Laney> jamespage: http://old-releases.ubuntu.com/releases/precise/
<Laney> Dunno why .3 isn't there, mind
<jamespage> Laney, ta
<Laney> c_jwatson tried to push it there the other day, but apparently it didn't work
<Laney> bah
<Laney> edubuntu got touch stuff again
<stgraber> what a surprise...
<Laney> indeed
<seb128> Laney, when was the iso rolling? maybe the u-c-c versioned recommends issue we discussed this morning
<Laney> it might be, i'm checking
<Laney> doesn't have system-settings, so probably not
<stgraber> Laney: feel free to just respin if you want to be sure. If you want a quick rebuild, respin only amd64, it's considerably faster than i386 to build (as it doesn't need to build 3 livefs images :))
<Laney> stgraber: yeah, will do, as I don't see the problem when running germinate manually
<jibel> cyphermox_, does one of the test changes network-configuration?
<jibel> *network configuration
<cyphermox_> jibel: it's possible yes. good point
<cyphermox_> I only just added tests, so it wasn't noticed before
<cyphermox_> I'll make it "breaks-testbed"
<cyphermox_> or whatever the tag for this might be
<Riddell> ahem
<seb128> slangasek, hey, do you plan to ask for an equivalent of https://bugs.launchpad.net/ubuntu/+bug/1208989 for trusty?
<ubot2`> Launchpad bug 1208989 in Ubuntu "[FFe] standing freeze exception for Ubuntu Touch-specific packages" [Undecided,Confirmed]
#ubuntu-release 2014-02-19
<tjaalton> doko_: I've uploaded a new xmlrpc-c but without the buildflags trickery, hoping that those won't be needed anymore. if it breaks on !x86 I'll add something back that fits the new d/rules
<tjaalton> migrated it to dh, it builds fine against the default flags
<tjaalton> still waiting for seanius to be announced MIA...
<zequence> Hi. Before FF, I'd very much like to have ubuntustudio-live uploaded (a new package that will replace ubuntustudio-live-settings). Should I go through MOTU? bug: 946591
<ubot2`> Launchpad bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<infinity> zequence: If you don't find a victim^Wsponsor before I wake up tomorrow, poke me and I'll help out.
<zequence> infinity: Thanks :)
<tkamppeter> Can someone tell me why gutenprint 5.2.10~pre1 did not make the transition from trusty-proposed to trusty? I uploaded ~10 other packages today which all made the transition.
<Laney> tkamppeter: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gutenprint
<cjwatson> https://launchpad.net/ubuntu/+source/gutenprint/5.2.10~pre1-0ubuntu1/+build/5615671
<tkamppeter> Laney, is the problem that it does not build on PowerPC?
<cjwatson> Correct
<tkamppeter> Does it mean that this new version needs to be fixed on PowerPC before FF?
<cjwatson> It needs to be fixed soon, not necessarily before FF
<cjwatson> But ideally
<tkamppeter> cjwatson, can it be put into trusty manually without the PowerPC fix?
<cjwatson> No.
<cjwatson> I mean it can but I won't.
<cjwatson> We don't regress architecture support unless there's no other choice.
<cjwatson> And in this case it would have fallout, so I wouldn't be happy with regressing that.
<xnox> tkamppeter: the byte_order macros look wrong... let me propose a patch.
<Daviey> cjwatson: Whilst I entirely support that model, I thought the effort to keep powerpc as a first class arch failed?
<cjwatson> proposed-migration's policy is entirely independent of which architectures are supported/first-class/whatever.
<cjwatson> It applies to all architectures.  If you've built before, you have to keep building.
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<xnox> tkamppeter: is it just not the case of missing brackets and semicolon as the compiler error says? http://paste.ubuntu.com/6960742/
<Daviey> Yes, I get that.. I just thought that was being undone for powerpc.
<xnox> tkamppeter: let me try to build it on powerpc.
<Daviey> (anyway, it's good :)
<xnox> Daviey: sure, but missing ";" and mismatched ")" say a lot about code quality, doesn't it?! =)
<cjwatson> No, powerpc not being a first-class architecture long predates proposed-migration even existing; and I don't think it would be overall beneficial to unapply that policy for powerpc.
<xnox> Daviey: especially for something in main.
<Daviey> Agreed
<cjwatson> We can override it in special cases by removing the binaries for powerpc, if there's just no chance of that architecture continuing to be supported for a given package.  But I'm generally reluctant to do that for anything with reverse-dependencies on that architecture, and certainly not when it's just a case of nobody having put even minimal effort into fixing it yet.
<mlankhorst> what about arm64? :P
<mlankhorst> seeing how long the build queue is
<xnox> mlankhorst: only regressions block... and it's reasonable to not regress.
<cjwatson> It backs up occasionally, but not severely enough to consider it "not keeping up".
<cjwatson> Particularly since arm64 is not exactly an architecture we can decide not to care about.
<mlankhorst> sure I can, I'll still try to keep it building though
<tkamppeter> xnox, it cannot be simply missing brackets as it builds on other architectures. Perhaps missing macros for PowerPC?
<xnox> tkamppeter: yes, it can be just that. cause brackets are missing on bigendian code-path.
<xnox> tkamppeter: out of all ports, powerpc is the only one bigendian that we have.
<xnox> tkamppeter: tested on a debian powerpc porter box, and it is just missmatch parenthesis and missing semicolon.
<xnox> tkamppeter: uploaded.
<xnox> tkamppeter: can you upstream the patch? or where do i submit it?
<tkamppeter> xnox, post on the Gutenprint mailing list, https://lists.sourceforge.net/lists/listinfo/gimp-print-devel, Gimp-print-devel at lists dot sourceforge dot net
<tkamppeter> xnox and thank you for yopur quick fix.
<xnox> tkamppeter: no worries, although i thought infinity already fixed one of the printing packages with a missing )); before.
<tkamppeter> xnox, thank you very much.
<bdmurray> it looks to me like pd-aubio should be sync'ed from debian (it was split out aubio) and multimedia-soundsynthesis depends on it.  Is that correct?
<rbasak> I've been waiting all day for a bunch of no-change rebuilds in universe on arm64 to free up migrating php5 past -proposed. The queue doesn't seem to be getting shorter. I presume these builds are getting trumped by arm64 main builds? I'm not sure I've got all the packages (at least two remaining). Will there be any issue with feature freeze here? No features on the rebuilds I suppose; just the new php5 itself is a feature.
<stgraber> since it's already been uploaded and just stuck in proposed, that shouldn't be a problem
<rbasak> OK, thanks.
<cjwatson> rbasak: Sorry, some of that is probably my fault - I was going through the auto-sync dry-run report looking for obvious and reasonably safe syncs of RC bug fixes and such
<rbasak> cjwatson: no problem. I guess they'll get built in the end. You already helped enough unsticking it yesterday.
#ubuntu-release 2014-02-20
<xnox> interesting, who uploaded that =)
<zequence> Would anyone like to help sponsor this package, please? Bug: 946591
<ubot2`> Launchpad bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<zequence> infinity: Not having much luck finding a sponsor yet. The source should be easy to review. Most of the changes I've done are naming, and removal of files I don't need (just now, anyway). bug: 946591
<ubot2`> Launchpad bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<zequence> infinity: What I just wrote makes sense if you know it's a fork of edubuntu-live, but that of course becomes apparent once you have a look at the source
<rbasak> I'm still working on fixing zeroc-ice (universe), which is the last package holding the php5 transition in trusty-proposed. It's got stuff hardcoded, hence the delay, and a test build takes forever. So it might not be until tomorrow. Is this an issue for feature freeze?
<cjwatson> rbasak: I wouldn't worry too much about FF for that
<cjwatson> Don't rush for it :)
<cjwatson> Esp if it's nearly done
<rbasak> OK. Thanks. Although I've just noticed. doko: you've done it?
<cjwatson> I expect we'll be spending a lot of time going through the -proposed backlog after FF
<jamespage> if there are any SRU team folk around - please could the NEW packag for bug 1262225 be reviewed for acceptance into precise-proposed
<ubot2`> Launchpad bug 1262225 in openvswitch (Ubuntu Precise) "openvswitch 1.4.6 is not compatible with the 3.11 saucy HWE kernel" [High,Triaged] https://launchpad.net/bugs/1262225
<Sarvatt> for the mesa thats in NEW would it be possible to put the new package (libvdpau1-drivers-mesa) in universe?
<jamespage> infinity, slangasek, bdmurray: any chance one of you guys could review my request above?
<bdmurray> jamespage: I'll have a look at it
<jamespage> bdmurray, thanks
<slangasek> jamespage, bdmurray: accepted
<slangasek> (sorry, had queued it up for looking while on a call)
<bdmurray> slangasek: do you know why openvswitch seems to be in -updates and -proposed?
<bdmurray> https://launchpad.net/ubuntu/+source/openvswitch/1.4.6-0ubuntu1.12.10.2
<arges> bdmurray: not sure why it tried to sync and blamed me
<infinity> bdmurray: Things don't get automatically removed from -proposed when they're copied to updates, we clean them up manually, based on the output on pending-sru.html
<infinity> bdmurray: I'll tidy right now.
<bdmurray> infinity: okay, any idea why there is a synaptiks sync request in the precise-proposed queue? I just released that version for precise
<bdmurray> arges: did you run sru-release?
<infinity> bdmurray: Blame arges, it's his queue item. :P
<infinity> bdmurray: Anyhow, just reject it.  Looks like someone messed up. :P
<infinity> Same for the openvswitch sync in there.
<infinity> Also done by arges...
<bdmurray> infinity: well if he was using sru-release perhaps it should behave differently
<infinity> arges: If you're doing copies to -updates, please stop. :)
<bdmurray> infinity: he's working with me to be an SRU team member
<infinity> bdmurray: It behaves just fine.  It performs a copy.  And if you don't have the permissions to auto-approve, it'll land in the queue.
<infinity> bdmurray: Oh, if you're training him up for SRU, cool.  But until I add him to the team, he has no queue admin permissions.
<bdmurray> but why should it land in the queue?
<arges> infinity: i'm not
<infinity> bdmurray: Nothing wrong with the tool there, or LP, they're working as designed.  So, while training, you can get him to run sru-release and then you can manually accept his syncs.
<stgraber_> bdmurray: that's what happens if anyone attemps a direct copy to -updates
<bdmurray> infinity: okay
<infinity> bdmurray: Anything uploaded by someone who can't auto-approve will land in the queue.
<arges> infinity: oh so if I run the tool locally it actually modified things?
<arges> i thought it errored out because of permissions
<infinity> arges: No, you have the permissions to do the copy, just not to ACCEPT the copy.
<arges> ah
<infinity> A subtle, but important difference.
<stgraber> infinity: if you have a minute, mind going through those lxc binNEWs? I'd hate for another distro to beat us to having LXC 1.0 in the archive ;)
<arges> infinity: got it. I'll work with bdmurray to do this properly. I'll run that tool with -n to start.
<arges> sorry about that
<infinity> stgraber: Haven't you heard?  We're removing LXC from the archive because Lennart thinks it's the wrong approach.
<infinity> (And someone else must have just done the binNEW review...)
<stgraber> infinity: well, then I guess we can just wait for him to merge a kernel and libc in systemd, then we can just do: rm -Rf /srv/ftpmaster.internal/ubuntu/pool/*/*/[!systemd]/*
<stgraber> all those packages and dependencies and upstreams, it's so complicated when we can just merge everything into a single git tree and release one massive blob every once in a while ;)
<infinity> stgraber: I look forward to changing glibc's SONAME from libc.so.6 to systemd-libc.so.1
<stgraber> infinity: he'd probably go with something like bionic just because that's different and looks cooler ;)
<stgraber> (who needs a fully working libc anyway...)
<infinity> stgraber: I'd be surprised if systemd didn't have a hard dep on glibc features.
<seb128> can we get arm64 builders?!
<infinity> seb128: Some day. :(
<seb128> everything is delayed by hours on arm64 today
<infinity> Yeah, the feature freeze flood hurt.
<infinity> Oh, also, twombly is sick.  Let me fix that.
<seb128> thanks
<infinity> ... after I remember which PDU it's connected to.
<infinity> seb128: Alright, twombly's back, queue should clear soonish.
<seb128> infinity, thanks
#ubuntu-release 2014-02-21
<Riddell> I can't help feeling there should be a feature freeze announce, should I send one out?#
<Laney> Riddell: Probably a reasonable idea, I didn't hear any different
* Laney 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
<Riddell> Laney: how is this? http://pad.ubuntu.com/release-team
<Laney> Riddell: bah, got to find a 2fa thingy
<Riddell> a what?
<infinity> Riddell: Looks fine to me.
<infinity> Riddell: Certainly a lot less verbose than my announcements usually are. :)
<infinity> (Which isn't a bad thing, I just talk too much)
<infinity> Riddell: Bonus points for the not-so-subtle Scottishism in there, too. :P
<Riddell> it's always been my ambition to use "beasties" in an announcement
<infinity> Riddell: If you send that out to u-d-a, I can approve it.
<Riddell> infinity: sent
<Laney> luverly
<Laney> all the wee and not so wee beasties
<infinity> Riddell: Accepted.
<tseliot> can an admin reject nvidia-prime from precise-proposed please?
<Beret> j #allura
<tseliot> admins: false alarm nvidia-prime is ok, no need to reject it
#ubuntu-release 2015-02-16
<elfy> infinity: so ... looks like whatever happened to our trusty has happened with vivid as well :(
<darkxst> elfy, but vivid uses tasks to build the images
<elfy> darkxst: I'm afraid I don't understand that - all I know is *we* don't want ibus and are certainly not wanting unity-greeter ;)
<darkxst> elfy then something else must be pulling them in
<darkxst> as opposed to be being cause by building images from metapackages
<elfy> could be - all I know is I'm critically failing my images :)
<darkxst> elfy, you use lightdm with a custom greeter?
<darkxst> elfy this line in lightdm/debian/control seems wrong
<darkxst> "unity-greeter | lightdm-greeter | lightdm-kde-greeter"
<darkxst> I suppose the middle one should be lightdm-gtk-greeter (that is what you use?)
<ochosi> indeed
<ochosi> if that pulls in unity-greeter then i guess that explains a lot of the indicators and unity stuff that's being pulled in
<darkxst> ochosi, yes, I think unity-greeter would pull in the indicators, and then most likely ibus as well
<seb128> that's not a typo
<seb128> the lightdm-kde-greeter one seems buggy though
<darkxst> seb128, there is no lightdm-greeter in vivid though?
<seb128> the "lightdm-greeter" is a provide from the individual greeters, maybe some are missing that though? then the usual way is to use "the-preferred-alternative | virtual"
<seb128> unity-greeter provides it, I didn't look at the others
<seb128> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/lightdm-gtk-greeter/vivid/view/head:/debian/control#L18
<seb128> same^
<darkxst> fair enought, then its something else
<DalekSec> There's been seed changes recently, fix should have been pushed.
<mdeslaur> infinity: xorg in trusty-proposed never got promoted, and it's required for the backport stack to work
<ochosi> Laney: we talked a longer while ago about the borked 14.04.2 xubuntu image (pulling in a lot of unity, parts of gnome too). while the issue in 14.04 was never solved (and 14.04.2 has been delayed), the same issue has resurfaced in 15.04 daily
<ochosi> from our team nobody was able to uncover the source of the issue (DalekSec tried and Noskcaj looked as well)
<Laney> ochosi: I don't know what the issue in 14.04 is, infinity seemed to be on it so I stopped looking
<ochosi> oh ok
<infinity> ochosi: Whatever's broken in vivid has nothing to do with that I'm fixing in trusty.
<wxl> oh noes :(
<elfy> infinity: thanks - the search will go on
<elfy> hi - id there's someone here from -release with admin rights on the mailing list - there's one obviously from me - copy of one I sent from the right address - can you delete that one please - thanks and sorry :)
<cjwatson> elfy: done
<elfy> cjwatson: thanks, it should have been pretty obvious which if there was more than one :)
<cjwatson> The other had already made it to the list proper.
<elfy> aah cool - thanks :)
<elfy> that'll keep Laney of my back for a bit :)
<wxl> infinity: since tomorrow's the tuesday before trusty's release,a re we ready to start testing yet or is the metapackages thing still all messed up?
#ubuntu-release 2015-02-17
<infinity> wxl: I'm going to spin up new RCs for everyone tonight after I get my last livecd-rootfs tweaks tested and in place.
<wxl> infinity: kthx
<elfy> infinity: awesome sauce
<wxl> vivid's being funky too it seems, but we'll gross that bridge later âº
<elfy> I'll be up and about earlier UTC and will be able to see how our's look asap
<elfy> wxl: I'll cross it instead if you don't mind - my days of gross are long gone :p
<wxl> elfy: argh, you know what i meant. i was typing with one hand
<wxl> infinity: tonight = what in utc?
<elfy> wxl: tomorrow for you I guess - why not just tell your people to look for change in image name on tracker if you're going to be asleep?
<elfy> because the time is likely to be when it's done :)
<wxl> so evening utc tuesday then elfy ?
<elfy> wxl: dude I don't know
<elfy> if I have to mark it not ready then that's what I'll do - but as long as I can smoketest the image I suspect I won't
<elfy> I'll just make it plain in release notes
<infinity> wxl: Tonight meaning late for me, in North American time.  Still need to work the last kinks out of myth, studio, and kylin, and then push the changes for everyone.
<Mirv> archive admin consultance (preNEW accept) needed for Compiz that adds compiz-mate package, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 - summary of packaging changes https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/32/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff
<elfy> anyone got an idea why lubuntu/gnome/kylin/studio and xubuntu have no dailies for vivid today?
<infinity> elfy: Picking GNOME at random from your list, it looks like it built fine.
<infinity> elfy: Unless today isn't the 17th...
<ogra_> yesterday the 17th was tomorrow
<infinity> ogra_: Ow.
<elfy> infinity: lol - so that built in the last short while :)
<elfy> mine is still showing the 16th on the tracker
<infinity> Speaking of builds, I *think* I finally sorted out everyone's task->meta messes for trusty.
<infinity> And am rebuilding the world right now.
<infinity> I'll check manifests when they're all done and see if I missed anything, but hopefully I got it all in this pass.
<elfy> infinity: thanks :)
<elfy> rest still showing as 16th - has the time these things build been changed?
<ogra_> lubuntu failed it seems
 * ogra_ notices a build failure mail
<elfy> infinity: booted 64bit - that looks more like it :) thanks
<infinity> elfy: Nice.  I'll go diffing things in a bit to make sure I got all the bits right in my own estimation, but if it looks sane, that's a good start.
<elfy> indeed :)
<elfy> still not sure what's up with vivid - but one thing at a time - more interested in trying to get trusty tested again
<elfy> Riddell: you got a minute?
<wxl> infinity: didn't see your email but i assume we're good? did you have any luck fixing the lubuntu alternate image?
<infinity> wxl: I haven't sent the email yet, cause I want to diff all the manifests, but we should be good for desktop images.
<wxl> infinity: so alternate is an unknown?
<infinity> wxl: I'm less inclined to try to fix the alternate, to be honest.
<infinity> wxl: But I can look at it later and see if the fix is simple enough.
<wxl> infinity: k thanks, hope you didn't have to pull an all nighter :)
<infinity> wxl: I might have...
<wxl> :(
<infinity> It happens. :P
<wxl> well thank you for your hard work regardless, infinity
<wxl> infinity: so server is going to suggest netboot/mini.iso then?
<elfy> infinity - so I've quickly done all 10 of our tests with trusty on vb and am pleased to have 10 passes instead of fails - so thanks awfully :)
<infinity> wxl: No, server doesn't have the same issue.
<wxl> infinity: well that's lucky :)
<infinity> wxl: Since server doesn't ship X.
<wxl> ah, i didn't realize it was x-specific
<infinity> wxl: Yeah, this is all about the X HWE stack.
<infinity> elfy: That's encouraging.
<wxl> infinity: so it's about the change from tasks to metapackages specifically for the x hwe stack?
<infinity> wxl: Right.
<wxl> infinity: oohhhhhhhhh, well now that clears things up quite a bit. thanks, then.
<infinity> wxl: Because tasks don't change post-release, so we can't make the *-desktop tasks suddenly pull in the new X stack.
<ogra_> will be interesting what happens to this in Mirland
<infinity> ogra_: I suspect Mir will still need a fair bit of the X framework for a long while, unless "switch to Mir" also implies "and only support 3 video cards", so... We'll see.
<wxl> infinity: wow, how did we ever survive using tasks before?
<infinity> wxl: We did this same thing in precise with the HWE point releases there.
<ogra_> infinity, right, so we might end up with two hwe stacks for a while
<ogra_> for the graphical bits
<wxl> infinity: so will we be metapackage only for 16.04 and on?
<infinity> wxl: I'm pondering that question.  Doing the switch at .2 hurts a lot, so doing .0 with metapackages makes some sense.  But tasks are a bit more convenient for $reasons.
<infinity> wxl: There are some ways we could make tasks post-release manglable, so thinking about that too.
<wxl> infinity: yes, there has been some concern about not using tasks. still, i see this whole transition to be a royal pain in the you-know-what for the release team (i.e. you in this case!)
<infinity> Hrm, and lubuntu powerpc is FTBFS.  Fun.
 * infinity scratches his head at that one.
<wxl> infinity: that is of major sucking, as lubuntu has changed to really only supporting ppc on lts
<infinity> wxl: Well, people who install with 14.04 and upgrade are fine.  It's just the 14.04.2 livefs that's hating me.
<infinity> wxl: But I'll look at it after I've rested a bit.
<wxl> infinity: we're seeing the lack of xserver-xorg-input-synaptics still in the live session. is it possible that the live session would fail but the install would work fine?
<infinity> wxl: Erm...
<infinity> wxl: Which image?
<wxl> infinity: desktop i386
<infinity> wxl: And are you just looking for the package name, or the functionality? :P
<wxl> infinity: is the package not required for functionality? :)
<infinity> wxl: Oh, hrm.  Okay, I did all my testing on amd64...  i386 does seem confused. :/
<wxl> <more expletives>
<wxl> infinity: i hate to ask this, but i assume you can resolve this?
<infinity> wxl: I'm sure it can be resolved.
<infinity> wxl: I first need to sort out why it's broken.
<wxl> infinity: thank you. please keep me updated.
<infinity> I might need to explicitly install xserver-xorg-input-all-lts-utopic, that's all.
<wxl> infinity: if that's what it is. i did do a diff on old versus new if that's helpful
<infinity> wxl: Have the diff handy?
<wxl> infinity: several available in the bug description of 1417784
<wxl> oops bug 1417784
<ubot93> bug 1417784 in lubuntu-meta (Ubuntu) "several packages missing or added in Lubuntu 14.04.2 manifests" [Critical,Triaged] https://launchpad.net/bugs/1417784
<infinity> Yeah, it looks like, for some insane reason, it's picking evdev instead of all.
<infinity> Implicitly installing all should fix it.
<wxl> infinity: okie dokie. none of the other differences are an issue?
<infinity> wxl: The others should have been fixed already in my previous pass, I believe.
<wxl> okie dokie
<wxl> infinity: let me know when we should go for a rebuild
<infinity> wxl: I'm going to do a pass of all the manfiests for all arches and flavours, I guess, and see where we stand, so I'm not doing a bunch of fixes in a row.
<infinity> wxl: But if you can test amd64, and assume I'll fix i386 soon, that'd be cool. :P
<wxl> infinity: on it
<infinity> wxl: Since it seems napping isn't going to be an option, I'm going to eat and take a TV/lunch break before I get to that, but should be sorted with new images spit out in, say, 4h or so.
<wxl> cool, thanks infinity
<jderose> found an issue with UEFI mode desktop installs - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1422864
<ubot93> Launchpad bug 1422864 in ubiquity (Ubuntu) "14.04.2: UEFI: linux 3.13.0-45 downloaded during install" [Undecided,New]
<cyphermox> jderose: looking
<jderose> cyphermox: thanks! i've never been clear on why the uefi-mode installs download the newest kernel but bios-mode doesn't. either way, it's not downloading the correct one :)
<cyphermox> jderose: well, the "newest" is the correct one and is on the CD anyway, but something is convincing ubiquity to get an older one.
<jderose> yeah, seems it's on  the 14.04.1 track still.
 * infinity boggles at lubuntu missing a dep of lubuntu-desktop, but having lubuntu-desktop installed...
<cyphermox> o.o;
<infinity> Oh, because it's provided by gnome-system-tools as well.  Brilliant.
<infinity> And, gnome-time-admin is a transitional package that shouldn't even be seeded.  Okay, that's one mystery I can stop caring about.
<cyphermox> infinity: there is much yuckiness in gnome-system-tools :)
<infinity> Meh, still a few other manifest diff bugs too.  *sigh*
<cyphermox> infinity: so, it's base-installer explicitly getting you to install linux-signed-generic, linux-signed-image-generic, that gets queries in ubiquity's scripts/check-kernels
<cyphermox> looks like base-installer/kernel/altmeta should allow for tweaking this, but perhaps not enough for signed kernels
<cyphermox> or any really. maybe it's not meant for that
<infinity> altmeta is meant to deal with that, yes.  But we don't preseed it on desktop installs because we don't have a kernel to select.
<infinity> And therein lies the problem, I imagine.
<cyphermox> hm, true
<cyphermox> the sed looks unsufficient anyway
<infinity> I wonder if we had a preseed on precise, and I'm just missing that bit somewhere.
<infinity> It does?  altmeta works great on the server ISOs.  Or, should do.
<cyphermox> trying to look that up but I'm waiting for the install to finish
<cyphermox> infinity: sed 's/$/-$RET/', it won't change -generic into xyz-generic, but I may be misunderstanding the intent
<cyphermox> download to finish, I mean
<infinity> cyphermox: No, it changes linux-generic into linux-generic-lts-utopic
<cyphermox> ah
<cyphermox> magic!
<infinity> cyphermox: $ (end of line) becomes -$RET (-lts-utopic)
<cyphermox> yes, I can read regex
<infinity> See, I assumed you could, but you seemed to be reading it backwards.  Maybe. :)
<cyphermox> no
<infinity> Or French.
<infinity> Stop reading in French.
<cyphermox> I just didn't know we had a linux-generic-lts-utopic
<infinity> Ahh. :)
<cyphermox> how about you start learning French? two official languages and all of that ;)
<infinity> I was fully bilingual as a child.
<cyphermox> d-i	base-installer/kernel/altmeta	string lts-saucy
<infinity> I've lost most of my vocabulary since I stopped using it.
<cyphermox> magic!
<infinity> Magic, and stale magic at that.
<infinity> Since that probably should have been trusty, if that was a 12.04.5 image. :/
<cyphermox> nah, it was .4
<infinity> Where is that preseed?
<cyphermox> you mean on the CD or in livecd-rootfs/ubuntu-cdimage?
<infinity> On the CD.
<infinity> From debian-cd, it looks like it should be there for trusty too...
<cyphermox> preseed/ubuntu.seed
 * infinity downloads a trusty ISO to look.
<cyphermox> ehhh
<cyphermox> it's there already
<infinity> That's what I assumed. :/
<infinity> So, either the preseed isn't being read correctly, or it's not base-installer's fault we're getting that kernel installed.
<cyphermox> I'd like to assume the preseed works
<infinity> I know it works with d-i installs (server CD and netinst), but ubiuity and I have never been on the best of terms.
<infinity> Perhaps a log from your install implies what it was thinking when it happened? :/
<cyphermox> working on it
<wxl> infinity: lubuntu amd64 desktop is a go, so at least that's good. alternate is hosed, but i'm not surprised.
<infinity> wxl: amd64 is still a bit broken too, but glad you didn't notice. :P
<wxl> aw great, infinity
<melodie> hello
<melodie> I have had a few talks with wxl about the issues met in Lubuntu. wxl said on the list and on another chan that infinity is in charge of the hard job : fix the issues.
<infinity> melodie: infinity is working on it currently.
<melodie> how can the fact that the packages linux-libc-dev and two depends of this package are not mentioned in the lubuntu trusty daily filesystem.manifest?
<melodie> I have seen them in Ubuntu, in Xubuntu one of them. Not in Lubuntu
<infinity> melodie: They never were in lubuntu's manifest.
<melodie> can that affect the behavior of the installer or other important parts?
<melodie> they were in 2012 when I did a search for a project of mine.
<melodie> so that's unrelated?
<infinity> melodie: Please compare to the 14.04 lubuntu manifest, not to another flavour.
<melodie> infinity ok. will do.
<melodie> thanks.
<infinity> cyphermox: So, the preseed is definitely being found at least.  Whether it's influencing ubiquity's abuse of base-installer is another question entirely.
<elfy> infinity: just quick mention that I'm sure you'll see - we appear to have xscreensaver and mate-notification-daemon in our newest image
<infinity> elfy: Yeah, noticed already and committing fixes.
<elfy> awesome :)
<infinity> Well, fixes committed for mate-notification-daemon ... Need to sort out xscreensaver.
<elfy> ok - ty
<infinity> elfy: Okay, and xscreensaver sorted too, I think.
<elfy> excellent
<elfy> rebuilds coming sometime by tomorrow? or request myself ?
<infinity> elfy: Well, I need to upload first. :P
<infinity> elfy: Rebuilds will be done by me for everyone, I think.
<elfy> lol - I didn't mean I'll go do that now :)
<infinity> elfy: Hoping to hunt down this efi/signed thing too.
<elfy> aah - super - I'll just wait for notification of it then :)
<infinity> elfy: OOI, do you test amd64 on UEFI systems?
<elfy> not personally
<infinity> elfy: I assume LP: #1422864 is a universal bug (can't see why it wouldn't be).
<ubot93> Launchpad bug 1422864 in ubiquity (Ubuntu) "14.04.2: UEFI: linux 3.13.0-45 downloaded during install" [Undecided,New] https://launchpad.net/bugs/1422864
<elfy> not sure if anyone does specifically for us
<elfy> tbh I've never needed to worry about UEFI
<infinity> elfy: The time will come soon, I'm sure. :P
<infinity> elfy: Hard to buy a new machine that doesn't force you to care.
<infinity> Or, getting harder anyway.
<elfy> well this machine has uefi pretty sure - but don't install - boot the usb to the other option
<elfy> certainly no EFI in /boot which I thought is where it would be
<infinity> cyphermox: If you make sense of the kernel thing, or need a sounding board, let me know.  I'm going to veg for a bit and try to not fall asleep.
<cyphermox> ugh, doing the best I can
<cyphermox> I'm testing this here but I can't seem to reproduce it just yet by hacking my way about it
<cyphermox> now trying a proper install with efi
<cyphermox> but really, efi or not you should get the same preseed behavior and the same kernel name mangling from altmeta and stuffs
<infinity> cyphermox: Yes, but without efi, it never tries to install/keep the signed kernel, so that whole path might be skipped.
<infinity> cyphermox: At least, this is my guess.
<cyphermox> yeah, but that's exactly what I was trying to reproduce just looking at /var/lib/ubiquity/install-kernel and remove-kernel
<cyphermox> they looked fine either way, if I just went running check-kernel for efi or non-efi
<infinity>         preferred_kernels="$(echo "$preferred_kernels" | sed "s/$/-$RET/"; \
<infinity>                              echo "$preferred_kernels")"
<cyphermox> yep
<infinity> for kernel in $preferred_kernels; do
<infinity> I read that second block as "I'm going to try to install the 'signed' variant of everything!"
<infinity> That's scripts/check-kernels
<cyphermox> yes
<infinity> At least, that's a naive stab in the dark on my part, I don't know how it all hooks back into reality.
<infinity> But that would install linux-signed-generic-lts-utopic (already there) *and* linux-signed-generic
<cyphermox> ah, here it's getting into remove-kernels... not good
<infinity> ie: I think the second "echo $preferred_kernels" is probably what's biting us.
<jderose> cyphermox: please let me know if you'd like me to help test anything... i have a qemu VM setup for uefi, so easy to do quick tests
<infinity> jderose: I think we've logicked it out.  Easiest testing method will be live-patching a VM before running ubiquity, when there's a patch, someone might paste it to you for sanity checking.
<jderose> infinity: cool, thanks
<melodie> good night
<infinity> jderose: http://paste.ubuntu.com/10280647/ might do the trick.
<infinity> jderose: Not entirely sure where scripts/check-kernels lives on the live filesystem, but "dpkg -S check-scripts" should find it.
<infinity> Err, check-kernels.
<jderose> infinity: okay, i'll give it a test. so just modify this file in the live enviroment before starting the installer, right?
<infinity> jderose: Right.
<bluesabre> would any archive admins be interested in releasing this to the archive? :-) New source: lightdm-gtk-greeter-settings (vivid-proposed/primary) [1.1.0-0ubuntu1]
<jderose> infinity: fix seems to work in that 3.13 is not getting installed. although that doesn't prove it would correctly download a newer 3.16 kernel were it available :)
<infinity> jderose: Well, if the system reboots and has linux-signed-lts-utopic installed, that should be proof it worked correctly.
<infinity> jderose: Since those packages are removed if not "needed".
<jderose> infinity: but linux-signed-lts-utopic was installed before.... the problem was that 3.13 was also needlessly installed
<infinity> jderose: Right.  I'm saying that it won't have regressed if it's still installing it. :P
<jderose> ah, gotcha
<infinity> jderose: So, if 3.16's signed is there and no 3.13 is there, we win.
<infinity> jderose: As soon as you tell me the rebooted system looks sane, kernel-wise, I'll commit and upload this.
<jderose> infinity: yup, rebooted, looked good
<cyphermox> awesome
<infinity> jderose: Thanks for the testing!
<jderose> infinity: cyphermox: np. thanks for the quick fix!
#ubuntu-release 2015-02-18
<wxl> infinity: anything else i can do to help?
<infinity> wxl: Just be patient.  Once this ubiquity makes its way through, I'll respin the world again.
<wxl> infinity: ok, just checking. wish i could help out :)
 * wxl sings a song about how heroic infinity is
 * bluesabre sings along
<infinity> wxl: Those alternates are likely still broken, I shouldn't have rebuilt them. :P
<infinity> wxl: But desktop CDs should be popping out soon for everyone.
<wxl> infinity: well, i have hope that something you do MIGHT make something better :)
 * infinity has an intense need for pizza, wine, and naps.
<Mirv> repeating from yesterday a request:âarchive admin consultance (preNEW accept) needed for Compiz that adds compiz-mate package, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 - summary of packaging changes https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/32/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diffâ
<Mirv> ie what you'd do normally if it already was in NEW queue
<wxl> infinity: when you arise from the dead, do you have any ideas on what can be done with ppc desktop? it seems that there's all sorts of dependency hell with xserver-xorg-* packages  https://launchpadlibrarian.net/197941262/buildlog_ubuntu_trusty_powerpc_lubuntu_FAILEDTOBUILD.txt.gz
<jamespage> urgh - please could someone reject golang-pty-dev - got the wrong source package name
<Riddell> jamespage: rejected!
<jamespage> Riddell, thanks
<Laney> Could someone look at grilo-plugins in vivid/NEW to unblock the gnome-photos autopkgtest please?
<flexiondotorg> Is there anyone in here who can review the Upload Queue? - https://launchpad.net/ubuntu/vivid/+queue
<davmor2> infinity: is netboot safe to test at this point?
<davmor2> infinity: and does netboot mini.iso hwe include the latest kernels etc
<flexiondotorg> ð
<rbasak> Could an AA take a look at bug 1417328 please? I think it's blocking proposed migration for MySQL 5.6.
<ubot93> bug 1417328 in percona-xtradb-cluster-5.5 (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328
<rbasak> I do need to get NEW percona-xtradb-cluster-5.6 uploaded though. Reviewing that now.
<rbasak> I don't think it should block removal though?
<rbasak> (of 5.5)
<highvoltage> o/
<highvoltage> Edubuntu 14.04.2 images marked as ready
<davmor2> infinity: are you about?
<ogra_> ogra@anubis:~$ rmadison livecd-rootfs
<ogra_> curl: (22) The requested URL returned error: 503 Service Temporarily Unavailable
<ogra_> cjwatson, ^^^ is that known ?
<cjwatson> It might just be unhappy because I'm doing a giant git repack
<ogra_> ah, k
 * ogra_ will wait then
<cjwatson> Though the machine is otherwise responsive
<Laney> Might be something else
<cjwatson> Grr
<Laney> I don't seem to be able to get to it from lillypilly
<cjwatson> cjwatson@lillypilly:~$ GET http://archive-team.internal/
<cjwatson> Can't connect to archive-team.internal:80 (Connection refused)
<cjwatson> Yeah
<cjwatson> I bet they broke the firewall.  Let me check
<cjwatson> ogra_: escalated to webops
<rsalveti> http://people.canonical.com/~ubuntu-archive/proposed-migration/ is also giving 503
<rsalveti> might be the same issue
<cjwatson> rsalveti: yes, everything under http://people.canonical.com/~ubuntu-archive/ is broken by this
<Riddell> bug 1423225
<ubot93> bug 1423225 in base-files (Ubuntu) "lsb-release 14.04.2 still points to 14.04.1" [Undecided,New] https://launchpad.net/bugs/1423225
<Riddell> infinity: â isn't that important to change ?
<infinity> Riddell: Oh, sonofa... I didn't promote base-files to updates before the last respin. :(
 * infinity wonders how he missed that.
<arges> infinity: hey. any merges you guys need help with?
<davmor2> infinity: hey dude, the mini.iso are still dated the 30/01 do they need an update at all or is mini.iso and netboot good to test?
<infinity> davmor2: netboot should be fine.
<jderose> infinity: so might be a regression introduced in fixing lp:1422864, but now linux-signed-generic-lts-utopic is marked as automatically installed, will be removed with "apt-get autoremove"
<davmor2> infinity: and is that the same for the HWE version?
<infinity> jderose: Erk, really?
<jderose> infinity: yeah, i just added a comment and screenshot - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1422864
<ubot93> Launchpad bug 1422864 in ubiquity (Ubuntu Trusty) "14.04.2: UEFI: linux 3.13.0-45 downloaded during install" [Undecided,Fix released]
<jderose> infinity: does that seem related to you, or is this a separate issue?
<infinity> jderose: I'm not sure how the change we made last night would have toggled the auto/manual state of that package.
<infinity> jderose: But it's a bug nonetheless.  Will investigate before I do the respin-for-base-files-screwup.
<infinity> Which image are you testing?  ubuntu?
<jderose> infinity: yes, ubuntu desktop amd64
<infinity> jderose: Alright, grabbing it.
<infinity> davmor2: Should be, yes.
<davmor2> infinity: cool
<infinity> davmor2: d-i was rebuilt for the latest kernels, there shouldn't have been a reason to rebuild it again after.
<davmor2> infinity: no worries
<davmor2> jibel: ^ I guess that means it's safe to test did you add it to the tracker?
<cjwatson> ogra_,rsalveti: webops have fixed it now
<cjwatson> though it'll be very slow until I've finished this git archive maintenance
<jderose> infinity: also, another problem i'm still trying to narrow down.... so in an oem install, i have a script that makes sure  ubiquity-frontend-gtk, oem-config-gtk are installed, because they've sometimes been missing in daily ubuntu+1 ISOs. with a production ISO this script should have no effect....
<jderose> infinity: but but when i try to install the two, apt wants to remove grub-efi-amd64 grub-efi-amd64-signed
<ogra_> cjwatson, yep, confirmed, works fine (as expected ... after some minutes :) )
<infinity> jderose: There are no conflicts there, I can't see why that would be happening...
<jderose> infinity: still trying to wrap my head around it, reproduce in a more isolated way. but for what it's worth, this script works fine when i do an oem install from 14.04.1
<rsalveti> cjwatson: thanks!
<jderose> infinity: starting to narrow it down. at least when doing a uefi-mode oem install, oem-config-gtk isn't installed - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1423254
<ubot93> Launchpad bug 1423254 in ubiquity (Ubuntu) "14.04.2: oem-config-gtk not installed after doing an OEM install" [Undecided,New]
<jderose> checking bios-mode now
<jibel> infinity, ^ confirmed
<jibel> cannot do an OEM installation
<infinity> Lovely. :/
<jderose> jibel: so are you testing in bios mode then?
<infinity> Does either of you happen to remember a time in the past when it did work correctly?
<jibel> jderose, no, it was an UEFI installation
<jibel> infinity, last attempt to release 14.04.2
<jderose> infinity: well, works with 14.04.1 :)
<jibel> infinity, 3 weeks ago
<jibel> or 2
<infinity> jibel: ...
<jderose> ah yeah, worked with the daily from feb 3
<infinity> jibel: It worked 2 weeks ago?  Not much changed.  Grr.
<jibel> infinity, usually it means that ubiquity and oem-config are out of sync
<infinity> Well, "not much changed" should make it easier to lay blame, but I really don't like that the blame might be a 4-line ubiquity change that shouldn't relate.
<jibel> infinity, ubniquity has be updated yesterday
<jibel> well, today
<jibel> I'm lost in time
<infinity> jderose: Well, reproduced the linux-signed meta issue.  Scratching my head about the why now. :P
<infinity> jibel: Oh indeed, you're right, the oem-config in the pool is out of sync.  Weird.  That really shouldn't happen.
 * infinity wonders if he has a stale lock on his mirror again.
<jderose> infinity: well, it's good i'm not crazy at least :) do you think this is related to the change yesterday?
<infinity> jibel: So, that might magically fix itself when I abuse nusakan and do a rebuild for the base-files issue.
<infinity> jderose: I think it could be.  I really don't want it to be. :P
<jibel> infinity, yeah, rebuild until if works ;)
<jibel> it*
<infinity> jibel: I was thinking something slightly more elegant like "figure out why my mirror is stale, then rebuild", but sure.
<infinity> Also, wow, llvmpipe video is awful.  Can I get something less crap in an OVMF qemu?
<jderose> infinity: oem-config-gtk is likewise missing after doing a BIOS-mode OEM install
<infinity> jderose: Yeah, same problem I'm sure.
<infinity> And I think I've narrowed down what's happening with linux-signed.  Ish.
<jderose> although when you try to manually install them after the fact in BIOS mode, apt doesn't want to remove grub-efi, so at least it's a slightly better situation
<infinity> linux-signed-image-generic-lts-utopic *should* be marked auto (and is), but linux-signed-generic-lts-utopic should be installed and manual, and it's... Not there.
<infinity> Now to hunt down why it's not there. :(
<infinity> Oh.  Balls.  It is the change yesterday.
 * infinity does a fresh install with some live patching.
<infinity> How many years ago did "-net user" become the default in qemu?  I just realised I forgot to specify it on the CLI, but I have a network.  And now I suspect I've been pointlessly typing it for half a decade. :P
<mlankhorst> no idea, I've had to use -net nic,vlan=0 -net tap,vlan=0 at least since precise :-)
<infinity> mlankhorst: Yeah, I usually use tun/tap bridge setups too, which might be why I never noticed that user "Just Works" without asking for it.
<mlankhorst> mostly for netboot
<infinity> cyphermox: You around?
<cyphermox> yes
<cyphermox> just finished my soup
<infinity> cyphermox: http://paste.ubuntu.com/10293752/ <-- Spot review for me.
<infinity> cyphermox: Tested by live-patching a VM, and it DTRT.
<cyphermox> there was an issue with $kernels after all?
<infinity> cyphermox: (Our first attempt only kept linux-signed-image-$blah, not linux-signed-$blah, which cascaded into a bunch of autoremovals post-install)
<cyphermox> ok
<infinity> cyphermox: $kernels only contains *image*... Oops.
<infinity> cyphermox: And rather than "fix" that and possibly create another bug, better to just use another list, IMO.
<cyphermox> yes
<infinity> cyphermox: At least, for a quick fix today.
<cyphermox> sounds good
<cyphermox> looks good
<infinity> jderose: Nice catch, BTW.  Not sure most people would have noticed until the first ABI bump when they couldn't boot anymore. :P
<cyphermox> heh :0
<jderose> infinity: only caught it because of some of the automated tooling i use at system76 :)
<infinity> jderose: Huzzah for your scripts hating on me?
<jderose> hehe
<infinity> Self-accepting that upload based on cyphermox's review.
<cyphermox> anything I should look at?
<infinity> cyphermox: Check iso.qa for any interesting new bugs filed that seem like something we could fix in an hour or three?
<cyphermox> sure
<infinity> cyphermox: But I think we're probably about as good as we're going to get once I fix my mirror skew and rebuild with the new ubiquity and base-files.
<jderose> infinity: cyphermox: is it just me, or is the timezone detection broken? i'm in us/mountain, and both desktop and server installs are defaulting to us/eastern
<infinity> jderose: Mine correctly picked Edmonton.
<infinity> jderose: (which is mountain, but of the Canadian type)
<infinity> jderose: Probably has more to do with your ISP.  It's not an exact science.
<jderose> infinity: it doesn't seem like it's even trying though... in the desktop install, i'm used to a delay while it does the lookup (when there in internet access).
<infinity> jderose: I don't remember if I saw a noticable delay (really, it should be quick anyway), but it definitely got it right here, so...
<infinity> jderose: You're not preseeding, I assume?
<jderose> no
<jderose> hmm, i wonder if the lookup is being skipped on oem installs, but not in normal installs... double checking some things
<infinity> jderose: I thought OEM install was broken for you anyway?  Or did you hack around it to keep testing?
<jderose> hacked around it. the install works okay, but oem-config-gtk isn't installed. you can manually install it after the fact
<jderose> well, except for the uefi-mode issue.
<jderose> infinity: never mind, must be something new and magical with my ISP... i'm getting us/eastern when i do a desktop 14.10 install also
<infinity> jderose: Yeah.  Large ISPs shuffle subnets around every once in a while, and the magic geoip databases don't always keep up.
<infinity> jderose: I've lived in pretty much every timezone in Canada over the last few years without ever moving. :P
<jderose> hehe :)
<infinity> In theory, IPv6 will fix all of this.  In theory.
<infinity> Except that most people get their v6 via tunnels right now, and completely break the geographical routing assumptions.
<cyphermox> jderose: you could check https://freegeoip.net/ to find out if that's it, but it most likely is the reason
<infinity> cyphermox: ... where I discover that I've been proxying firefox through my colo in San Jose for god knows how long and forgot to turn that off.
<cyphermox> fwiw I live in a reasonably sized city where the ISP usually does the right thing, but with dynamic IPs, they can mess up geoip databases pretty quickly
<infinity> cyphermox: Also, creepy.  Looking up my real IP actually drills down to the right postal code.  I don't know how I feel about that.
<cyphermox> infinity: meet Big Brother.
<Riddell> infinity: will you respin for the lsb-release update?
<jderose> hmm, pretty amazing it gets it right down to that sort of granularity. amazing/creepy, take your pick i guess :)
<infinity> Riddell: Once this ubiquity winds its way through.  So, Soon(tm).
<cyphermox> infinity: ou could sit at home, and do like absolutely nothing, and your name goes through like 17 computers a day. 1984? Yeah right, man. That's a typo. Orwell is here now. He's livin' large. We have no names, man. No names. We are nameless!
<infinity> Riddell: Did you have one more thing you wanted to squeeze in, or just curious when you'll see new ISOs?
<infinity> cyphermox: Great, now I need to watch Hackers in the background while I work.
<cyphermox> sorry, so do I
<Riddell> infinity: the latter, just needing to know if I should poke my testers now or wait
<Riddell> I'll wait :)
<infinity> Riddell: arm64/armhf binaries for ubiquity need to publish, then a copy-to-updates, another publisher cycle, then buildy buildy.
<infinity> Riddell: So, triggering in probably about an hour, images as they spit out after that.
<cyphermox> jderose: take into consideration it could pinpoint your location to the meter, via lat/lon coordinates. Databases don't usually include that precise information, but it could ;)
<infinity> cyphermox: I love the "17 computers a day" bit, though.  That number seemed low even then, and laughably tiny now.
<cyphermox> indeed.
<cyphermox> infinity: fwiw I don't see bugs-i-can-fix-in-one-hour so much in iso.qa, unless it was going to be yet another ubiquity upload for bug 1418105 ;)
<ubot93> bug 1418105 in ubiquity (Ubuntu) "Trusty: testing .2 the oem session on i386 leaves the oem wifi password in place" [High,In progress] https://launchpad.net/bugs/1418105
<cyphermox> .. which isn't even on iso.qa?
<cyphermox> and not yet fixed in vivid, either, so yeah
<infinity> cyphermox: That's not a regression, right?
<infinity> cyphermox: If not, then target for .3 is much more reasonable than trying to squeeze it in.
<cyphermox> infinity: no, that was already in 14.04.1 too
<cyphermox> yeah, I know
 * infinity targets it.
<infinity> cyphermox: Fun bug, though.  Reminds me of how Every Single Time we get a machine sent to us from IBM, it's configured to run on their internal network. :P
<cyphermox> my evil plan has been discovered.
<infinity> Because, apparently, DHCP is hard.
<cyphermox> well, it's really a lot more of an issue for wifi, assuming people would do OEM installs on a wifi network and all
<cyphermox> most likely one by one, because preseeding that would be ugly.
<infinity> cyphermox: Sure, yeah, cause the password is actual sensitive data.  But conceptually similar, that's all. :)
<cyphermox> yes
<infinity> cyphermox: Though, I think it would be hilarious if driving by System76 with my laptop gave me free Internets.
<infinity> jderose: Can we consider this a feature instead of a bug? :)
<cyphermox> infinity: ask jderose, he could hook you up
<cyphermox> ;D
<jderose> infinity: cyphermox: it doesn't. now we do all our image mastering with qemu, never have a wifi password in the golden image
<infinity> jderose: Oh, I didn't assume this bug actually affected you. :P
<jderose> although i do know that prior to me working at system76... free wifi was included. definitely a feature :)
<infinity> jderose: You're just the only OEM in the channel right now to bug. :P
<cyphermox> you'd see house prices right around that building rise up, and mostly taken by Ubuntu developers, that's break demographic statistics badly :)
<infinity> cyphermox: I dunno, what self-respecting developer would be satisfied sharing WiFi with a bunch of other people?
<infinity> cyphermox: I consider my 100Mbit slow. :(
 * ogra_ glares at infinity 
<infinity> I need to go back in time to when I thought 1.5 SDSL was effin' INCREDIBLE, and just live there forever.
<cyphermox> 100MBit?
 * ogra_ still lives there 
<ogra_> well ... 2MBit SDSL
<infinity> cyphermox: Yeah.  Well, only 10 up, which is part of the complaint.  Cause who downloads stuff, really?
<infinity> ogra_: At least it's S and not A.  I imagine 2M down would ba 256k up or something in A land.
<infinity> Or worse.
<ogra_> yeah
<ogra_> thats why i have it :)
<infinity> ogra_: Also, assuming that's SDSL-over-repurposed-ISDN-infra, isn't the EU standard 2.3Mbit, not 2?
<infinity> Or are you rounding down? :P
<ogra_> nope, its 2MBit :)
<infinity> Sucks to be wherever you are...
<ogra_> they probably swallow the overhead somehow
<ogra_> i could get 100M cable ... *if* there was cable in m street ... which my neighbors voted against
<ogra_> s/m/my/
<infinity> ogra_: Get it two streets over and set up a wireless repeater?
<ogra_> haha
<jderose> infinity: was the problem with base-files just that /etc/lsb-release hadn't been bumped to 14.04.2?
<infinity> ogra_: That's more or less how lamont used to do things before they finally ran cable to his place.
<ogra_> well, I#m pondering getting an additional sat link
<infinity> jderose: The problem was that I bumped it ages ago and forgot to promote it from -proposed because I'm a derp.
<ogra_> for downloads that should be fine ... 60M or some such for ~50â¬
<jderose> infinity: no, not a derp. likely just too busy with other things :)
<infinity> jderose: I'm sticking with the derp explanation.
<jderose> fair enough, that's your right :P
 * ogra_ goes back to scream and shout about nodejs and npm 
<ogra_> i'm inclined to say i havent seen something as bad in a long time ...
<ogra_> but i think thats wrong ... i havent seen something that bad *evar* !
<infinity> ogra_: Whatever you're doing with node, RUN AWAY.
<ogra_> hahaha
<ogra_> to late
<infinity> It's never too late.  You're in an abusive relationship with nodejs, there's help available.
<ogra_> well, created that "hangouts server" for snappy ... webrtc based using socket.io ... so it need node ... up to now i just used a complete node sdk build that i unpackked in the snap before building it ...
<ogra_> now i'm trying to get x86 working too and try to pull the node install from the archive ...
<ogra_> (which makes it 10:1 smaller ... but is a pain to do in qemu arm chroots)
<infinity> So use real hardware?
<infinity> Surely, you have some lying around from a past life. :P
<ogra_> heh, i even have a ton of new one (yay snappy) ...
<ogra_> but i want a build script that runs on one machine
<infinity> I think relying on qemu-user-static for this is likely to end in tears.
<infinity> There are any number of things it just will never do quite right.
<ogra_> my target is to have a proper script for people wanting to package node projects
<infinity> And it'll fail even more miserably the day someone asks you to support powerpc.
<ogra_> so they can just call it on their PC and get a snap with the necessary binaries in place
<ogra_> the point is that i use binaries from debs ... i *theoretically* wouldnt need to even execute anything foreign
<infinity> ogra_: As long as the debs don't have postinsts that are necessary, yeah.
<ogra_> *if* there wasnt that crappy npm (node package manager) that essentially just downloads crap from github to put it in some module dir
<ogra_> right, but even then i could re-implement my own postinst if needed
<infinity> "Downloading crap from github" is the new black.
<ogra_> yeah
<infinity> It amazes me that people don't see all the flaws in this.
<ogra_> thats whyy we have sappy ... just ship the flaws and dont care how broken it is
<infinity> But I guess our industry is all about making the same mistakes, learning the same lessons, and solving the same problems, every half generation or so.
<jderose> infinity: i feel the same way. call me old fashioned, but i really like signed pre-built packages. and shared libraries, dependencies :)
<infinity> jderose: You're old-fashioned.
<infinity> jderose: And also 100% correct.
<infinity> jderose: And I have no bias whatsoever.
<infinity> *cough*
<jderose> hehe
 * ogra_ loves the "a package is a project" approach you can go with snappy ... 
<ogra_> it fulfills a different purpose indeed
<infinity> ogra_: I don't at all discount the need for the "app store" model to let people do crazy things, and to let upstreams and end users get on with things without me getting in their way.
<infinity> ogra_: I was specifically being grumpy about how the "github culture" distributes software.
<ogra_> yeah
<infinity> Blows my mind that it's become both common and *accepted* to say "wget this ruby script and pipe it to sudo, what could possibly go wrong?"
<infinity> I kinda want to blame Apple.  Just cause.
<ogra_> haha
<infinity> The OSX generation of UNIX developers seem to leave much to be desired when it comes to learning all the same things we learned 15 years ago.
<ogra_> dunno, can you blame apple for misbehaving opensource devs ?
<jderose> infinity: i'm noticed a very strong correlation between using osx and being a fan of this approach :)
<infinity> ogra_: No, I can blame them for switching to UNIX (which was the right thing to do, but argh)
 * ogra_ would expect them rather in the linux camp
<ogra_> for switching UNIX you mean :)
<infinity> That too.
<wxl> infinity: speaking of apple, any luck on lubuntu desktop ppc? :)
<ogra_> lol
<wxl> ftw XD
<ogra_> stop being on topic !
<infinity> wxl: Oh, err.  No.
<ogra_> :)
<wxl> i know, so lame
<infinity> wxl: We might just have to skip that image this round, and PPC users can install with 14.04.1
<infinity> wxl: I think we're running out of time to unwind what went wrong.
<wxl> infinity: well the log kind of suggested the same problems as with the others but *shrug*
<infinity> wxl: To be fair, PPC users also have about 0 reason to want/need the HWE stack.
<infinity> wxl: No, the log suggests entirely new and exciting problems. :P
<wxl> hm
<wxl> not what i saw
<infinity> wxl: Well, none of the other failed to build, they just got weird things installed.
<infinity> wxl: ppc is actually just refusing to install what we ask it.  I'd need to spend some quality time in a PPC chroot and sort out what mlankhorst broke. :P
 * infinity fires up a PowerStation in the corner to look.
<infinity> wxl: No promises on fixing it, but I'll look.
<infinity> wxl: But, like I said, I don't think it's world-ending either.  The HWE stack is for people who have Really New Hardware, which is the exact opposite of your PPC users.
<wxl> infinity: yeah, but if we can fix it, it would be nice
<wxl> infinity: looking at the END of https://launchpadlibrarian.net/197941262/buildlog_ubuntu_trusty_powerpc_lubuntu_FAILEDTOBUILD.txt.gz it's apt that's unhappy
<infinity> wxl: Yes, I've read the log.
<infinity> wxl: Just need to drill down a lot deeper to find out why.
<infinity> And it's probably that the X metapackages are broken on PPC.
<infinity> But fixing them means respinning everyone, so as we get closer to the wire, I'm more inclined to say "oh well, next time".
<wxl> meh
<wxl> well you're the boss :)
<infinity> wxl: I wouldn't leave one of your x86 images high and dry like that, but yeah.  PPC users probably shouldn't want the HWE stack anyway.  It solves nothing for them, except pretty version number bumps.
<infinity> Anyhow, I'll look now.  If it's a quick fix, I'll slam it in.
<wxl> that's what i'm thinking it might be
<wxl> and if's not, then yeah, oh well :)
<infinity> wxl: Thankfully, we can just keep publishing the 14.04.1 PPC ISO anyway, and other than the weird version mismatch, no "normal end user" will really notice the difference. :P
<infinity> Install, update, it says "14.04.2" when they log in, just old kernel and X, no big deal.
<wxl> yep, sounds good
 * infinity needs to get some faster SAS disks for his PPC machine...
<infinity> Or more RAM and a massive tmpfs.
<wxl> infinity: what ram you need?
<wxl> if you tell me what hardware you need for that ppc machine, i'll figure out a way to get it to you
<infinity> wxl: Hah.  Not sure, TBH.  I'd have to go digging a bit.
<wxl> infinity: well, let me know
<wxl> brb
<infinity> wxl: But being old server class hardware, it's probably something annoyingly expensive, like the disks. :P
<infinity> I'm really just waiting for more OpenPower kit to become available.
<wxl> infinity: oh you have a server, huh. maybe i could ship you my g5 :)
<wxl> you and randall ross, eh, infinity ?
<infinity> wxl: It's essentially the same as your G5, but with some IBM oddities.
<wxl> brb
<infinity> wxl: Okay, throwing a quick test at my PPA.  If this builds for all arches, I'll let it in, but I make no promises that it will boot, install, or not suck.
<wxl> infinity: sounds good, thanks
 * infinity taps his foot waiting for LP to publish that so he can kick off quick tests.
<infinity> rsalveti: Are you doing manual builds on nusakan right now?
<infinity> Okay, rebuilding everything but lubuntu for the ubiquity and base-files bugs.  Will respin lubuntu after I've tested this livecd-rootfs hack for PPC.
<infinity> Riddell: Images should start vomiting out shortly.
 * infinity goes to hunt lunch.
<wxl> thanks infinity
<infinity> wxl: Okay, got it building.  Once this livecd-rootfs makes its way through LP, I'll rebuild lubuntu.
<infinity> wxl: Like I said, I'm making no promises about the PPC ISOs being usable, this is our one chance.  If they suck, oh well.
<infinity> wxl: But the manifest diffs look sane, so they might be alright.
<infinity> Riddell: Lucky you, your ISOs were first out ^
<elfy> alphabetical? going to propose AXubuntu :p
<infinity> elfy: No, entirely random (ish).
<elfy> :)
<infinity> elfy: We throw all the livefs builds at the buildds and the first ones to return get turned into ISOs.
<infinity> elfy: So, in theory, the smaller livefses would usually win.
<elfy> right
<infinity> elfy: (And that would always be server, except that it takes a while to get the powerpc livefs back across the ocean...)
<infinity> elfy: Really, though, there's a certain element of "whee, computers!  parallelism is hard!" to it that makes it random enough to be fun betting on.
<elfy> ha ha
<jderose> infinity: 20150218.1 desktop amd64: uefi mode install seems correct; also no problems with OEM install (now to test customer setup bit)
<jderose> infinity: oem-config customer setup bit seems solid too
<infinity> jderose: \o/
<infinity> jderose: I love it when a plan comes together.
<jderose> infinity: thanks for all the help and quick fixes!
<infinity> jderose: Are you logging your testing on the ISO tracker?  I see 0/9 for all ubuntu desktop tests, always nice to see more than just jibel filling those in. ;)
<jderose> infinity: no, i haven't been. for some reason ubuntu sso wont let me signinto the tracker, i think because i used the same user name before tracker was integrated with sso
<infinity> jderose: Oh, special.  I thought all instances of that had been fixed.
<infinity> stgraber: ^-- You know what's up with that?  (if you're not too busy at Collab)
<infinity> wxl: Your builds are on their way now.
<wxl> thx infinity
<wxl> um desktop ppc's not there infinity https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu
<wxl> i mean i see the tracker thinks it's rebuilding
<infinity> Bah, maybe it failed differently.  Looking.
<infinity> Or the build never happened...
<wxl> that's what i'm thinking infinity
<wxl> i've never seen it not show up there if it's in process
<infinity> I think the tracker rebuild thingee lost its mind.  Let me force the issue.
<infinity> wxl: Doing a manual build to restore sanity.
<wxl> thank you again, infinity
<davmor2> infinity: netboot on 32,64,32hwe,64hwe done
<infinity> wxl: It might end up renumbering amd64 and i386 to .2, but they'll be the same build as before.
<infinity> davmor2: Ta.
<infinity> davmor2: Any idea who's taking responsibility for testing server ISOs?
<davmor2> infinity: server team normally
<infinity> davmor2: I can do ppc and ppc64el, since no one else seems to, but we usually have a ton of Canonical QA folks doing x86.
<davmor2> infinity: yes I'm one of them ;) I was getting the netboot out the way while iso's were respinning
<infinity> highvoltage: Sorry to invalidate all your testing, but there's a new edubuntu for you to spot check and smoketest.
<infinity> davmor2: Check.
<davmor2> infinity: tomorrow I think the plan is that jibel will hit i386 and amd64 and I'll do a quick run on mac, I think server team have their own qa who auto/manually test server at least that is what has happened in the past jibel might know more though
<wxl> i see it building, so thanks infinity
<infinity> davmor2: I'd better test ppc/ppc64el tonight, so I know if the world's generally broken.
<infinity> davmor2: But I don't really anticipate issues, the HWE stuff is both (a) trivial for server compared to desktop and (b) been included in dailies for months without much complaint.
<infinity> superm1: Is anyone testing mythbuntu point release ISOs?
<davmor2> infinity: famous last words ;) QA Motto if something can go wrong it will and will take out the universe with it :D
<infinity> davmor2: Don't jinx it.
<infinity> zequence: Ditto for you, is anyone testing studio point release ISOs?  You're running out of time.
<infinity> davmor2: What's the public/community QA channel again?  Either I parted it, or I can't remember what it's called. :P
<elfy> #ubuntu-quality
<elfy> that the one you mean?
<davmor2> infinity: #ubuntu-quality
<davmor2> meh elfy beat me to it :)
<elfy> :)
<rsalveti> infinity: I was building for touch
<elfy> infinity: what sort of time UTC are you expecting to release tomorrow for trusty?
<wxl> you're utc-5 infinity ?
<elfy> not working - so I'll be able to catch my own stragglers and could do other's empties for an hour or so today
<infinity> rsalveti: Yeah, I figured.  Stellar response time, though! ;)
<rsalveti> infinity: sorry, started the image and went to get some food :-)
<infinity> wxl: I'm -0700 right now.
<wxl> infinity: oh, you're close to my time, good. :)
<infinity> elfy: I haven't picked a time, and won't until I get more results in.  We could always be respinning again if something Very Bad is found. :/
<wxl> so my guess is something like 1200-0700
<elfy> infinity: yep understand that - but it's not going to be something daft like 10:00UTC is what I'm after here :)
<wxl> elfy: hahah yeah it's not going to follow the ubuntu on air schedule XD
<infinity> elfy: Oh, no.  It'll be much later than that.
<elfy> infinity: ok - cool, I can clean up my own stuff tomorrow then - have a bit of time now - can smoketest studio's installs at least
<elfy> and I mailed the studio list too
<infinity> elfy: You're a champion.
<elfy> infinity: I could actually mark the studio stuff for release, in the -release team to get access on trackers to help them set up package stuff
<elfy> not that I actually would
<infinity> elfy: If $people test it, I'll happily mark it ready myself.  I'm really just looking for either user-harmful showstoppers (you tried to install it and your computer started speaking in tongues before throwing a fireball at your cat) or usability showstoppers (the xfce desktop was replaced by fvwm95, and no one's sure how).
<infinity> elfy: If it all looks "good enough", I'm not terribly picky.
<elfy> :D
<elfy> not looking forward to beta vivid - we got a vbox issue on 32 bit that's going to have people failing it :)
 * wxl waits for the successfully built desktop ppc image to show up on the tracker alreadyÂ·
<infinity> elfy: Tell the virtualbox testers to use kvm instead? :P
<infinity> wxl: It's still thinking hard about it over here.
<elfy> infinity: I looked at that - too much to think about for this old man
<infinity> elfy: I'm sure there are pretty GUI frontends to KVM too...
<infinity> Not that I use them, but I'm sure they exist.
<elfy> probably - and probably not as 'hard' as it appeared
<elfy> but if they didn't test with it - we'd not have found a bunch of stuff last cycle :D
<infinity> elfy: Usually, what we find with virtualbox is that virtualbox is crap.
<elfy> yea
<infinity> elfy: Which is an interesting test, but less relevant when 99% of our expected users are either installing on real hardware or in cloud instances, which are invariably every hypervisor in the world EXCEPT virtualbox.
<cjwatson> infinity: hey, fvwm95 was pretty good.
<infinity> (kvm, xen, hyper-v, vmware...)
<cjwatson> At least, you know, in 1998.
<infinity> cjwatson: Wash the pink paint off your shades.
<elfy> unfortunately people use it - and till I got rid of testdrive references in the current wiki - QA recommended vbox sort off :)
<infinity> cjwatson: Also, windowmaker 4 lyf, yo.  *gang sign*
<elfy> s/off/of
<cjwatson> I tried using windowmaker in 1999 and never understood it
<stgraber> jderose: hey
<infinity> cjwatson: Understanding it wasn't important, it was undocking apps and watching the icon explode.  You could do that ALL DAY LONG and never tire of it.
<elfy> infinity: understand your point - but only Ubuntu will be worrying about cloud :)
<jderose> stgraber: hey :)
<infinity> elfy: Sure, but most desktop people don't worry about any virt (err, except I guess Mac people and whatever thing they insist on running Linux under...)
<elfy> :)
<stgraber> jderose: ok, so let me take a look at the tracker logs real quick
<wxl> OMG PPC JUST BUILT
<elfy> cjwatson: have you got a really quick minute in PM?
<wxl> elfy: infinity: isn't virt-manager the GUI for kvm?
<infinity> wxl: Dude, that was a whole 6 minutes ago.
<wxl> infinity: i was involved in other conversation :)
<elfy> he's been refreshing the tracker infinity :)
<cjwatson> elfy: sure
<wxl> and i like virtualbox honestly
<cjwatson> though I'm mostly a spectator here now
<infinity> wxl: And sure, if you say so.  I run qemu from the commandline because I hate learning anything that involves a mouse and isn't a video game.
<wxl> of course i use the one from oracle's repos
<wxl> infinity: word, homie.
<stgraber> jderose: can you login now so I get a new log record to investigate?
<wxl> is there anywhere that the upload to cdimages are tracked (publicly)?
<jderose> stgraber: done: The name jderose is already taken.
<infinity> wxl: I'm not sure what you mean by "upload to cdimages".
<wxl> infinity: once the build is done, it uploads to cdimage, right?
<infinity> wxl: Well, it's done on a machine we call "cdimage", and published to its disk.
<infinity> wxl: Then mirrored via rsync to all the frontends you know as cdimage.ubuntu.com
<wxl> so this is not made public at all, infinity ?
<infinity> wxl: But there's nothing being uploaded to cdimage, per se.
<infinity> wxl: I'm not sure what you're asking for. :P
<infinity> wxl: The rsync logs to the frontends?  No, no reason for every mirror to make their logs public.
<infinity> wxl: The cd image build logs, those are public.
<infinity> wxl: http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<cjwatson> although only synced hourly or so
<wxl> oh that's good to know cjwatson
<cjwatson> oh, every 15 minutes, not so bad
<stgraber> jderose: try now
<jderose> stgraber: it worked, thanks!
<stgraber> good
<elfy> oops installer crashed in studio
<elfy> knew I should have just gone to bed
<infinity> ...
<stgraber> not sure what was going on, I just checked if there was any content linked to the old account and seeing how there was none, I removed it :)
<elfy> mmm
<infinity> elfy: Like, python exploded, or whole desktop went poof?
<elfy> won't let me report it either ...
<elfy> crashed mid install
<infinity> But just ubiquity, is what I was asking?
<elfy> trying again
<elfy> I guess - I'd set it all up and it was in the middle of the actual install
<elfy> wouldn't let me report it - 3rd party package warning from apport
<infinity> Oh, apport, you scamp.
<elfy> :p
<elfy> redoing it
<elfy> 32bit install passed, the livesession tests passed as much as I could
<ianorlin> Hi apport from running the installer at the menu doesn't seem to working on a package during the install I think the install completed but is saying the packages on the release are not offical package on the installation media
<wxl> do you have any idea what you might have done to cause that issue, infinity ? :)
<wxl> ianorlin: that's desktop amd64 or i386?
<ianorlin> desktop i386
<ianorlin> I orignally just wanted to report a papercut but apport being broken in install seems to be worse bug
<infinity> I have no idea why apport feels the urge to even perform that check, nor why it's half broken. :/
<elfy> but funny I just had the same
<infinity> bdmurray: The above is all yours.  Why does apport suck at life?
<elfy> infinity: mmm - so it crashed again - apport gave up again - best I can do is show what it was trying to install when it crashed
<elfy> http://i.imgur.com/5C75Q1i.png
<infinity> elfy: The file from /var/crash could be handy.
<elfy> I'll run it again ...
<elfy> ;)
 * infinity downloads the image too..
<infinity> elfy: amd64?
<bdmurray> ianorlin: which desktop image?
<elfy> yep
<elfy> checked the md5sum - that was good
<bdmurray> have you run apt-get update yet?
<elfy> bdmurray: I get the same apport issue from the studio 64 bit trusty image - apport fail that is
<ianorlin> trusty-desktop-i386
<ianorlin> ah that works around it
<bdmurray> ianorlin: apt-get update?
<ianorlin> yes from the installer
<bdmurray> infinity: its because apport doesn't know where the packages come from
<infinity> bdmurray: Which means?
<infinity> bdmurray: Seems like a bug if you can't file bugs from the livecd because apport's being too strict about how it decides a package is "official".
<elfy> bdmurray: if I'm getting the same - better to abort and apt-get update and start again?
<bdmurray> elfy: getting the same what?
<elfy> apport issue in studio's 64 bit trusty
<elfy> but half way through install
<ianorlin> improve error message to make apport tell you to run sudo apt-get update if in the installer and you have ubiquity running?
<elfy> infinity: ok so crashed again, can see the crash file - which is 13Mb
<infinity> elfy: That's a bit larger than I'd hoped, but if you can toss that $somewhere that I can get at it, that might be nice.
<infinity> elfy: I'm about to try to reproduce myself anyway, though.
<elfy> trying to ;)
<infinity> cyphermox: Want to grab an ubuntustudio trusty ISO, on the off chance that I need help hunting down WTF is going on?
<infinity> It might just be that studio doesn't get to release with this point release if we can't sort it in a hurry, I'm not going to delay everyone else because they had no testing. :/
<cyphermox> infinity: ah, yes, I might as well start downloading
<cyphermox> I was going to run off in a few minutes for karate class though, but I guess I can reschedule that to tomorrow
<infinity> cyphermox: amd64.  Seems elfy can only reproduce this on amd64, for some odd reason.
 * infinity is hoping he can't reproduce under kvm and can just blame it on virtualbox somehow.
<cyphermox> does virtualbox/qemu matter?
<cyphermox> ah, answers my question
<infinity> cyphermox: Well, http://i.imgur.com/5C75Q1i.png was in vbox.
<infinity> cyphermox: But I doubt it actually matters. :P
<cyphermox> yeah, I saw
<elfy> infinity: paste.ubuntu.com/10298040
<cyphermox> hmm, for a crash like that, and the four lines in the screenshot look fine too, I doubt it's vbox
<infinity> cyphermox: Yeah, I know.
<cyphermox> ...
<infinity> bdmurray: So, is this behaviour a new regression?  Given that ubiquity *has code* to call into apport when it crashes, either this has never worked (unlikely), ubiquity hasn't crashed for anyone in ages (unlikely), or something changed to break this.
<cyphermox> ah, I see. paste.u.c is slow because the paste is ginormous.
<elfy> yea ...
<cyphermox> elfy: you... ran out of space?
<infinity> elfy: Your disk image is too small.
<elfy> orly
<infinity> Feb 18 22:51:03 ubuntu-studio ubiquity: Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
<infinity>  Feb 18 22:51:04 ubuntu-studio ubiquity: /usr/bin/mandb:
<infinity>  Feb 18 22:51:04 ubuntu-studio ubiquity: can't write to /var/cache/man/10957
<infinity>  Feb 18 22:51:04 ubuntu-studio ubiquity: : No space left on device
<infinity> elfy: studio is kinda huge. :P
<elfy> mmm
<bdmurray> infinity: I've tested it in utopic / vivid live cds and it (ubuntu-bug apport) works for me. I did find a bug about it failing when the installation is off-line.
<elfy> yea yea - it says it wants 8.6Gb - made drive 10
<infinity> Their estimate is clearly wrong. :P
<infinity> But that's a minor bug compared to an installer crashing.
<infinity> So, phew.
<ianorlin> I am online I kust started it before it ran apt-get update on installing
<elfy> infinity: :D
<ianorlin> I got apport to work using apt-get update
<elfy> rerunning it for the last time ...
<bdmurray> infinity: apt-cache policy apport when booting a Trusty Live CD doesn't show the version being from archive.ubuntu.com rather /var/lib/dpkg/status
<infinity> cyphermox: That said, can you file a ubiquity bug for it to do a df of target before popping up the "crash" dialog and maybe suggesting something more appropriate like "you ran out of disk, doofus" instead of "please file a bug"?
<infinity> bdmurray: Yes, that's expected on a livecd.
<cyphermox> yeah, sounds like a good idea.
<cyphermox> I'll use non-infinity wording for the error message though ;)
<bdmurray> infinity: it didn't happen with utopic or vivid
<infinity> bdmurray: I think we may have changed livefs creation recently to keep the indexes instead of wiping them.  Don't recall now.
<infinity> bdmurray: But trusty has always been the way it is, we didn't change how IT builds.
<infinity> bdmurray: So either apport's always been doing this in trusty, or a change was backported that wasn't tested in that environment?
<bdmurray> infinity: I'll double check the 14.04.1 release then
<infinity> bdmurray: It's entirely possible this has always happened in trusty, and it's just that no one's crashed anything in the live session and complained about it. :P
<elfy> infinity: 64bit must be a lot bigger than 32bit then - 32bit didn't fail on same size drive
<infinity> bdmurray: But that seems unlikely, y'know?  We know a lot of whiney people.
<infinity> bdmurray: And ship a lot of shoddy software.
<infinity> elfy: 64-bit binaries are a fair chunk larger, the i386 install might have been borderline.
<infinity> elfy: If you're using the automagic partition layout, it's possible the 64-bit one also reserved more swap space, giving you a smaller root.
<elfy> possible - certainly didn't look afterwards :)
<elfy> aah yes
<ianorlin> bdmurry you don't need me to report a problem with apport from the live session do you or should I continue to make the lubuntu i386 install is complete and boots?
<bdmurray> ianorlin: no, I don't need any more information
<bdmurray> infinity: it also happens on 14.04.1 image
<elfy> infinity: yea :) 32 bit ... 92% of / used
<infinity> bdmurray: Okay, cool.  Then not a regression for .2, officially don't care today.
<infinity> bdmurray: But we should sort out what the right fix is for .3
<elfy> I didn't really think about drive size, space it wanted and swap tbh - too late in the day
<bdmurray> infinity: oh and I guess crashes won't be reported from point release CDs either, because of /etc/apport/crashdb.conf problem_types setting
<elfy> infinity: ok - passed that now, so studio have 32/64 bit installs done and some livesession
<infinity> elfy: Well, to be fair to you, the installer is monumentally unhelpful about informing you that you've run out of space.  So, at least we got a cosmetic bug out of it. :P
<elfy> not doing anymore today :)
<infinity> elfy: Thanks for that!
<elfy> infinity: :)
<elfy> and your welcome :)
<elfy> remember how helpful I've been when we still can't get 32bit to run on vbox next week :D
<cyphermox> fwiw it's bug 1423377
<ubot93> bug 1423377 in ubiquity (Ubuntu) "Should show a more meaningful error message on full disk" [Undecided,New] https://launchpad.net/bugs/1423377
<elfy> can I mark that affects me more than once?
<elfy> :p
<infinity> elfy: There might be a new kernel landing before Beta 1, if the kernel team's ducks are all in a row, maybe that'll magically fix your vbox issues.  Maybe.
<infinity> Not that I know what your issues are, and I don't want to know until this point release is out. :P
<elfy> cyphermox: ta - I made a note on the tracker and referred bug
<wxl> so is this whole bug an issue that's going to require respins?
 * infinity suspects he might need beer to fuel the rest of his evening.
<infinity> wxl: There was no bug.  The bug was elfy being tired.
<elfy> infinity: do you think I've been drinking tea?
<wxl> infinity: oh. well ianorlin too then?
 * wxl is drinking tea
<infinity> wxl: Oh, the apport thing?  That's not a regression, we're going to leave it be and fix it later.
<wxl> infinity: k cool
<elfy> infinity: and yes - magic is good too
<infinity> wxl: 14.04.1 images have the same apport issue, so I officially don't care until tomorrow. :P
<wxl> infinity: the workaround will be included in the main release notes, ya?
<wxl> hahaha
<elfy> ok - well - nice to spend some time with you gents - but I'm going to wander off now :)
<elfy> night all
<infinity> elfy: 'Night.
<wxl> nite elfy
<bdmurray> infinity: bug 1423382
<ubot93> bug 1423382 in apport (Ubuntu) "unable to use apport to report a bug from point release Live CDs" [Undecided,New] https://launchpad.net/bugs/1423382
<wxl> ianorlin: could you make sure to include that in your report â
<infinity> bdmurray: The solution might be to have indexes on the livefs, if that's what we're doing in U/V... But we can talk about it when I'm not a release crunch mess.
<elfy> I did
 * cyphermox back in ~1h30
#ubuntu-release 2015-02-19
<wxl> uh?
<wxl> you're just assuming they won't work, infinity ?
<infinity> wxl: I know they don't work. :P
<wxl> i figured as such
<infinity> wxl: I fiddled with amd64 a bit to see if I could sort it out, tested, still broken, and don't have the time to fix it before tomorrow.
<infinity> wxl: But, like I said, the target audience for alternate ISOs and HWE stacks are almost at polar opposites, so I don't think it's a huge loss, just a bit of a personal annoyance that I didn't have the time to figure out how to make it go.
<wxl> it's all good infinity
<wxl> infinity: if you want to look at why maybe check out bug 1417918
<ubot93> bug 1417918 in debian-installer (Ubuntu) "installation step failed - Select and install software" [Undecided,Confirmed] https://launchpad.net/bugs/1417918
<cyphermox> oh, shiny, a d-i bug just for me ;)
<wxl> hahahah have fun cyphermox :)
<cyphermox> ahaha
<wxl> check out the syslog
<infinity> It's not a d-i bug.
 * cyphermox is still high on adrenaline.
<wxl> it's clearly an issue with dpkg
<infinity> wxl: Dude, I was testing locally, I've seen the issue first hand.
<infinity> It's not a dpkg or apt issue either.
<wxl> well i don't mean a bug in dpkg
<wxl> but a bug with the installation
<wxl> so it's an issue with tasks or seeds or some other bs :)
<infinity> There seems to be an issue with non-HWE stuff being installed before the desktop task is selected.
<wxl> oh my
<infinity> But I don't have the time to try to unwind what's going on there.
<infinity> But yes, it's ultimately going to be a seed/task issue, and maybe also a preseed issue.
<cyphermox> infinity: do you have syslog too, or is the one on the bug good enough?
<infinity> cyphermox: I didn't save mine.
<cyphermox> ok
<wxl> infinity: i owe you a beer. thanks for the hard work.
<cyphermox> heh, it looks like fun.
<infinity> cyphermox: Mine looks a lot like that one, though.
<infinity> cyphermox: The curious bit is that if you chroot into /target/, some *mesa* packages (non-HWE) are already installed, though I don't see them getting installed in syslog.
<infinity> cyphermox: So, a bit hard to track down why they're there before the desktop install happens (and fails)
<cyphermox> copied from the live filesystem?
<cyphermox> (just guessing)
<infinity> What live filesystem?
<infinity> This is d-i.
<cyphermox> oh, of course
<cyphermox> but as I recall there is still a live fs now no?
<infinity> Though, I was tired and grumpy, maybe they were ^i., not ^ii...
<infinity> As in, selected for install, but not installed.
<cyphermox> that's why base-installer has some weird live fs image preseed
<infinity> cyphermox: Only the server CD uses live-installer, other alternates (of which lubuntu is the only one left) use base-installer.
<cyphermox> what iso was this?
<infinity> lubuntu-alternate-trusty-amd64 was my guinea pig.
<cyphermox> ok
<cyphermox> are you already looking into it, or can I start looking to let you worry about other things?
<infinity> Honestly, I really want to talk lubuntu out of shipping the alternates.  It's not a codepath we maintain well anymore, and they don't maintain it for us either.
<infinity> cyphermox: I'm giving up and telling them they can't have alternates for the point release.  If you really want to waste an evening figuring out how to fix it, be my guest, but don't make anyone any promises.
<cyphermox> I wasn't going to make promises, I know better
<wxl> i don't think we can avoid not having alternates
<wxl> lubuntu is a strange case, as the targets are often old computers
<wxl> there are other issues with netboot/mini.iso i hadn't really considered
<infinity> wxl: I think the better option is a text-based ubiquity that doesn't involve the X overhead.
<wxl> our only hope is a text-only frontend to ubiquity
<wxl> great minds think alike :)
<wxl> infinity: unfortunately, i don't know if i can implement that myself
<wxl> i've asked the server team for some help
<wxl> no response yet :/
<infinity> wxl: Though, the boot-to-ubiquity option solves most concerns.  Maybe only the ubuntu images have that?
<wxl> whatcha mean boot-to-ubiquity?
<wxl> like don't go live before installing?
<cyphermox> Install, rather than Try and
<infinity> wxl: Cause if you can't run a minimal X and just ubiquity (no desktop, etc), then you can't run LXDE either, let's be honest.
<infinity> wxl: Yes, boot to install, instead of try-then-install.
<wxl> infinity: yeah we have that
<infinity> wxl: That should boot to a minimal X environment with just ubiquity running.
<wxl> infinity: but even still it seems to require more memory than lxde does
<infinity> wxl: And really, if you can't run JUST ubiquity and X, how can you run a full desktop (even a lightweight one) and, say, a web browser?
<wxl> we only need like 128-256mb to run lxde
<wxl> you can run a browser
<wxl> it's just stupid slow :)
<wxl> ubiquity outright freezes if you don't meet its memory requirements
<cyphermox> wxl: just ubiquity and ubiquity-dm takes more memory than lxde?
<infinity> Anyhow, I think the right path is to explore slimming down the installer if we can.
<wxl> cyphermox: seems to
<infinity> ubiquity-dm could be a bit of a hog.  An lxde variant could solve that.
<wxl> infinity: i agree. we just need (at minimum) some stakeholders, if not people to DO the work :)
<cyphermox> wxl: that ought to be fixable by editing ubiquity-dm. maybe it's not doing quite the right thing to bring up the session for lubuntu
<wxl> cyphermox: infinity: i still think text only would be ideal. then we could get server away from d-i, too
<wxl> that way ALL of us would share the same problems
<cyphermox> heh..
<wxl> well
<wxl> with the installer, cyphermox :)
<cyphermox> d-i tends to work ;)
<wxl> mmmmm
<wxl> i don't know if that's 100% been my experience :)
<infinity> wxl: Server is fine with what it has, really.  It's d-i in conjunction with complex and weird desktop use-cases that explodes a bit oddly at times.
<cyphermox> wxl: but hey, if you want to implement a text-only frontend for ubiquity, you're free to play with it. There's already a debconf frontend so it can't be missing all that much
<infinity> And, to be honest, "real" server admins never use the CD.
<wxl> heheh
<wxl> so what's ubiquity-dm
<wxl> ?
<wxl> !info ubiquity-dm
<wxl> derp
<ubot93> Package ubiquity-dm does not exist in utopic
<cyphermox> mostly a script that starts key parts of the session apps for whatever release
<infinity> cyphermox: I think what the debconf frontend is missing is a sane UI (or any UI?) for the partitioner, last I looked.
<infinity> cyphermox: Which is, of course, the hardest part to get right.
<cyphermox> infinity: right
<wxl> well i guess i could look deeper and see what i might be able to figure out
<Ukikie> !find ubiquity-dm
<cyphermox> or just preseed it ;)
<ubot93> File ubiquity-dm found in ubiquity
<cyphermox> wxl: ubiquity-dm is a script in ubiquity\
<cyphermox> under bin/ IIRC
<wxl> alrighty
<wxl> hey cjwatson is the maintainer. i'll just tell him to fix it XD
<infinity> wxl: Not anymore.
<cyphermox> you might be surprised at the result... or I'll be
<wxl> infinity: i know, i was kidding.
<infinity> ubiquity-dm appears to be trying to do lxde-ish things correctly already.
<infinity> It may well just be that ubiquity itself is a bit too chubby.
<infinity> Writing installers in python is handy, but not exactly memory-efficient.
<infinity> But there could also be obvious bits that could be slimmed down with some effort.
<wxl> i'll play with this and see what i can figure out
<infinity> Profiling python isn't my forte though, just complaining about it.
<wxl> that's usually the case, infinity :)
<infinity> I'd rewrite it in C if everyone involved wouldn't shoot me for doing it.
<wxl> oh man
<wxl> that would be like nuclear
<flo__> Thanks everyone for bringing us 14.04.2 :-) I've installed the HWE bits already and Tropico 5 finally works on my older AMD card. I should probably check if they have fixed ETS2 as well, that was an issue when I uninstalled catalyst some time ago. :-) Anyway, thanks & good night!
<cyphermox> Ah? Seems to me like ubiquity in c could be nice, just a time-consuming endeavor
 * wxl starts rewriting ubiquity in common lisp
<cyphermox> Redoing or dropping all these hacks
<infinity> cyphermox: It doesn't lend well to rapid fixes or new features, which is obviously why it wasn't done in C, but it sure would be quicker and smaller. :/
<cyphermox> wxl: there is definitely some room for improvement though already, so if you have any branches to review I'll be happy to help
<wxl> seriously, though, i'll see what i can do
<cyphermox> And otherwise I'll see about making some large cleanups as well, but I suspect it won't be for vivid, it's already busy enough for me to get into the hang of things with the bugs right now, and FF being right around the corner
<infinity> ypwong: Not sure if you noticed, but we had to respin all the trusty ISOs for another couple of bugs.  If you guys could re-test kylin (quick smoketesting to make sure the images are still sane), that would be lovely.
 * infinity goes to take a beer and video game break.
 * elfy will one day be in the same place as infinity and will slide him a beer ... 
<elfy> Riddell: ping :)
<bluesabre> we have reached the age of a the omni-tz elfy
<elfy> yea ...
<elfy> holiday week and what did I do?
<elfy> really late image tests for someone else ...
<bluesabre> dedicated individual
<elfy> read that as maniac ...
<elfy> :D
<stgraber> infinity: FYI due to sucky Internet here, I'm about 10 hours away from getting the Edubuntu candidate images downloaded on my laptop, so unless highvoltage can spend some time doing the testing, Edubuntu will only get test results pretty late tomorrow (due to me being on the west coast at the moment)
<highvoltage> stgraber: hmm, I tested Tuesday night's one and marked it as ready, but it seems cleared out on the tracker
<bzoltan_> hi all, I see the qtcreator-plugin-ubuntu and the phablet-tools being blocked like this -> https://jenkins.qa.ubuntu.com/job/vivid-adt-qtcreator-plugin-ubuntu/lastBuild/ARCH=amd64,label=adt/console looks like an infrastructure issue
<bzoltan_> Could anybody here help me?
<infinity> highvoltage: I had to respin for a couple of bugs.  Re-testing should really just be a boot/install/reboot smoketest to make sure the image didn't somehow implode.
<infinity> bzoltan_: That's not an infrastructure issue, it's a broken package.
<bzoltan_> infinity:  I see, and how can I see what is broken there?
<infinity> bzoltan_: Oh, a broken package that was deleted from proposed for being so broken.
<infinity> bzoltan_: So, someone just needs to retry those tests for you.
<bzoltan_> infinity:  who could do that?
<infinity> bzoltan_: I could if I was home.  pitti or jibel certainly can, when they're around.
<bzoltan_> infinity:  Thank you, I will check with them. Enjoy not being at home :)
<wxl> well 2/3 lubuntus done
<wxl> now to start a fire under ppc folks grr
<wxl> server need help?
<darkxst> infinity, Ubuntu GNOME images seem ready, won't mark them us such, so people keep testing
<darkxst> so just go ahead, since I won't likely be awake when you are doing the releases!
<wxl> congrats darkxst :)
<darkxst> wxl, what for? think we got lucky with this one
<wxl> that's what i mean!
<darkxst> wxl, right
<amjjawad> darkxst, I'll be around so no worries
<amjjawad> don't mark them as ready yet please, darkxst so we get more testing :)
<amjjawad> darkxst, I have bad night so in case I will sleep early, I will try to wake up early and do the needful so no worries about the release, etc etc
<darkxst> amjjawad, isnt that what I just said!
<amjjawad> darkxst, and I was confirming it!
<infinity> darkxst: Good to hear.  I won't be releasing until tomorrow afternoon (my time), so plenty of time for testing, but I'm also not going to respin or retract images for anything but dire bugs, so pretty sure this is what we're shipping.
<amjjawad> infinity, thanks for all your hard work, you and everyone else :) but may I know what is your time zone, please? so I can get things ready on time :)
<infinity> amjjawad: -0700 ... You have plenty of time.
<infinity> amjjawad: It's 1:22am now, and I'm heading to bed.
<amjjawad> I'm from the future (+11GMT) so indeed, that's plenty of time :) good night and thanks for everything :)
<infinity> amjjawad: Please send me winning lottery numbers, thx.
<amjjawad> infinity, will sure do :P
<darkxst> infinity, thanks, was just saying so you know they ready, though sounds like amjjawad will stay up anyway
<darkxst> infinity, I'm not very good at responding to are your images ready yet pings when I am asleep ;)
<Riddell> elfy: you pung?
<jibel> davmor2, if you find 10 min, can you try an OEM installation. The session didn't start on first boot, immediately after the end user setup.
<davmor2> jibel: will do
<elfy> Riddell: I did :) do you have a moment to spare me in PM ?
<jibel> davmor2, and again, this time on i386, on first boot to prepare for end user, unity session fails to start
<jibel> no compiz
<davmor2> jibel: I have i386 install for the oem bit now will reboot it in a second
<davmor2> jibel: I'm still not getting the password box on hw till I reboot again, I do have a desktop but I did have to reboot to get the password box
<jibel> davmor2, actually the live session doesn't even start on i386
<jibel> davmor2, it's on qemu, can you try on HW?
<Riddell> elfy: ok
<davmor2> jibel: let me check I have the right iso
<jibel> amd64 is OK
<davmor2> jibel: this is i386
<davmor2> jibel: I'll try a live session 1 second
<davmor2> jibel: I have the live cd up and the iso image md5sum matches the one in current
<davmor2> live session even
<jibel> davmor2, yeah, it seems to be a qemu only problem
<davmor2> jibel: I did have a crash file for the greeter though so I might see if I can add that to the bug report
<highvoltage> Edubuntu 14.04.2 LTS marked as ready
<Riddell> hmm non english installs are broken in kubuntu for bug 1182784
<ubot93> bug 1182784 in ubiquity (Ubuntu Utopic) "Install with non English language fails on Keyboard: "ubi-console-setup failed with exit code 141" or "Installer Crashed"" [Critical,Fix released] https://launchpad.net/bugs/1182784
<Riddell> I wonder if I have time for a fix and respin
<Mirv> didrocks: would you have time for bin-preNEW review of compiz(-mate) since it's FF today? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 / https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff
<didrocks> Mirv: why is there this remove unity script on upgrade?
<didrocks> Mirv: the default profile plugin doesn't use unity for mate
<didrocks> (see debian/mate.ini)
<didrocks> Mirv: all the rest is good, but this part should be clarified
<Mirv> bregma: ^
<bregma> didrocks, hmm, I'll check
<didrocks> bregma: yeah, I see it's a copy of my own migration script a while ago, but this was to transition from "default" to "ubuntu" session (and so, leave the default session with compiz without unityshell)
<didrocks> bregma: If I'm right and can still read my code, no promise :p
<Mirv> thanks didier for helping bregma
<didrocks> yw!
<bregma> it's a dark moist area of the code I haven't looked at before, I'l trying to grok it now
<didrocks> bregma: yeah, it's not really a biggy but I feel it's not of use (and will just create a delay at startup), so better to check
<didrocks> bregma: maybe you can even clear my old migration script, the LTS has passed :)
<bregma> maybe
<bregma> didrocks, would it be acceptable to promote the current MATE changes as-is and open a bug to remove all the migration stuff before Vivid release?
<didrocks> bregma: fine by me if you ensure me it doesn't fall off track :)
<bregma> I shall open a bug and get an MP up today, as soon as I get a troubled Unity landing off my plate
<didrocks> bregma: let me open the bug for you
<didrocks> Mirv: +1 then ^
<Mirv> didrocks: bregma \o/ huge thanks!
<didrocks> bregma: bug #1423566
<ubot93> bug 1423566 in compiz (Ubuntu) "Removal of migration scripts (both MATE and ubuntu one)" [High,New] https://launchpad.net/bugs/1423566
<bregma> super
 * pitti waves
<pitti> so GunnarHj asked me to build fresh trusty langpacks (with new -base), as we got updated ubuntu-docs this week
<pitti> I realize the timing of this might be a bit unfortunate with 14.04.2, though
<pitti> so what is the best course of action now:
<pitti> - wait a week
<pitti> - build/test them and upload them to -proposed, so that they can be tested, and we only release them next week
<wxl> pitti: 14.04.2 is out today. vivid beta 2 is out next thursday. so act now! :)
<pitti> or
<pitti> - upload them, but don't accept them from the trusty-proposed queue?
<pitti> wxl: this is about trusty :)
<pitti> infinity: ^
<wxl> pitti: oh. then you're either screwed or infinity is going to be peeved. XD
<pitti> I'm not saying that these langpacks must go into 14.04.2 :)
<pitti> just making sure that uploading them to trusty-proposed now won't cause any difficulties
<pitti> I don't see any as trusty-proposed has lots of stuff which isn't going into 14.04.2
<pitti> but better safe than sorry
<wxl> afaik we made sure -proposed wasn't enabled by default in trusty
<wxl> that *was* a problem at one point :/
<pitti> urgh :)
<wxl> sorry i can't otherwise be of help
<wxl> unfortunately my only relation to the release team is being the release manager for lubuntu
<wxl> infinity and i are on similar time zones and i'm up early, so, you might give him a couple hrs
<wxl> also he's pulled a couple all nighters this week for trusty :(
<pitti> I'll just prepare them for now, but not upload them yet
<wxl> i'd say that's a good idea
<stgraber> highvoltage: thanks for testing! I just woke up here and noticed that the hotel disconnected me halfway through the night so it'd still take me another 4 hours or so to grab the Edubuntu images...
<jamespage> afternoon - please could an archive admin do the honours and promote python-pint? - https://bugs.launchpad.net/ubuntu/+source/python-pint/+bug/1407970
<ubot93> Launchpad bug 1407970 in python-pint (Ubuntu) "[MIR] python-pint" [High,Fix committed]
<jamespage> that unsticks one of my teams openstack uploads
 * Riddell rebuilds kubuntu for new ubiquity
<Daviey> jamespage: done
<jamespage> Daviey, thanks!
<infinity> Riddell: Err, what?  You got a rebuild for ubiquity already... Or did you upload a new one when I wasn't looking?
<Riddell> infinity: yes I uploaded a new one
<infinity> Riddell: Ugh.
<infinity> Riddell: And thi crash only happens in the KDE frontend, despite being in common code?
<infinity> Daviey: Hey, weren't you involved with mythbuntu at some point? :P
<Daviey> infinity: Sort of still am.. but not claiming to be. :)
<infinity> Daviey: No one's smoketested the 14.04.2 images.  Could I talk you into spinning them up for a quick boot/install/reboot cycle to make sure they're not completely buggered?
<Riddell> infinity: yes, it's in a PageFooKDE class
<infinity> Riddell: Mmkay.  Technically, I should respin the world for the change, but I'll let it slide in that case.
<infinity> pitti: Please no langpacks today. :P
<Daviey> infinity: Would you believe me if i said i only had access to armv7 machine today?
<infinity> pitti: Would have been nice to have them a week ago, but oh well.
<infinity> Daviey: Probably not.
<pitti> infinity: yeah, certainly not for 14.04.2; it's mostly the question whether uploading them to -proposed would disturb anything on yours ide
<infinity> pitti: No, I'm blissfully ignoring proposed right now.
<tgm4883> infinity: I can do that today
<tgm4883> let me pull the images now
<infinity> Riddell: Argh.  I'm going to have to respin those again for you.
<infinity> Riddell: The cdimage ftp mirror got skewed, your ubiquity and oem-config are mismatched.
<infinity> tgm4883: Thanks.
 * infinity really needs to hunt and fix that bug.
<tgm4883> infinity: 20150218.1 images?
<infinity> tgm4883: Yep.
<tgm4883> ok, pulling them now
<infinity> Riddell: Fixing the mirror skew issue, will respin for you as soon as it's not broken. :/
<pitti> infinity: i. e. I can upload those and translators can test them? they'd be released to -updates in two weeks
<Riddell> :( sorry
<infinity> pitti: Sure, go nuts.
<infinity> Riddell: Not your fault, the local mirror thing is a bit fragile.
 * infinity taps his foot, waiting for rsync.
<cjwatson> Laney,infinity: could use reviews/merges of my stack of britney MPs if you get a chance.  They're mostly cowboyed live but it'd be best to squash the cowboys ASAP
<infinity> Riddell: Okay, respinning again.
<cjwatson> also should mostly be fairly obvious
<infinity> cjwatson: After I point release.  Tomorrow seems more likely.
<cjwatson> k
<cjwatson> the remaining piece is to work out what to do with the "old binaries" bits on http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html for linux
<cjwatson> I think I'm going to add a switch to britney.py to ignore those for stables, TBH
<infinity> cjwatson: Oh, whee.  Didn't think about that ugliness.
<cjwatson> because even discounting the debatable bit about whether to clean up old ABIs, there are always going to be binaries in trusty release that we can't get rid of
<cjwatson> and honestly I really don't want to get into having to teach britney.py to tell the difference between release and updates and suchlike ...
<infinity> cjwatson: Well, and even if I won the debate with "screw every old ABI except the ones on currently published installation media", there would still be *some* old ones.
<cjwatson> yeah exactly
<cjwatson> I think we just have to ignore those, maybe keep the excuse but not make it block
<infinity> cjwatson: Can you special case the ignore to just linux* source packages?
<infinity> cjwatson: Not that I anticipate others having NBS, but I suppose it could happen in the case of agressive-backports-as-SRUs (firefox locales, for instance), and the cruft should actually be noticed and cleaned.
<cjwatson> I can think of other cases where it matters
<cjwatson> and where we can't clear it
<infinity> Hrm.  Okay, then you've thought about it more than I have. :P
<cjwatson> consider a library upload for a new HWE stack that changes the library package name, and we've decided to accept that and rebuild everything for it
<infinity> I guess it's not killing us to carry other cruft anyway, linux is by far the worst offender.
<cjwatson> that could well be fine (if nasty), but we can never get rid of the original binary in trusty release
<infinity> cjwatson: new HWE stack libraries have new source names.
<cjwatson> s/for a new HWE stack //
<cjwatson> it was an example :)
<cjwatson> my point is there are situations where there's uncleanable cruft
<infinity> But yeah, right, I hadn't thought about the part where you're smooshing release and updates into a single "testing".
<infinity> Cause we can't do a thing about "cruft" (which isn't) in release.
<cjwatson> now it's sort of theoretically possible to fix that by making the merge be source-aware
<cjwatson> actually, hmm, maybe it already is
<infinity> I think the "just ignore it" solution is fine for now.
<cjwatson> ok, I can start by "just ignore it" but limited to .startswith("linux")
<cjwatson> and we can see how that goes
<cjwatson> though I'll need to think about how to handle that on the command line, or whether to just do it by default, or what
<cjwatson> I don't want to have to hardcode "dev series is vivid, treat it differently" in too many places
<infinity> cjwatson: Wait, other than the ugly output on excuses, what's the actual problem?  In the dev series, the "testing" target always has old binaries, since we don't clean them until after the migration.
<infinity> cjwatson: Or is this check for "old binaries that don't belong to the target's source version"?  ie: really old binaries.
<tgm4883> infinity: testing done. Sorry about the wait on that, with the US holiday this week, and conducting interviews I've been pretty busy
<infinity> tgm4883: All good.  Thanks for the turnaround.
<cjwatson> infinity: this all ties into the complex way we mangled britney to handle partial unstable, but normally speaking that gets handled
<cjwatson> infinity: but in this case it doesn't, haven't quite worked out exactly why, but it stops autopkgtests from being dispatched which was kind of the whole point of this exercise
<infinity> Riddell: ^-- Finally.
<Riddell> infinity: thanks, I'll get some people on it, I'm going out shortly for about 3 hours, does that screw with your plans?
<infinity> Riddell: Nope, I have a ton of prep to do before I can release.
<Riddell> sounds fun
<elfy> infinity: are we there yet? :p
<elfy> have fun :)
 * infinity throws things at elfy.
<elfy> :)
<infinity> elfy: If you're feeling all helpful again, I have paperwork you could do!
 * infinity watches as the channel goes silent.
<elfy> I couldn't possibly do any writing  ...
<elfy> and I've got a bone in my leg
<cjwatson> infinity: linux> ah, the problem is that the NBS binaries have never been removed from *-propo*
<cjwatson> *-proposed*
<infinity> cjwatson: Oh.  See, I can do that.
<cjwatson> we don't need to do anything about -updates here, but NBS-cleaning -proposed would sort it out.  I think I'd rather do that than hack britney.
<infinity> cjwatson: No code changes required, I can just fix that in my process.
<cjwatson> Want to leave that to me for this round since you're busy atm?
<infinity> cjwatson: If it's blocking you testing this more, go forth and be cleany.
<cjwatson> It is, and will do.
<infinity> cjwatson: Just don't clean any of the current ones by accident. :)
<cjwatson> I will be careful :)
<cjwatson> Grumble, why doesn't rmadison -r work
<elfy> infinity: seriously - in a bit if there's anything I can do to help you - I will
<cjwatson> oh, because the CGI inhibits it, hmm.
<cjwatson> probably vaguely reasonable.
<infinity> elfy: Well, there's my least favourite part of point releases still to do, running Colin's evil bug-scraping script to put together the "all the crap we fixed since the last point release" part of the release notes.
<Mirv> note on vivid binary new queue - simgear armhf ftbfs is not a regression, the current version doesn't build as well
<cjwatson> infinity: doing the removal pass for -proposed.  will presumably take hours
<cjwatson> for trusty-proposed, that is
<cjwatson> I want to see that this fixes p-m before doing others
<bdmurray> infinity: Looking at the trusty SRU queue won't affect the point release right?
<infinity> bdmurray: Accepting to proposed won't, no.  Just don't release anything to updates today.
<jderose> infinity: just wanted to check in on 14.04.2... do you expect to spin another round of ubuntu desktop iso?
<infinity> jderose: Nope.
<jderose> sweet :)
<infinity> jderose: Don't tell me you found a critically awful bug. :P
<jderose> nope, it's all good from where i sit :)
<infinity> jderose: Because then we won't be on speaking terms.
<infinity> jderose: Oh, good.  All good sounds nice.
 * infinity tests powerpc and ppc64el server ISOs quick-like.
<elfy> infinity: kind of about now, so I could look at that if you wanted and it didn't waste more of your time explaining things than just doing it yourself
<davmor2> infinity: just to make your day https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1423643
<ubot93> Launchpad bug 1423643 in bcmwl (Ubuntu) "Trusty.2 bcmwl-kernel-source is not installing on hwe kernel on macs" [Critical,New]
<infinity> elfy: See the "Prepare change summary" bit of https://wiki.ubuntu.com/PointReleaseProcess
<elfy> infinity: ok
<infinity> elfy: If you want to help by doing that, I'll owe you a large number of bubbly beverages.
<cyphermox> any images still need testing?
<cjwatson> infinity: Oh, should I switch auto-sync into dry-run mode after the 23:00 run?
<infinity> cjwatson: Sounds like a plan.
<infinity> davmor2: Ugh.
<jibel> cyphermox, I just finished desktop but didn't run screenreader and vmware tests
<cjwatson> That just requires me to remember after I get back from the pub, which is probably reasonable-ish.
<cjwatson> It's just adding --dry-run to that crontab line.
<infinity> davmor2: I'm not sure that we can investigate and fix that one before release and force everyone to re-test. :/
<cyphermox> jibel: ok, I can try to run the screenreader while vmware downloads. Having that can't hurt in the future
<infinity> davmor2: I thought that driver was meant to be replaced by one that shipped with the kernel for 3.16.
<infinity> apw: What do you know of bcmwl?
<davmor2> infinity: it's only mac who uses those ;) and there is no oem involvement, personally I blame the sales team for that though I just don't think they are trying hard enough ;)
<infinity> davmor2: Hah.  Good luck squeezing money from Apple to support a competitor's OS.
<davmor2> infinity: I have a feeling that utopic switch to some other driver for bcm but taht doesn't support mac iirc
<jibel> jamespage, do you have anyone to review iSCSI on server images for 14.04.2?
<infinity> davmor2: Can we just tell people with Macs to go buy better laptops?
<elfy> infinity: looking
<elfy> infinity: I note this is in Release minus 14 days and not Release minus a couple of hours ;)
<infinity> elfy: Picky, picky.
<elfy> :D
<elfy> anyway - script running now
<Guest15179> Any idea about 14.04.2? Is it ready for primetime yet ?
<infinity> Guest15179: Patience.
<Guest15179> :)
 * infinity runs downstairs to grab a shawarma for fuel.
<elfy> oooh - grab 2 :)
<infinity> Sure, I'll email you yours.
<elfy> mmm - etherfood
<jibel> infinity, Ubuntu Desktop i386 and amd64 are OK. vmware easy install is not tested.
<jibel> infinity, on server, iSCSI is not tested and I don't have a setup to test it.
<cyphermox> infinity: interesting idea. I just received my shish taouk plate I ordered.
<cyphermox> .. which means I'll need to spend a half-hour shoveling snow later
<wxl> infinity: could you ping me when you have main release notes done?
<elfy> infinity: umm ....
<elfy> so now I have a look at the output - should I maybe have changed line in the script which says "distro_series=precise, pocket='Updates', created_since_date='2012-08-23'
<elfy> possibly explains why it's still going and is at line 6000
<cjwatson> Yeah, that wants to be trusty and the date set to whenever the last SRU was accepted for the previous point release
<cjwatson> Though the output is usually still very long
<elfy> cjwatson: and where would I get that date?
<highvoltage> stgraber: ah that sucks. np though. everything was fine. I have the draft announcement too, but it needs the links fixed for the final links
<cjwatson> elfy: I'm overcomplicating things.  SRUs aren't accepted between end of prep and the actual release, so just find the date of the last point release from the announcement lists and use that
<elfy> ok :)
<elfy> sigh ... so it appeared to finish, last line appears to be dated sensibly 2015-01-26, got this in terminal - http://pastebin.com/g33yvjfh
<elfy> and I am no coder so don't if it's died or if ouput is good
<cjwatson> That died I'm afraid
<cjwatson> But you might be able to tell it to start at 2015-01-26 and then stitch the output together by hand, manually eliminating any overlap
<elfy> cjwatson: thanks
<elfy> mmm keeps dying
<elfy> cjwatson: sorry to be pita - is this just a case of it timing out?
<elfy> infinity: too
<infinity> elfy: Seems like.
<infinity> cjwatson: Hrm, did we even do this for 14.04.1?  I can't find where it was published if we did.
<elfy> bah - keeps doing it ...
<elfy> https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummary/14.04.1
<infinity> Oh, there.
<infinity> Yeah.
<infinity> Missed the link at the top.
<elfy> not sure what I can do here if it's timing out
<cjwatson> sorry you probably get to keep trying
 * cjwatson -> pub
<infinity> wxl: The "main" release notes haven't moved, though they need me to go through and s/14.04.1/14.04.2/ and update kernel bits, etc.
<elfy> infinity: so - question, is it just coincidence that it keeps dying at the same place?
<infinity> elfy: It could be a specific upload on that day had a massive number of bug links.  Likely a kernel.
<infinity> elfy: Just start it over from the next day and splice the two together, and if you missed something in between, oh well?
<infinity> elfy: I'm not convinced anyone reads this page that closely anyway. :P
<elfy> :)
<elfy> ok - so as I had the same thing at later date too 15 mins ago - just keep doing that?
 * infinity cargo cults HWE stack stuff from the precise release notes...
<elfy> infinity: ok - so it eventually finished :)
<infinity> elfy: \o/
<infinity> elfy: Hack and slash it as best you can to be readable, like Colin's previous attempts, perfection isn't the order of the day here, just convey what seems important and skip the 8000 redundant kernel bugs, etc.
<elfy> yea - doing my best ...
<infinity> elfy: When you have something halfway okayish, paste it into the right wiki location, and call it good.
 * infinity builds source DVDs.
<bdmurray> slangasek: I found an old task to write a wrapper around remove-package for unverified SRUs that'd comment on bugs and call remove-package. While I've written something its hard for me to use as I can't remove packages.
<bdmurray> s/use/test/
<bdmurray> Can I be added to some team temporarily?
<infinity> bdmurray: You can call remove-package against a PPA.
<bdmurray> I guess if I get a 401 its trying to do the right thing.
 * infinity curses at cron.source crashing.
<infinity> Riddell: plasma5 is dead, right?
<Riddell> infinity: kubuntu-plasma5 is yes
<Riddell> plasma5 itself is now part of kubuntu normal for vivid
<infinity> Riddell: Kay, we should rid cdimage of any mention of it, but I'll do that after the point release.
 * infinity just fixes the trusty oops for now.
<elfy> infinity: best that I can do for now https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/ChangeSummary/14.04.2
<elfy> date info at beginning needs to be done
<elfy> having to dash and do some r/l thing for a bit now - bbl
<infinity> elfy: Looks lovely to me, thanks.
<elfy> your welcome(ish) :p
<infinity> Riddell: Time's running out, how are the new kubuntu images looking?
<infinity> ScottK: Or maybe you have a better answer (or at least a better timezone) than Riddell?
<Riddell> infinity: let me ask
<infinity> Riddell: Given that they're nearly identical except for the bug you fixed, a solid boot/install/reboot smoketest should be mostly enough to say they're good, I think.
<Riddell> yeah let me run one test and I think that's fine
<wxl> question: how often are point releases supposed to come out?
<wxl> pheverything but alternate
<wxl> yes please
<wxl> omg
<wxl> wrong channel as always
<infinity> wxl: 3 months after release for the first one, then every 6 months after that until .5
<infinity> wxl: Basically, staggered about halfway between regular releases.
<jderose> infinity: so the above notices from queuebot: did those ubuntu ISO get rebuilt, or is this .1 from yesterday just renamed?
<infinity> jderose: Nothing renamed or respun, just marking as ready.
<jderose> gotcha, thanks. just trying to understand a bit how the process works :)
<wxl> infinity: why do some releases only have 4 or 3 point releases?
<infinity> wxl: lucid had 4 point releases because the 5th would have been after precise came out, and that's the upgrade path we wanted people to take.
<infinity> wxl: precise had 5 because, even though we'd prefer people upgrade to trusty, we were also providing the trusty HWE stack in .5 for people who wanted to stay on precise.
<infinity> wxl: trusty will be the same, with .5 shipping the 16.04 HWE stack.
<wxl> infinity: so .5 from here on out?
<infinity> wxl: Basically, it's the HWE thing that added the last one.
<wxl> ko
<infinity> wxl: If we find a better way to do HWE in the future, we might revisit, but this is what we've got for now.
<infinity> wxl: It does mean, annoyingly, that we have to do old.5 and new.1 at the same time, but .1 is usually no effort, since it's just an SRU rollup with no HWE bits, etc, so it's not terrible.
<wxl> thanks for the heads up infinity :)
<wxl> infinity: you going to give us until tomorrow morning for the official release?
<infinity> wxl: No, I plan to do it in the next few hours.
<wxl> infinity: darn.
<infinity> wxl: Why darn?
<wxl> infinity: oh i'm just struggling to get the wiki team working on stuff
<wxl> infinity: and i'm tryuing to avoid really hard doing it myself :)
<infinity> wxl: Shouldn't be much to work on?
<wxl> infinity: it's not, but i've got a stack of stuff piling up on me at work
<infinity> wxl: The ReleaseNotes didn't move, you just have to change 14.04.1 to 14.04.2 and add a short paragraph about how there are no 14.04.2 alternates, but people can use the 14.04.1 ones, and done.
<stokachu> SIGH
<stokachu> infinity: can you fix my blunder
<infinity> stokachu: That was meant to go to a PPA or something?
<stokachu> apparently my dput.cf doesn't null out default
<stokachu> infinity: yea :(
<stokachu> infinity: thanks man
<infinity> stokachu: Is that true of the one you uploaded to vivid too?
<stokachu> infinity: nah vivid is for real
<stokachu> i gotta do some back port requests for trusty on that
<infinity> stokachu: Also, stop putting -proposed in your changelogs. :P
<infinity> stokachu: That hasn't been necessary for years.
<infinity> (And, in fact, was never necessary for the devel series)
<stokachu> infinity: ah sorry about that
<stokachu> the bot was so thoughtful to automatically rename it for me :)
<stokachu> so i have [DEFAULT] fqdn = null and incoming = null in my ~/.dput.cf
<stokachu> but it still uploaded to ubuntu
<infinity> default_host_main?
<infinity> default_host_main       = ubuntu
<stokachu> i dont have that one set
<infinity> ^-- From /etc/dput.cf
<cyphermox> stokachu: might want something like http://paste.ubuntu.com/10314769/
<stokachu> ah ok perfect
<bluesabre> any archive admins about? Please release https://launchpad.net/ubuntu/+source/lightdm-gtk-greeter-settings to vivid so we might be able to add it to the xubuntu seed :)
<Riddell> infinity: â
<infinity> bluesabre: I'm mildly entertained that the only translation that contains is Russian. :)
<amjjawad> hi infinity
<amjjawad> http://cdimage.ubuntu.com/ubuntu-gnome/releases/14.04.2/release/ << is showing 14.04.1 instead of 14.04.2
<bluesabre> infinity: yes... we hope to improve that in the immediate future :D
<amjjawad> not just the text infinity but the links as well
<infinity> amjjawad: Give it time.
<infinity> amjjawad: rsync isn't instant.
<amjjawad> infinity, okay, just thought to report that :)
<infinity> Riddell: Handy, cause I just pushed to mirrors about when you did that, figuring I could delete later if you told me I was wrong. :P
<bluesabre> infinity: thanks :)
<flexiondotorg> infinity, Thanks also. Ubuntu MATE is using lightdm-gtk-greeter-settings
<flexiondotorg> also
<infinity> It's nice to see flavours get along. :)
<bluesabre> (we agree)
<elfy> do we?
<elfy> :D
<amjjawad> is this the best answer for point releases? http://askubuntu.com/questions/106159/what-are-point-releases-in-lts-versions
<amjjawad> AFAIK, the major difference is: newer Linux kernel, bug fixes and updated packages - please correct me if I'm wrong
<amjjawad> another Q: https://wiki.ubuntu.com/Kernel/LTSEnablementStack AKA HWE is ONLY available from 14.04.2 (AKA the 2nd point release)  correct? at least, this is what the page is saying but I just want to make sure!
<infinity> amjjawad: That's correct, since the HWE stack is based on the previous non-LTS release, and there wasn't one before .1
<infinity> amjjawad: So, .2 is after 14.10, .3 is after 15.04, up to .5, which is after 16.04
<amjjawad> infinity, thank you. But what is the 'best' for 'new' users with 'new' installation? is it about which hardware they're using? or they can just go ahead and stick to the latest which is at the moment 14.04.2 ?
<infinity> amjjawad: For new desktop users, the latest point release is probably the "best".
<infinity> amjjawad: For server types, there's more evaluation required, I think.  If all their kit is supported with the trusty kernel, having some on 3.13 and some on 3.16 is confusing, and being on 3.16 means being forced to upgrade to 16.04 (or 14.04+16.04), as we drop support for the interim HWE stacks, etc.
<amjjawad> infinity, thank you again. That is also an answer to whether I have to update the release notes with the latest (14.04.2 for now) or not. I usually update it with the latest point release. So, the newer people read the newest information. No one with 14.04 installed will go back to the release notes, that if and only if they have read that anyway to begin with.
<amjjawad> I think for servers, they should stick to the most stable not the most recent IMHO.
<elfy> infinity: thanks for the hard work fixing stuffs :)
<wxl> seriously, infinity. you went over and above the call of duty.
<elfy> and if in future you want me to do anything like that again - while I would be more than happy, a bit more notice - that was nasty job indeed :D
#ubuntu-release 2015-02-20
<infinity> bdmurray: You still around?
<infinity> bdmurray: If so, can you bump 14.04.1 to 14.04.2 in metarelease?
<wxl> infinity: i'm about to head out in 30 mins or so. any chance of being done by then?
<infinity> wxl: Just fiddling with the website, but should be releasing very shortly.
<elfy> ohhh
<elfy> sorry infinity - though the shout went out ... bad elfy :(
<bdmurray> infinity: still need that metarelease change?
<infinity> bdmurray: Yeah, unless I have access and don't know it.
<infinity> bdmurray: But someone would need to point me at the branch to mangle.
<bdmurray> infinity: I can do it
<infinity> elfy: Eh, from an infra POV, it's all out, except for the ubuntu.com website and my announce email.
<infinity> elfy: Nothing stopping flavours from announcing if they want to.
<elfy> right - saw so much words - I just read the few I wanted to :)
<elfy> yea - but I do like to wait for the nod - only polite :)
<bdmurray> infinity: all done
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Utopic 14.10, Vivid Alpha 2 | Archive: open | 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
<rsalveti> stgraber: seems the system-image importer is commented out in nusakan
<rsalveti> stgraber: was that on purpose?
<stgraber> rsalveti: I don't know
<stgraber> you should ask whoever commented it :)
<rsalveti> stgraber: how to know that?
<rsalveti> we got our possibly rtm image for ota out, but didn't show up in system-image yet (to be validate by QA), and just noticed it was commented out
<stgraber> you can't really, just guess. ogra_ is usually a pretty safe bet :)
<stgraber> or maybe slangasek knows
<rsalveti> stgraber: right, guess will just run it now manually and see if we can import at least the current rtm image
<ScottK> infinity: Now isn't it time for the "Hey - feature freeze" email?
 * bluesabre managed to get everything xubuntu pushed before the email
<infinity> ScottK: It is, I just haven't sent it.
<ScottK> K.
<infinity> ScottK: If you want to do the honors, be my guest, I'm eating dinner. ;)
<ScottK> Wouldn't want you to get to comfortable and relaxed.
<infinity> Heh.
<ScottK> Let me see what I can whip up before a spouse or child appears.
<ScottK> It's vivid vervet, right?
<infinity> ScottK: Last I checked.
<ScottK> Sent.
* ScottK 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
<ScottK> infinity: It needs to be moderated.
<infinity> ScottK: Done.
<ScottK> Thanks.
<infinity> ScottK: Those looked suspiciously like my words. :)
<infinity> ScottK: Or I'm rubbing off on you.
<ScottK> The similarity was non-random.
<rbasak> I hope you used a Sender: header? :-)
<slangasek> stgraber, rsalveti: sorry, that was my doing, there was some ubuntu-core s-i damage that I needed to fix and I forgot to re-enable it
<slangasek> re-enabled now
<infinity> Does anyone else ever get an uncontrollable urge to watch the Tunak Tunak Tun music video?
<infinity> No?  Just me?
<slangasek> never heard of it
<infinity> slangasek: Really?  Did you not have the Internet in 1998?
<slangasek> I did, but perhaps not the Canadian Internet
<rsalveti> holy, that's old
<rsalveti> that was everywhere
<rsalveti> slangasek: thanks
<rsalveti> still good though :-)
<slangasek> I guess this was filmed on the set of DOOM II
<ogra_> rsalveti, stgraber, i always notify this channel if i turn the importer off or on
<cjwatson> auto-sync belatedly switched to dry-run
<flexiondotorg> Would is be possible to try a build for Ubuntu MATE?
<flexiondotorg> cyphermox, Has helped get the backend stuff integrated.
<flexiondotorg> I'd like to see how far along it gets so I can fix things if required.
<Mirv> would someone friendly accept the binnew simgear packages from the queue? I believe I'd have all openscenegraph 3.2.1 bits uploaded but simgear is needed to unlock the rest of the builds
<caribou> Does the PlusOne maintenance team still exist ?
<cyphermox> cjwatson: in case you're still around, could you kick off a mate build?
<cyphermox> flexiondotorg: ^
<cjwatson> cyphermox: done
<cjwatson> failed immediately :)
<cyphermox> awesome, thanks :)
<cjwatson> ah, I know what we need, there's a production config branch
<cjwatson> let me fix
<cyphermox> could you tell me more? to share the wealth of knowledge and all of that even though I'm not on the release team ;)
<cjwatson> should be building now
<cyphermox> ok
<cjwatson> well you can't see the branch without access to nusakan
<cyphermox> oh ok
<cjwatson> it has private data and such
<cjwatson> it's mentioned in https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<bdmurray> Could somebody run the -proposed cleanup on the pending-sru report?
<cjwatson> bdmurray: running
<bdmurray> cjwatson: thanks, is there anything wrong with two factor auth and staging.launchpad?
<cjwatson> bdmurray: what are you seeing?
<cjwatson> you have to use a different 2fa setup for staging sso remember
<bdmurray> oh, its been awhile since I've used staging
<cjwatson> bdmurray: https://help.ubuntu.com/community/SSO/FAQs/2FA#Why_doesn.27t_my_2F_login_work_on_staging.3F
<bdmurray> cjwatson: thanks
<elfy> infinity: so ... our 32 bit images still get the fail in vbox, running it from kvm - it only passes because it just sits there waiting for *you* to choose between try or install at the first boot menu
<elfy> if nothing else it would be good to have an idea of who we could actually talk to about it :)
<bdmurray> slangasek: sru-remove tool mp at https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/sru-remove/+merge/250492
<infinity> elfy: Point me at the bugs, maybe I can at least sort out who's responsible. :P
<elfy> bug 1423161
<ubot93> bug 1423161 in ubiquity (Ubuntu) "No try/install dialogue displayed" [High,Confirmed] https://launchpad.net/bugs/1423161
<elfy> infinity: I did try with kvm :)
<elfy> thanks though :)
<infinity> elfy: Seems pretty unlikely to be a ubiquity bug if it only happens on one type of "hardware".
<elfy> oh - I did report it syslinux too - hard to know what to report it against
<elfy> bug 1423267
<ubot93> bug 1423267 in syslinux (Ubuntu) " No try/install dialogue displayed " [Undecided,New] https://launchpad.net/bugs/1423267
<infinity> elfy: That seems even less likely, assuming you're talking about an X desktop. :)
<elfy> http://iso.qa.ubuntu.com/qatracker
<elfy> those bug reporting instructions are what we get :)
<elfy> hard to know what to do
 * infinity wonders what the "Xubuntu Core" product on the tracker is meant to be.
<cyphermox> I wonder if that could be related to that "being unable to select OEM install" on some images bug that I've been looking at
<infinity> cyphermox: Oh, if he's actually referring to gfxboot?  Maybe.
<cyphermox> yes
<infinity> elfy: Do you have a screenshot from a working system of the screen you think you're meant to be seeing? :P
<infinity> cyphermox: See, I'm assuming it's the dialog in X that has try/install.
<cyphermox> elfy: or a screenshot of the screen you're seeing when things are stuck
<cyphermox> infinity: yeah
<cyphermox> but ubiquity is *meant* to wait for you to click Try or Install when you've gone through the gfxboot timeout, AFAIK
<infinity> cyphermox: Right, but it's also meant to display a pretty dialog explaining that.
<infinity> Which it might not be.
<cyphermox> yes
<cyphermox> could be
<infinity> But that would still not be a ubiquity bug if it's hardware-specific.
<infinity> More likely X has partially exploded.
<cyphermox> unity
<infinity> And the window is there, but not so much with the visible.
<cyphermox> oh wait
<infinity> XFCE, no Unity.
<cyphermox> yes, I realized that
<Laney> There's no unity at that point in ubiquity anyhow
<infinity> But xfce also does hardware compositing by default (just much, much, much less hardware taxing), so it could be an accelerated driver thing with the vbox drivers, or lack thereof, on the CD?
<cyphermox> Laney: well, ubiquity-dm might be trying to start something in setting up the session and failing to do so
<infinity> Laney: Oh, is that dialog pre-window-manager?  You're probably right.
<cyphermox> we'll know exactly, or much better, with a screenshot
<elfy> http://i.imgur.com/rDCyE0O.png
<elfy> 64bit on the left :)
<cyphermox> ah, ubiquity-dm perhaps.
<infinity> Okay, that's the dialog I assumed you were talking about.
<infinity> So, some very verbose printf-debugging of ubiquity-dm might show up what's happened.
<cyphermox> I'm not sure exactly what starts when you go through that dialog
<infinity> cyphermox: I'll leave that one with you. :)
<elfy> thanks for looking :)
<cyphermox> elfy: are we still talking trusty?
<infinity> cyphermox: Given the full desktop is otherwise loaded, I'm skeptical about blaming X/drivers, so ubiquity itself might be having a sad.
<elfy> no - this is vivid - those are both today's daily
<infinity> cyphermox: This is vivid/i386
<infinity> cyphermox: xubuntu.
<cyphermox> good, I had hoped so
<elfy> I do understand that vbox can be a pita
<infinity> elfy: Stupid question, but I assume those yellow dots are part of the wallpaper, not rendering artifacts from the window shooting itself in the head? :P
<elfy> yea - that wallpaper is how it should look :)
<infinity> Kay.
<infinity> Wallpaper that looks a lot like video tearing is kinda entertaining.
<cyphermox> elfy: is there a ubiquity process?
<cyphermox> it already set up the panel and wallpaper so it at least got through some piece of setting up the session
<elfy> cyphermox: appears to be http://i.imgur.com/T2YgMde.png
<cyphermox> thanks
<infinity> Neat.
<infinity> cyphermox: I'm having a really hard time seeing how this could be ubiquity's fault, but I think this is one of those "have to prove it's not us, so we can reassign to the real culprit with a vengeance" type bugs.
<cyphermox> yeah
<cyphermox> will probably need .xsession-errors at this point, and/or syslog
<elfy> what is interesting is that yesterday 64bit gave the same result
<cyphermox> I did install vbox here so I'll spin it real quick to see if I get the same thing
<elfy> ok - I'm floating about - grub time in UK - and ravenous teenager
<cyphermox> phablet_demo: hi Will!
<cyphermox> how does one not get just garbage graphics in virtualbox again?
<elfy> hostF1 then hostF2
<elfy> usually right ctrl
<cyphermox> I still get a screen of green lines and a mouse the size of my head
<cyphermox> ok
<cyphermox> ahh!
<cyphermox> got the dialog though
<cyphermox> elfy: was the vm set to 64bit and you ran the 32 bit image?
<cyphermox> ah, got it, no dialog
<elfy> cyphermox: nope and good :)
<cyphermox> but also no useful logs
<cyphermox> things look fine, nothing weird in ubiquity's logs
<cyphermox> it says it's trying to use DISPLAY=:0 which is also right
<elfy> I know last cycle there was one thing after another with vbox
<cyphermox> elfy: I only got this when I used a 64-bit vm to run the 32-bit image though
<elfy> infinity: and xubuntu core is a stripped down racing version of xubuntu installed from mini.iso
<cyphermox> so I could try to start the same image on real hardware and see if it does something similar
<elfy> cyphermox: I'll double check and build a new vm - but I don't think that's the issue
<elfy> cyphermox: it does boot on hardware fine
<cyphermox> eep, if I kill off the ubiquity process I get thrown into a proper session, which is good, but I see there are still some graphic issues -- lots of tearing around the pointer
<infinity> elfy: Okay.  Just seems weird to list it as an ISO product, but as long as that doesn't break publishing scripts, whatever.
<cyphermox> infinity: adding xubuntu core?
<elfy> infinity: it's not new - was there last cycle
<infinity> elfy: Really?  I guess I have a short memory.
<infinity> elfy: Although, I don't see it on the Utopic Final milestone.
<elfy> seemed the only way to get it on the tracker was like that - we just wanted it to chug along cycle
<elfy> infinity: no - it just shows up on dailies
<infinity> elfy: Check.
<elfy> if that's wrong blame balloons :D
<infinity> elfy: Nah, don't care, if it's working for everyone, I'll just ignore it.
<elfy> it's something we're actively looking at - but it's a bit of a corner case
<cyphermox> elfy: if you could, start the same cd to reproduce the issue but edit the command line (ie, you don't just let things time out), to add 'maybe-ubiquity debug-ubiquity', and then put /var/log/installer/debug and /var/log/installer/dm on whatever bug report you may have open about this
<infinity> cyphermox: Confirmed your 32-on-32 works, 32-on-64 doesn't findings.
<cyphermox> infinity: yay
<infinity> cyphermox: For bonus points, on a Win32 installation of vbox (it's on my gaming desktop :P), so you can rule out host kernel weirdness.
<elfy> cyphermox: ummm, I'll do that if you can give me a bigger clue :)
<cyphermox> this makes it sound a little less critical to me, because if that fails and it works fine on hardware, I expect people bringing up VMs to more or less use the right bitsize for the image they try to run... not that it shouldn't be fixed anyway
<elfy> or do you mean at grub?
<elfy> cyphermox: I just built a new vm - double checked it was 32bit - same issue
<cyphermox> elfy: well, at grub if you get grub, or when you get the splash for the cd, press a key to get the menu, then hit F6, ESC and type that before the -- at the end of the command line
<cyphermox> elfy: ok
<cyphermox> elfy: then it's even more worth your time trying this out
<cyphermox> hmm.. I may have just gotten the same result
<cyphermox> infinity: guess it's some race, 32-on-32 failed for me too
<infinity> cyphermox: Well, that's actually more comfortin from a WTF perspective, but it does mean the bug is probably ours, not Oracle's. :P
<cyphermox> heh
<cyphermox> maybe I see something a little unusual here
<cyphermox> elfy: you do have to switch VTs to not get garbage on screen, right?
<elfy> sometimes - not always
<elfy> unless I boot an Ubuntu vm - then always
<cyphermox> right
<cyphermox> ah, this definitely needs more testing. If I can get another case where the window does show\
<cyphermox> infinity: did you flush your vm yet?
<cyphermox> if you could DISPLAY=:0 xwininfo -name ubiquity that would be cool if you still have your vm running
<cyphermox> ah, the window is definitely there, just off-screen
<cyphermox> if only I could remember the key combo to move windows from the keyboard
<elfy> cyphermox: added both to bug 1423161
<ubot93> bug 1423161 in ubiquity (Ubuntu) "No try/install dialogue displayed" [High,Confirmed] https://launchpad.net/bugs/1423161
<elfy> back shortly
<cyphermox> elfy: thanks
<cyphermox> heh, if you just press up or down a bit it pops back up
<infinity> cyphermox: Oh, so just a positioning issue?  Perhaps the driver is reporting the wrong screen size at just the wrong time before the desktop settles?
<cyphermox> no, not a positioning issue
<cyphermox> I just got the window to display from boot and the resulting xwininfo is the same
<elfy> oh ...
<cyphermox> so looks like it someone is hidden
<cyphermox> it's right there in the middle of the screen, when it's not showing you can hit up and down to switch languages and it will drawn on the screen again
<elfy> hah so changing where the cursor is - language and it shows up
<cyphermox> yup
<cyphermox> I'm kind of curious if it's not ** (xfdesktop:2205): CRITICAL **: xfdesktop_grid_is_free_position: assertion 'icon_view->priv->grid_layout != NULL' failed that is a hint as to why this is happening
<cyphermox> nope, it's there on my "successful" run too
<cyphermox> brb, I need to secure beverage, apparently we still need to boil water here
<cyphermox> elfy: infinity: i may have a fix but it's a little hard to be certain just like this that I'm not ignoring some critical use case
<cyphermox> but my wild guess is that in general when we run the installer we really want it to be visible, so I'm just making that explicit as it starts.
<cyphermox> looks like it works but I don't always hit the bug anyway
<infinity> cyphermox: I can't think of when we'd not want it to be visible in the frontends, at least.
<infinity> cyphermox: Is this code GTK-specific?
<infinity> cyphermox: If so, I'm pretty confident no one wants an invisible GTK ubiquity.
<cyphermox> I'm putting it in the gtk_ui frontend only
<cyphermox> yeah, but I'm still figthing this trying to be very sure the bug fixes it, and that I'm not just lucky.
<cyphermox> *code fixes it
<cyphermox> especially when I'm further complicating things by breaking the boot to edit files before ubiquity has a chance to start
<infinity> cyphermox: Well, be a bit sciency about it.  Break the boot and *don't* edit files, and see if you can still hit the race reliably.
<infinity> cyphermox: Then break and edit, and see if you can't.
<cyphermox> I did
<elfy> thanks for this :)
<cyphermox> that's what I've been doing, so far haven't hit one case where I edited the file and the dialog didn't show
<infinity> cyphermox: But I vaguely recall other gtk visibility issues (or, rather, the need to forcefully tell it YES I WANT A WINDOW YOU TWIT) in the past, so you're probably on the right track, just need to make sure you call it dead last after the UI is drawn, so it doesn't blink in and out of existence, I suspect.
<cyphermox> hehe yeah ;)
<cyphermox> flexiondotorg: btw, livefs build failed for mate, that needs to happen before it gets much CD done, I wonder if there isn't another package that is in the seed that hasn't made it in Ubuntu yet.
<cyphermox> flexiondotorg: really it could be anything though -- https://launchpadlibrarian.net/198284153/buildlog_ubuntu_vivid_amd64_ubuntu-mate_BUILDING.txt.gz
<cyphermox> infinity: could you please review mate-menu and mate-tweak source packages in the new queue? they should have been landed prior to feature freeze, leaf packages for a flavor we don't yet quite build, etc. ;)
<cyphermox> actually, fairly critical packages for these, but still :)
<infinity> cyphermox: Yeah, I'm not going to ask for a FFe for most MATE stuff, except when they have to touch packages shared with other flavours.
<robru> infinity: you around? can you figure out what happened to telepathy-qt5? it's in the PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-025 and in the packagelist https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/22/artifact/packagelist_rsync_landing-025-vivid/*view*/ but it didn't even get to proposed while telepathy-ofono
<robru> is already in vivid. also cicopy.log doesn't show any error.
<infinity> robru: No idea, copy it again?
<robru> infinity: oh, hm, the packagelist is invalid....
<robru> sigh
<robru> ok
<bdmurray> infinity: is there something missing here? http://cdimage.ubuntu.com/ubuntu/releases/14.04.2/release/
<infinity> bdmurray: I don't know, is there?
<bdmurray> I only see amd64+mac not amd64 for 14.04.2
<infinity> bdmurray: Are you maybe looking for http://releases.ubuntu.com/14.04.2/ ?
<bdmurray> yeah, maybe
#ubuntu-release 2015-02-21
<teward> what do I need to do to get an FFe for a sync req for something in Universe?
<ari-tczew> !FFe
<ubot93> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<ari-tczew> teward: ^
<teward> well... the bug already exists, I believe I have to modify it for FFe
<ari-tczew> do it ;)
<infinity> teward: Just ask.  For most of universe, the default answer is "go nuts".
<bluesabre> :)
<ScottK> infinity: getdns has a soname mismatch problem that's just now fixed in Debian.  Can I get an IRC FFe from you and will you take care of binary New?  There's one rdep and I'll take care of it.
<teward> infinity: well, the bug exists, but i want to follow the process anyways - i want to make sure there's not an FTBFS (ran into a nondeterministic FTBFS in a test build on my local sbuild instance on a system here at home, want to make sure it wasn't a glitch, so i'm running the build again with a brand new schroot)
<teward> besides, thorough testing means less fails later on :0
<teward> :) *
<teward> infinity: it's also not a package i maintain, just one i try and nudge along :)
<infinity> teward: Sounds fine by me.
<infinity> Err.
<infinity> ScottK: ^-- That was for you.
<ScottK> thanks.
<teward> infinity: heh :)
<elfy> infinity: we has try/install dialogue \o/  thanks to you and cyphermox - lovely to work with you :)
<ScottK> infinity: ^^^ that's all of them.
<infinity> ScottK: I, too, can count to six. :)
<ScottK> Wasn't sure how closely you were watching.
<infinity> That closely.
<ScottK> Apparently.
<ScottK> Conveniently, the rdepend (python-getdns) was depwait on this newer version, so I don't even need to upload a no change rebuild.
<infinity> Handy.
<ScottK> Of course the version sync'ed from Debian was fubar, so it needed an upload anyway ...
<teward> ScottK / Logan: Thanks for looking at the znc sync - i was just spinning up the VM too when the FFe was approved and the sync happened, thanks again!
<Logan> sure :)
<ScottK> yw.  Fortunately FFe aren't coming in too fast and furious yet, so it's easy to keep up.
<teward> ScottK: well, FF was only yesterday, no?  I actually filed that bug just before FF, but because Debian hadn't caught up yet, well... :P
 * ScottK waits for Adam to count to six again.
<Logan> ScottK: how about my ~ubuntu-archive bugs? ;)
<ScottK> Maybe later.  Actually I'm about to be AFK for awhile.
<infinity> ScottK: I was otherwise occupied. ;)
<Logan> it's okay, infinity can take care of them
<Logan> I think some package removal requests are still open from the trusty cycle
<infinity> Logan: No promises.
<Logan> :P
<infinity> ScottK: That was an impressive number of fixes required for python-getdns.
<ScottK> infinity: Yeah.  All clearly from the DD only building in a dirty environment.
<infinity> ScottK: Yep, it's failed on all arches except the one he uploaded on.
<ScottK> Fortunately it's in DPMT, so I just fixed it in Debian too.
#ubuntu-release 2016-02-22
<jamespage> anyone else noticed that the SRU report is not updating?  http://people.canonical.com/~ubuntu-archive/pending-sru.html
<flocculant> Odd_Bloke: thanks :)
<flocculant> yofel superm1 stgraber - any of you doing xenial beta 1
<flocculant> infinity: so - any idea of who's doing the release-team bit yet?
<knome> infinity, also, what's the status of the "base" merges? :X
<Odd_Bloke> flocculant: :)
<cyphermox> flocculant: you should still see both, low disk should show a screen that is titled "Sorry" and has just how much space you have and how much is needed, and no connection should have the updates checkbox disabled and a caption under it that says why
<lotuspsychje> can some check if a package hits xenial for enyc?
<lotuspsychje> mythtv 0.28
<ginggs> lotuspsychje: mythtv FTBFS on some archs https://launchpad.net/ubuntu/+source/mythtv/2:0.28.0+fixes.20160217.44fd8a6-0ubuntu1
<lotuspsychje> ginggs: thank you! enyc ^
<apw> qmake for Qt5.2 or newer not found.
<flocculant> cyphermox: ok - cool, not seen the no internet one - assumed there'd be something in that case :)
<cyphermox> you did see the space one though?
 * davmor2 shakes his fist at cyphermox dude why you make ubiquity crash?
<cyphermox> does it crash now?
<flocculant> cyphermox: yep - 8Gb not enough for Ubuntu :)
<cyphermox> err, that's probably wrong
<flocculant> seems to want 8.6Gb iirc - not often booting ubuntu image
<cyphermox> ok.. well I'm going to have to try a few images and flavors to see
<davmor2> cyphermox: on current with the check sum of 09bc9cec32f7cd49270f165b81390d7a  iso/daily-live/current/xenial-desktop-amd64.iso on macbook pro
<cyphermox> ok
<davmor2> all intel mac that is
<cyphermox> davmor2: would need to know what the crash is. you'll file a bug?
<davmor2> cyphermox: about to if I can get the wifi to connect
<xnox> flocculant, if your RAM >> disk space then yes partioner does things weridly. Are you testing in a VM with a weirdly sized config?
<xnox> davmor2, ^ ?
<davmor2> 268699
<xnox> bug 268699
<ubot5> bug 268699 in Empathy "empathy crashed with SIGSEGV in tp_connection_run_until_ready()" [Critical,Fix released] https://launchpad.net/bugs/268699
<xnox> davmor2, is that your phone number? or sudo password?
<davmor2> xnox: no
<davmor2> xnox: otp in the wrong window :)
<flocculant> cyphermox xnox: possibly - vm with 2Gb ram in a 8Gb drive - anyway - my ping was really just about the change - not how much space something needs - I'd actually only have concerns if it was xubuntu :)
<davmor2> xnox, cyphermox: bug 1548362
<ubot5> Error: Launchpad bug 1548362 could not be found
<davmor2> xnox, cyphermox: subscribed you both so you should have access
<xnox> flocculant, is this a real machine or a VM? i believe swap is generated to be 1x or 2x of RAM, i can't remember, and then there is not much disk space left. we have the weird swap calculation, so do use "normal" machines, were disk drive is >> RAM.
<xnox> davmor2, strange. upower doesn't exist anymore....
<utlemming> could I bother a core-dev for a merge of https://code.launchpad.net/~utlemming/livecd-rootfs/v380/+merge/286806 ?
<xnox> does it?
<davmor2> xnox: mine is a macbook pro 2011 all intel iirc
<flocculant> xnox: vm - so if it did 1x with the ram I give then - then leaves 6.something Gb for install
<davmor2> might 2013 it's been a while anyway :)
<xnox> flocculant, and the argument is that with 6GB of disk space, there is not enough space to a) ever install any additional apps b) store any documents/photos/music/files
<xnox> flocculant, do thin provisioning/non-preallocated 20GB drive or some such, if you are testing in a VM.
<flocculant> xnox: yea - I'm not complaining at all - this is JUST about me wanting to double check that things were supposed to be missing from ubiquity now :)
<flocculant> I didn't want a discussion about disk sizes :)
<xnox> flocculant, ubiquity fails to install whenever disk ~= RAM size. and it's not a bug =)
<xnox> it has always been the case.
<flocculant> dude - I know - you're reading too much into my comments :p
<flocculant> I have NO idea at all - how much space ubuntu would want - I don't use it - I only ever install it to check if a bug I see is global or just xubuntu
<davmor2> xnox, jibel, cyphermox: http://paste.ubuntu.com/15171252/
<cyphermox> davmor2: so, clearly upower got broke
<davmor2> cyphermox, jibel: oddly works on vm with the same image
<cyphermox> davmor2: oh, I think I know what this is
<cyphermox> or have an idea, anyway
<Odd_Bloke> slangasek: Your switch to a plain rootfs broke some of our outside-of-buildds code, so I've opened https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ext4/+merge/286809 to (partially) revert it; I've retained the hard-coding because (as you identified) building with an alternative type of rootfs doesn't make sense.
<xnox> Odd_Bloke, slangasek is on 4 week holiday =)
<superm1> flocculant: it's not looking good to me for mythbuntu.  mythtv 0.28 didn't make it out of proposed still, mythtv isn't building on non-x86 stuff properly, we're not really sure why but that will blcok the proposed migration
<Odd_Bloke> xnox: Yeah, I know; I'm going to bug someone else soon. :p
<tgm4883> superm1: isn't it specifically just arm64?
<superm1> tgm4883: and s390x, ppc64el, powerpc
<tgm4883> ah
<superm1> i mean i personally don't think anyone is going to be running mythtv on anything but x86 and arm, but anyway..
<cjwatson>     CHECK_QMAKE="qmake-qt5 /usr/lib64/qt5/bin/qmake /usr/lib/x86_64-linux-gnu/qt5/bin/qmake /usr/lib/i386-linux-gnu/qt5/bin/qmake /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake /usr/local/lib/qt5/bin/qmake $qmake"
<cjwatson> none of those look very clever
<cjwatson> maybe pass --qmake=/usr/bin/qmake to mythtv's configure as well as to mythplugins?
<flocculant> superm1: thanks :)
<superm1> cjwatson: we did some test builds on a PPA to look more into it and i want to say it tried /usr/bin/qmake and wasn't working still.  tgm4883 where is that test build?
<superm1> tgm4883: i thought it was on ~mythbuntu/master-building but maybe teh logs got destroyed when you copied the x86 builds
<xnox> superm1, however arm64 should kind of work. i'm poking darkness with a stick in a ppa.
<tgm4883> looking
<superm1> yeah the test build was trying to give some more verbosity to that error
<cjwatson> https://launchpad.net/~mythbuntu/+archive/ubuntu/master-building/+build/9028662 exists and is a little different
<cjwatson> found qmake at /usr/bin/qmake but version failed
<tgm4883> https://launchpadlibrarian.net/240280457/buildlog_ubuntu-trusty-arm64.mythtv_2%3A0.29.0~master.20160218.e4fface-0ubuntu0mythbuntu3_BUILDING.txt.gz
<tgm4883> cjwatson: yea that's the error
<tgm4883> found qmake at /usr/bin/qmake but version failed
<tgm4883> qmake: could not find a Qt installation of ''
<superm1> which makes me wonder if qmake is misconfigured in the chroot?
<cjwatson> perhaps this is a QT_DEFAULT=5 thing or whatever the syntax is
<cjwatson> QT_SELECT=5, sorry
<superm1> that's for when you have 4 and 5 side by side though right?  shouldn't be needed when only 5 is around?
<cjwatson> yeah
 * xnox is downloading all the build-deps in an s390x chroot....
<cjwatson> looks like you're just missing some Qt-related build-dep, anyway, question is which
<xnox> libqtmirclient1-not-ported-dev </joking>
<xnox> (xenial-s390x)root@DEVAC02:~# QT_SELECT=5 qmake -version
<xnox> QMake version 3.0
<xnox> Using Qt version 5.5.1 in /usr/lib/s390x-linux-gnu
<xnox> (xenial-s390x)root@DEVAC02:~# qmake -version
<xnox> qmake: could not find a Qt installation of ''
<Odd_Bloke> xnox: Speaking of bugging people, I notice that you could merge https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ext4/+merge/286809 ^_^
<xnox> sounds like export QT_SELECT=5 is the thing.... /me ponders what makes it work on  [x86 + armhf]
<Odd_Bloke> xnox: (For context, we're pinned on an old version of livecd-rootfs until this happens <coercion>which will make fixing any s390x problem tricky</coercion>)
<cjwatson> QT_SELECT=5 does indeed make a difference here
<cjwatson> superm1: ^- I'd suggest exporting that and trying
<tgm4883> superm1: so how do we add that to our packaging?
<cjwatson> export QT_SELECT = 5 in debian/rules
 * xnox ponders if our qt5 is borked somehow
<tgm4883> that's what I figured
<xnox> Mirv, qmake is weird. On armhf,i386,x86_64 there are two of them built "armhf" and "native", and on those arches, installing qt5-qmake "qmake -version" just works.
<xnox> Mirv, but on all other architectures requires an export of QT_SELECT=5 to "find" the qt installation.
<jderose> infinity: could you point me to the tools you use to build the daily/release ISOs? I'd like to build up-to-date 15.10 ISOs (desktop and server) to master System76 images from, so i can avoid any chance of USN-2900-1/CVE-2015-7547 compromising the VM during the initial update
<infinity> jderose: Surely, you install/update on an isolated network?
<jderose> infinity: yes, but the VM still makes network requests that get sent to the outside world. short of disabling networking, i'm not sure there's a reasonable way to work around this.
<jderose> plus, i've always wanted to know how the ISOs are built anyway :)
<infinity> jderose: I can point you at livecd-rootfs, live-build, cdimage, and debian-cd, but you won't like what you find (and certainly won't like it for a one-off respin) :P
<jderose> infinity: hmm, i always hope there was just a magic button you pushed :P
<infinity> jderose: If you ask really nicely when I'm not on VAC, though, I could be pursuaded to do a one-off daily of wily for you.
<davmor2> jibel, cyphermox: so played with live desktop mode on hardware and vm both look okay so just that upower issue so far oh and the fact that the new store is missing from the launcher.
<jderose> infinity: ah, didn't realize you were on vacation ATM. sorry about that, ignore me and enjoy your time off
<infinity> jderose: That said, I'd suggest your network should just be more isolated.  Authoritative nameserver with limited outside resolution, local mirrors, etc.
<xnox> cjwatson, superm1 - build-dependency resolution is somehow off, so on some architectures one ends up pulling in libqtcore4 which has default preset to qt4, on other architectures only qt5 is pulled in which doesn't have such a default.
<xnox> unless i'm doing something wrong, let me try again.
<xnox> actually i'm wrong.
<xnox> superm1, on both amd64 and s390x qmake doesn't find any installations. It's just i guess x86/armhf configure options result in qmake not being needed at all during mythtv mythtv portion of the build.
<xnox> cjwatson, superm1 - ok found it. Mythtv plugins are funky and did tricks behind our back with iterating:
<xnox> if [ x"$qmake" = "xqmake" ]; then
<xnox>     CHECK_QMAKE="qmake-qt5 /usr/lib64/qt5/bin/qmake /usr/lib/x86_64-linux-gnu/qt5/bin/qmake /usr/lib/i386-linux-gnu/qt5/bin/qmake /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake /usr/local/lib/qt5/bin/qmake $\
<xnox> qmake qmake-qt4"
<xnox> in case of "qmake" default qmake specified.
<xnox> and thus it "worked" on x86_64, i386, armhf only =)
<xnox> exporting QT_SELECT=5 would have been a better trick.
<xnox> or like querying the triplet from gcc.
<xnox> Mirv, our qt is fine, it's mythtv which is funny.
<superm1> xnox: thanks so much for digging in and that analysis, we'll yell at upstream.
<xnox> superm1, qt-chooser is an "upstream" thing as far as I understand. and all they should do is like QT_CHOOSER=5 qmake, QT_CHOOSER=4 qmake, and then give up, and that's it.
<Mirv> xnox: fun hacks there. arguably though qtchooser is a bit of a hack itself and not universally liked either (Fedora chose to rename all binaries instead)
<xnox> =(
<xnox> i see
<xnox> meh
<xnox> Mirv, time to switch "default" to qt5 and forget this ever happened?
<flocculant> infinity: didn't realise you're on vacation - who else is likely to do the beta stuff for the flavours?
<stgraber> FFe request for LXD. We'll be tagging our next beta tomorrow so it'd be great if we could have this reviewed before then!
<stgraber> https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1548489
<ubot5> Launchpad bug 1548489 in lxd (Ubuntu) "[FFe] Let's get LXD 2.0 final in Xenial" [Undecided,New]
<infinity> flocculant: It's only one day of VAC, though if you can talk someone else into doing this one (hi, stgraber!), I've done my fair share of milestones already. :P
<flocculant> infinity: yea I know you have :)
<stgraber> sure, I'm around this week, so I can take care of the machinery, so long as someone else takes care of tracking, paperwork, announcement, ...
<flocculant> stgraber: I'm doing that stuff
<stgraber> cool, who's participating?
<stgraber> creating the milestone now, then do a one-off build and switch all of those off in cron
<flocculant> stgraber: lubuntu/kylin/mate/cloud/gnome/studio and xubuntu
<flocculant> https://wiki.ubuntu.com/XenialXerus/Beta1 is up to date
<flocculant> I pinged yofel earlier today re kubuntu
<flocculant> and you didn't reply about Edubuntu - but I kind of assumed you'd not be anyway :p
<stgraber> we won't
<stgraber> not even sure we'll be releasing 16.04 at all in fact
<stgraber> highvoltage and I have been rather busy with !Edubuntu stuff and we've said that if we'd make a 16.04, it would be the last release we'd be involved in, though even that seems unlikely now
<flocculant> right
<stgraber> flocculant: http://iso.qa.ubuntu.com/qatracker/series/56/manifest does that look good?
 * stgraber fires up VPN
<stgraber> dailies disabled for those
<flocculant> stgraber: if all of those EC2 things are cloud - then yep that looks like the right things :)
<stgraber> yeah, they're the cloudy stuff
<flocculant> cool
<stgraber> oh, though I'm not sure if they still matter since they have their own tracker
<flocculant> thanks stgraber :)
<stgraber> utlemming, rcj, Odd_Bloke: do you guys still need the products in the manifest on iso.qa.ubuntu.com or is that only tracked through the cloud tracker nowadays?
<stgraber> if they don't need it, I'll remove those entirely from the manifest so they don't keep popping up
<flocculant> stgraber: I'll let people taking part know things are building *soon*
<flocculant> and yea - if they use something else
<stgraber> I "think" they don't need those anymore
<flocculant> I have no clue for sure :)
<stgraber> rebuilds requested for all the participating products, the bot will announce as they show up
<flocculant> stgraber: thanks :)
<Odd_Bloke> stgraber: We don't.
<wxl> we have a rebuild going on for some reason?
<flocculant> stgraber: looks like bug 1547518 is going to be an issue
<ubot5> bug 1547518 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.InvalidArgs: No such interface '/org/freedesktop/UPower'" [Critical,Confirmed] https://launchpad.net/bugs/1547518
<flocculant> stgraber: also - what timezone are you?
<stgraber> US/Canada eastern but usually working pacific hours
<utlemming> stgraber: correct, we do not need the products on iso.qa.ubuntu.com. We have cloud.qa.ubuntu.com for that stuff.
<stgraber> utlemming: cool, removed from manifest
<stgraber> flocculant: yeah, that sounds like a potential problem. Looks like it's been assigned to cyphermox so "just" need to wait for a fix and then ask everyone to respin their images
<flocculant> stgraber: ok thanks - just so I know when to see you about if I need anything, I'm UK time
<flocculant> stgraber: yup
<stgraber> qatracker is temporarily down because of a security reboot taking longer than expected
<flocculant> yep
<stgraber> oh, this may actually trigger a second rebuild of some images when the server does come back online as the image builder wasn't able to mark things as built or published :(
<flocculant> heh
<flocculant> awesome timing :)
<stgraber> yeah...
<flocculant> stgraber: most people expect milestones to show up on Tuesday anyway so ...
<stgraber> qatracker is back, lets see what's been lost in the process
<stgraber> I confirmed that nusakan thinks that everything was processed so any product that's missing will be getting another build
<flocculant> lubuntu missing desktops/gnome missing 32bit/ Mate missing completely
<stgraber> convenietly all the missing ones are marked as rebuilding :)
<stgraber> triggered those again now
<flocculant> very convenient - also seems that I can read and agree with that :)
<cyphermox> flocculant: that ubiquity crash, do you get it with the live session or with only ubiquity for installing?
<wxl> cyphermox: both. bug report now says that
<cyphermox> hrm, sorry, I didn't notice
<wxl> cyphermox: also it's i386 and amd64. i'm trying to get one of my ppc testers to check it out there, too, but it likely affects them as well
<wxl> cyphermox: i just changed it
<cyphermox> I'm trying to figure out why
<wxl> cyphermox: somehow it's related to the presence of the battery
<cyphermox> don't bother checking every arch, it will fail eveywhere
<cyphermox> yeah
<flocculant> cyphermox: I've not seen it
<wxl> cyphermox: earliest report seems to be the 19th. i wonder if earlier images have something different in terms of the kernel or upower?
<cyphermox> we only go ask dbus for upower if there is a battery
<cyphermox> they might have, yes
<cyphermox> we got 0.99.4-1 on the 18th
<cyphermox> (but I also uploaded the last ubiquity on the 17th, so it's not a large different in timing)
<cyphermox> I think the new upower is broken somehow, haven't managed to find out how just yet but I also don't have a system with a battery to debug this today, I will later.
<cyphermox> before patching out the crashy bits I'd still like to know why it's crashing
<jibel> cyphermox, if it's upower pitti could have a look tomorrow morning?
<cyphermox> yeah, I'll look too, just a bit later.
<wxl> cyphermox: but did ubiquity have any changes that would affect its dealings with dbus?
<cyphermox> wxl: not directly, but I did move stuff tangentally relevant to upower, when I moved off the "connected to power" widget
<cyphermox> so it's probably just some timing issue where upower isn't starting fast enough or something
<cyphermox> nah, the widgets themselves don't reference that at all
<jibel> cyphermox, actually on a laptop just run upower -d and upowerd crashes
<cyphermox> figures
<cyphermox> oh, so it does, nifty
<cyphermox> I had looked in case there was something like this, but I saw it was just running the daemon seemingly happily on my laptop
<jibel> cyphermox, the dbus call probably make it crash too
<cyphermox> yeah
<cyphermox> well, I got the backtrace, going to look at the code to see
<jibel> cyphermox, https://errors.ubuntu.com/bucket/?id=/usr/lib/upower/upowerd%3A11%3Ag_variant_is_trusted%3Ag_variant_builder_add_value%3Ag_variant_valist_new%3Ag_variant_new_va%3Ag_variant_new
<cyphermox> yeah
<flocculant> stgraber: thanks for starting the ball rolling - I'm off now - back tomorrow :)
<cyphermox> jibel: I think I'll let pitti play with this
<jibel> cyphermox, k, I'll ping him in the morning
<jibel> it's a showstopper for beta1 IMHO
<wxl> jibel: well, server, netboot and lubuntu alternates will be fine :)
<cyphermox> jibel: I'm fixing up a patch to ubiquity to not crash
<flexiondotorg_> infinity, You around?
<cyphermox> flexiondotorg_: infinity has a day off today, can I help?
<flexiondotorg_> cyphermox, Hi :-)
<cyphermox> hey
<flexiondotorg_> infinity, Asked me to annoy him about Xubuntu Base and Ubuntu MATE Base.
<flexiondotorg_> Just here to do as instructed :-)
<cyphermox> ok, then remind again tomorrow maybe ;)
<yofel> flocculant: yes, kubuntu would like to do beta1 - not like we can test much, but it would be nice to at least get ubiquity etc. tested
<flexiondotorg_> cyphermox, Wilco :-)
<flexiondotorg_> cyphermox, Catch you tomorrow!
#ubuntu-release 2016-02-23
<slangasek> xnox: so did you regression-test these latest livecd-rootfs changes against raspi2?
<tgm4883> xnox: thanks for your help earlier on the QT stuff, that seems to have fixed the build
<highvoltage> stgraber: ack
<flocculant> stgraber: can you add Kubuntu in - late to the party ...
<flexiondotorg_> balloons, Morning.
<flexiondotorg_> UBuntu MATE amd64 is missing from the 16.04 Beta 1 iso tracker.
<flexiondotorg_> Can you help with that?
<flexiondotorg_> I need to rebuild all the Ubuntu MATE images for 16.04 beta 1 because there are a couple of packages in the archive that I need in the images.
<flexiondotorg_> balloons, ^^^ :-)
<flexiondotorg_> infinity, cyphermox Ubuntu MATE amd64 is missing from the Xenial Beta 1 iso tracker.
<flexiondotorg_> Can you add it please?
<flexiondotorg_> I'd like to rebuild the images because there are some Ubuntu MATE packages in the archive I need on the isos.
<Laney> flexiondotorg_: Done, but I think that triggering from the daily would have worked too
<flexiondotorg_> Laney, Thanks. Also, good to know. Noted.
<jamespage> arges, hey - we have a load of SRU's penned up in proposed for trusty and wily for openstack components and ceph
<jamespage> they are all verification done - but the http://people.canonical.com/~ubuntu-archive/pending-sru.html report has not been updated since last week, so not sure whether they are appearing on anyone's radar for release to -updates ?
<bremner> polymake upstream asks me (debian maintained of polymake) about polymake 3.0r1-4 migrating to release for 16.04. This apparently needs the old armhf binaries removed.  Can someone have a look at the bug https://bugs.launchpad.net/ubuntu/+source/polymake/+bug/1542398 or suggest another course of action.
<ubot5> Launchpad bug 1542398 in polymake (Ubuntu) "please remove armhf from old package" [Undecided,New]
<flocculant> flexiondotorg_: for the record - we knew yesterday evening Mate was missing - was due to get added then - it all got hung up when the tracker went down shortly after builds started
<flocculant> and - when bug 1547793 fix lands - there will definitely be rebuilds
<ubot5> bug 1547793 in Upower "upowerd crashed with SIGSEGV in g_variant_is_trusted()" [Critical,In progress] https://launchpad.net/bugs/1547793
<cjwatson> bremner: done
<bremner> cjwatson: thanks!
<flexiondotorg_> flocculant, OK.
<flocculant> kubuntu were late - waiting for stgraber to wake up and add it to the pile
<xnox> slangasek, i did not.
<lamont> should I worry that update_excuses shows scads of armhf tests as "In Progress"
<arges> jamespage: yikes. hey bdmurray pending-sru.html hasn't been updating in a few days.
<arges> (i'm guessing its a bit early for him now)
<cjwatson> jamespage,arges: ah, almost certainly a casualty of reboots.  I've killed the stuck process.
<cjwatson> bdmurray: ^- FYI
<arges> cjwatson: thanks
 * flexiondotorg_ wonders if infinity is awake yet so I can "annoy" him as requested?
<stgraber> flocculant: kubuntu added, cron disabled and initial image build in progress for it
<davmor2> cyphermox: who's in charge of upgrade from trusty to xenial?
<cyphermox> davmor2: anyone, what's broken?
<davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1548858
<ubot5> Launchpad bug 1548858 in ubuntu-release-upgrader (Ubuntu) "Trusty â Xenial upgrade window vanishes with no crash" [Undecided,New]
<bdmurray> cjwatson: thanks
<davmor2> cyphermox: anything else that would be useful there?
<cyphermox> maybe what process is running at 100%
<cyphermox> ps -ef
<cyphermox> the upgrader clearly crashed, just need to find out where
<LocutusOfBorg> please accept virtualbox-lts-wily and reject virtualbox-lts-utopic (trusty qieie==
<LocutusOfBorg> queue
<LocutusOfBorg> with .4 trusty the default stack points to wily, utopic seems useless now
<davmor2> cyphermox: done odd thing is, is there is no crash file
<davmor2> cyphermox: anything else you need from that machine before it melts?
<cyphermox> davmor2: I don't know, feel free to reboot it, worst case we'll just try to reproduce it
<davmor2> cyphermox: it's my laptop you won't :P
<cyphermox> heh
<cyphermox> there might be something simple, I'm not sure if very many upgrade tests have been done so far. bdmurray?
 * bdmurray is catching up
<bdmurray> davmor2: what desktop is this?
<davmor2> bdmurray: trusty.4 â xenial beta1 candidate
<bdmurray> davmor2: what desktop environment is this? Unity?
<davmor2> bdmurray: yeap default install of trusty.4 so unity7 no new app installs
<bdmurray> davmor2: hmm, okay - thanks
<cyphermox> there might be something simple, I'm not sure if very many upgrade tests have been done so far. bdmurray?
<cyphermox> oops, sorry
<bdmurray> cyphermox: they are getting set up https://platform-qa-jenkins.ubuntu.com/view/Upgrade/
<bdmurray> Oh, I wonder if this had something to do with it. "DistUpgrade/DistUpgradeViewGtk3.py, DistUpgrade/ReleaseNotesViewerWebkit.py: Port to WebKit 2
<Laney> Get a trace, no point in wondering
<Laney> does that download the new version thing handle dependencies?
<bdmurray> probably not
<bdmurray> "namespace vte not available for version 2.91"
<Laney> :|
<Laney> lemme try this
<Laney> sounds like the same code has to run back to the previous lts?
<flexiondotorg_> Kn1tram.
 * Laney eyes flexiondotorg_ 
<bdmurray> Laney: yes, that's correct
<Laney> bah
<Laney> bdmurray: how do I test this?
<Laney> I mean a fixed version
<bdmurray> Laney: put the tarball somewhere on a system, extract it and run xenial
<bdmurray> Laney: Was that enough information?
<Laney> tell you soon
<cjwatson> snakefruit (proposed-migration, people.canonical.com/~ubuntu-archive/, etc.) will be going down for reboot for a little while shortly; I've shut down archive cron jobs there in preparation
<flocculant> stgraber: ty :)
<flocculant> stgraber: re the upower bug - you gonna do a global rebuild - or expect people to do their own?
<stgraber> I'm using the same web UI they are, so they may as well do it themselves when they feel like it :)
<flocculant> stgraber: okey doke - just wanted to check
<flocculant> not seeing kubuntu yet by the way
<stgraber> I triggered a rebuild, maybe it's still ongoing
<flocculant> ok
<stgraber> that or it failed
<flocculant> :)
<stgraber> looks like it's still going, I see two processes running on nusakan for daily live images
<flocculant> ok - thanks for checking :)
<flocculant> rebuilding mine now - should get the new upower I assume
<cjwatson> snakefruit back
<Laney> bdmurray: hash sum mismatch is killing me
<bdmurray> Laney: hmm?
<Laney> here we go
<Laney> I couldn't run the pre-build because of that error
<Laney> bdmurray: want to try / review / merge / upload https://code.launchpad.net/~laney/ubuntu-release-upgrader/lp1548858/+merge/286930 ?
<Laney> I get a terminal at least
<bdmurray> Laney: sure, I'll give it a go
<Laney> thanks
 * Laney is going to be off, so feel free to fix and merge or whatever
<mdeslaur> could someone please delete squid3 from the trusty and wily upload queues please? I'll include that fix in my security update
<flocculant> stgraber: kubuntu built - not showing on the tracker though
<stgraber> flocculant: I see it here
<flocculant> I see it on daily only
<cyphermox> could someone please review libcxl in xenial queue?
<davmor2> cyphermox: question how would I install a package into ubiquity to test if it fixes the upower issue?  I tried usb pendrive and adding it but there  doesn't appear to be a usable tty, I tried adding it to the iso and burning a new dvd but then it just doesn't boot at all :(
<cyphermox> davmor2: ah, I thought I patched this to not crash yesterday
<cyphermox> ah, it failed to build
<davmor2> cyphermox: No unfortunately there was a real issue in upower
<cyphermox> yeah, I know
<cyphermox> so I would usually boot to a live session and then apt upgrade from a PPA or something
<davmor2> cyphermox: so that has been built now, but is stuck in proposed till it can be tested but I can't get it installed
<davmor2> cyphermox: but it only crashes in the ubiquity session not the live session I think
<cyphermox> upower should be as crashy in both
<cyphermox> your other option is to break=bottom in the command-line and copy/install packages from busybox, but that is painful
<davmor2> cyphermox: oh well in that case I'll burn the real iso again and test in live cd mode when I get back from Shopping
<cyphermox> ok
<jibel> cyphermox, could you respin a desktop image that includes upower 0.99.4-2? users say it's still crashing but I am not sure they are testing the right thing
<jibel> davmor2, what is stuck in proposed?
<lamont> I'm curious why bind9_9.10.3.dfsg.P2-4 is still stuck in -proposed
<lamont> and update_excuses is not making that clear to me
<apw> lamont, it is tied up with debian-installer, and thus with the kernel
<lamont> oh, right
<apw> i've recently released that kernel as the testing is as good as it can be, so it may all migrate now
<lamont> thank you, kind sir
 * lamont goes back to arguing with what he's supposed to be arguing with
<cyphermox> jibel: sorry, EACCESS
<davmor2> jibel: that's what I'm trying to brute force test now
<davmor2> cyphermox, jibel: right Live session, Up and running and crashing ubiquity when I run it.  Installed the new package and then run sudo service upower restart and it's still crashing, I've enabled wifi and I'm going to do and apt get update and see if I missed a package restart it upwer and try again
<cyphermox> libupower-glib3?
<davmor2> cyphermox: nope installed that no change
<davmor2> cyphermox: still giving me the crash line
<cyphermox> mkay
<cyphermox> well, I don't know, you'd have to make sure things are up to date but it should be just upower packages
<cyphermox> plus this doesn't use any library, just straight dbus calls
<cyphermox> which means as long as upowerd was really restarted it should work
<davmor2> cyphermox: yeap watched the indicator die and start again so I assume that means it got restarted
<davmor2> just did a grep power list.txt and list.txt contained the contents of apt list --upgradeable
<davmor2> not sure what else to try I don't really want to install the 133 updates from proposed most of which is libreoffice anyway
<davmor2> cyphermox: any idea's
<ianorlin> is this about bug 1547488 as on an installed xenial system I had a crash that was a duplicate of that and looking at the changelog I got a crash marked as a duplicate and the changelog of upower cited that bug
<ubot5> Error: Launchpad bug 1547488 could not be found
<davmor2> ianorlin: yes this bug https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1547793
<ubot5> Launchpad bug 1547793 in Upower "upowerd crashed with SIGSEGV in g_variant_is_trusted()" [Critical,In progress]
<davmor2> cyphermox: if it helps I can possibly brute force you ssh access to the mac I'm testing on
 * davmor2 calls it a night too tired now
<cyphermox> nah I'll write the daily to usb and run this on my own laptop
<cyphermox> too many computers, not enough room on my desk
<jdstrand> mdeslaur: do you still want squid3 3.3.8-1ubuntu6.5 from trusty and 3.3.8-1ubuntu16.1 from wily deleted?
 * jdstrand happens to be looking at the queue and can do it
<marlinc> Is there a PPA I can try for the Unity 8 stuff on Xenial?
<marlinc> So that I can for example try the OpenStore (if that's even possible)
<jdstrand> mdeslaur: I deleted them based on conversations elsewhere
<flexiondotorg_> infinity, Ping.
#ubuntu-release 2016-02-24
<infinity> flexiondotorg_: Sorry, ended up somewhat (very) sick today.
<flexiondotorg_> infinity, Sorry to hear. I'll "annoy" you another day :-) Rest up.
<amjjawad> Oh, launchpad is down/broken for some reason! why such things happen during before a milestone release?!
<amjjawad> infinity, I'm testing Ubuntu GNOME images and these are true mess :(
<infinity> amjjawad: Security updates, it's only temporary.
<wxl> amjjawad: for more info on that, see #canonical-sysadmin.
<amjjawad> infinity, the installation is broken and I just can't install anything.
<amjjawad> wxl, "Technically, this is a 503 error and has been caused by our database being temporarily offline. " but thanks for your advice :)
<wxl> amjjawad: have you read the topic at #canonical-sysadmin?
<amjjawad> infinity, http://iso.qa.ubuntu.com/qatracker/milestones/357/builds/113126/testcases
<infinity> amjjawad: I'm staying far away from this milestone.
<wxl> amjjawad: you can see who is involved in this milestone here https://wiki.ubuntu.com/XenialXerus/ReleaseTaskSignup
<wxl> suffice it to say, flocculant is asleep
<wxl> i believe stgraber is handling the canonical side of things, right, infinity ?
<amjjawad> Thanks infinity and wxl then guess I have to wait as there is nothing I can do except confirming bugs.
<wxl> amjjawad: you do know you can get around the upower bug by running off ac power only, right?
<infinity> The upower bug was fixed, it just needs a respin.
<amjjawad> wxl, I'm testing on Oracle VB. Not sure if that applies to that as well?!
<infinity> (which stgraber left up to the flavours to do themselves)
<wxl> infinity: not true. flocculant triggered a respin and doesn't work.
<amjjawad> how can I know if I have access to do a re-spin or not? can I try?
<amjjawad> to be more accurate: a re-spin for Ubuntu GNOME images only.
<wxl> amjjawad: if you have an SSO login to the tracker and you have an LP membership that allows you to, for example, mark images as ready, you can select a rebuild in the same area there
<wxl> amjjawad: just click the right images, and click rebuild. bvut again, i don't think it will help
<amjjawad> wxl, indeed, I have access to mark them as ready but never touched "re-spin" as of now.
<infinity> lftp cdimage.ubuntu.com:/ubuntu-gnome/daily-live/20160222.2> cat xenial-desktop-amd64.manifest | grep upower
<wxl> amjjawad: and yes, if your host has a battery, remove the battery and run off of AC power and your vm will work.
<infinity> gir1.2-upowerglib-1.0   0.99.4-1
<infinity> The latest version isn't in those images.
<infinity> libupower-glib3:amd64	0.99.4-1
<infinity> upower	0.99.4-1
<infinity> wxl: It'll help.
<wxl> infinity: it isn't in the xubuntu images?
<amjjawad> darkxst, I'll give it a go!
<infinity> wxl: The newest xubuntu images have -2.
<cyphermox> infinity: jibel asked me to do a respin earlier too, but I have no access to do that
<wxl> infinity: --which is supposedly the fix, right?
<infinity> wxl: Yes.
<wxl> infinity: and what i'm telling you is dear flocculant already tested it and no dice.
<wxl> infinity: i know the bug is fix released. i know pitti worked on it. it didn't fix it.
<amjjawad> is there any harm if one does a re-spin?!
<infinity> Or the testing methodology was lacking.  I'm happy to believe both.
<infinity> amjjawad: No.
<wxl> amjjawad: no harm. go for it.
<amjjawad> perfect :D
<wxl> amjjawad: if you DO get success, let me know.
<amjjawad> wxl, sure ;)
<wxl> amjjawad: but the battery removal WILL work.
<amjjawad> request a rebuild, right?
<wxl> do it
<amjjawad> wxl, yes, will remember the battery thing.
<amjjawad> Done. I must leave my home now. Will keep you posted wxl in case the new build is okay.
<wgrant> Launchpad is back.
<wxl> fwiw i'm sure when amjjawad comes back he's going to complain about the gnome images having failed :) https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-gnome
<darkxst> wxl, I retried them, i386 worked, amd64 is MIA!
<wxl> darkxst: and logs aren't very telling either http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-gnome/xenial/daily-live-20160224.log
<wxl> darkxst: did you get a chance to test the ubiquity/upower bug on that i386? or does your hardware not have a battery?
<darkxst> wxl, trying to find my usb stick so can test on my laptop
<darkxst> might have to go buy another one!
<wxl> darkxst: you can do it in a vm, too
<darkxst> wxl, will try once it downloads
<darkxst> infinity, amd64 ubuntu-gnome build seems to be stuck in a black hole
<darkxst> wxl, what crashes exactly? the installer or live session?
<darkxst> my VM cannot see the battery
<flocculant> darkxst: not having a laptop to physically look myself relying on bug report, but I know the guy tested my respun image is honest :) he says "Yes, the crash dialog appears whether I start the install process from the main menu or from the desktop icon." which implies to me that he sees live session
<infinity> Yeah, the crash is in ubiquity, so live session would work fine.
<flocculant> hi infinity :)
<infinity> flocculant: But also not entirely sure if your tester definitely tested a fixed image, unless it's a different crash, since the one reported literally can't happen in the new version pitti uploaded (the function call isn't there anymore :P)
<flocculant> infinity: well I have to assume that he did use the respun image - he's not new to testing :)
<infinity> flocculant: Sure, but lots of people not new to testing mess that one up several times a year, me included. ;)
<flocculant> yea
<infinity> darkxst: Lemme go find your lost image.
<infinity> darkxst: (You want stgraber for future complaints about this milestone, I'm supposedly not helping)
<infinity> darkxst: Cancelled and re-requested, should be happier.
<darkxst> infinity, ok noted, thanks!
<darkxst> flocculant, I will test on a real laptop after dinner
<darkxst> hopefully it crashed before the repartitioning bit, since I can't really do that unless I can find an old hdd
<flocculant> darkxst: afaik it doesn't get anywhere but starting up
<darkxst> k
<flocculant> I'll try and breathe life back in to a really moribund laptop after work
<darkxst> its hot here, my laptop is trying its best not to melt ;)
<flocculant> :)
<darkxst> 72C basically idle
<flocculant> I don't think the sensors on any of my hardware ever see that :D
<flocculant> UK - it's a bit warm - oooh best rain for a few days then ...
<darkxst> Ive not since that since the prescott P4 days, wonder if the fan is gone
<flocculant> darkxst: ok - got this old laptop working enough - it doesn't even start the installer dialogue
<darkxst> flocculant, can you get a backtrace?
<flocculant> probably if someone tells me how ...
<flocculant> but not now - got 15 minutes to get ready for work now :)
<darkxst> flocculant, if it crashed, you should get crash popup?
<flocculant> I did
<infinity> flocculant: I've got pitti looking into it again, perhaps he only fixed one of two bugs. :P
<flocculant> infinity: ack
<infinity> flocculant: pitti, pitti, flocculant
<flocculant> ha ha ha - no need for introductions :)
<pitti> infinity: I tried plain ubuntu for now
<pitti> and in the live session
<darkxst> flocculant, pitti, its crashing here also, but I am too hungry to look just yet!
<flocculant> :)
<pitti> does that happne in the live session or in ubiquity-only, or in the "choose between those" dialog (ubiquity-dm)?
<darkxst> pitti ubiquity-dm crashed here
<infinity> darkxst: Are you too hungry to get pitti some basic "dpkg -l" and backtrace info? :)
<pitti> ah, dm
<pitti> we are talking about bug 1548362, right?
<ubot5> bug 1548362 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.InvalidArgs: No such interface '/org/freedesktop/UPower'" [Medium,New] https://launchpad.net/bugs/1548362
<pitti> just to avoid doubt
<infinity> pitti: I was told it happens either in ubiquity-dm, or live+ubiquity.
<darkxst> infinity, I have food on the bbq, gotta run, be back in 20mins
<infinity> Heh.
<infinity> pitti: I leave you with the wolves, I shouldn't be active right now.
<infinity> Or, at least, I shouldn't be admitting to it.
<flocculant> pitti: I have enough time to boot before leaving - I'll just double check
<pitti> ubiquity-dm also doesn't crash here
<pitti> flocculant: is that with an actual battery? I only tried in qemu so far
<pitti> or is that somehow flavor specific?
<infinity> pitti: Oh, it does require having a battery, yes.
<pitti> well, perhaps it's easier if you could describe your precise situation in that bug
<darkxst> pitti, no dm doesnt crash its ubiquity greeter and yes its that dbus error
<pitti> other than "requires a MacBook Pro"
<flocculant> pitti: yea battery
<darkxst> and my food is burning
<infinity> pitti: Though, apparently vbox passes through enough fake batteryness on a laptop to also trigger it. :P
<darkxst> pitti, thinkpad t400 here
<infinity> pitti: Crashes on startup, so entirely safe to abuse your own laptop for this, it never gets to the destructive bits.
<pitti> ok, I'll try in vbox and on my laptop
<flocculant> pitti: ok - I am seeing the No such interface /org/freedesktop/upower bug
<pitti> flocculant: do you get an upower crash?
<pitti> what does "upower -d" show?
<flocculant> in laptop with battery
<flocculant> I really have to go now - late already ...
<pitti> meh, installing vbox insists on virtualbox-dkms which breaks secure boot
<flocculant> pitti: shows a whole bunch of stuff - but no net on it atm - just got it working enough to test this
<flocculant> and now really really off :p
<jibel> pitti, this bug only happens on laptops with batteries. I didn't have a chance to reproduce it myself but davmor2 could with the new upower.
<pitti> jibel: I'm currently testing on my laptop
<darkxst> pitti, I can't get wifi working, not able to install enough to get a backtrace
<pitti> meh, this whole test was a waste of time
<pitti> at least the current ubuntu desktop image still has 0.99.4-1
<pitti> I did get the crash, and only checked the version afterwards
<pitti> http://cdimage.ubuntu.com/cdimage/daily-live/current/xenial-desktop-amd64.manifest
<pitti> upower0.99.4-1
<pitti> ah, /current is from yesterday, /pending is from today
<pitti> infinity: ^
 * pitti rsyncs /pending and retries with that
<jibel> pitti, right, that's why I asked a respin. I am not sure people tested the right version and side loading upower is not trivial
<pitti> jibel: got it; let's move to #u-release to keep it all in one place
<jibel> it's already u-release?
<flexiondotorg_> pitti, It is possible this bug is related to upower? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1549045
<ubot5> Launchpad bug 1549045 in ubiquity (Ubuntu) "Ubiquity drive space and connectivity checks are missing" [Undecided,New]
<flexiondotorg_> Because I think I'm right is saying that those checks also include a battery connectivity test?
<jibel> flexiondotorg_, unlikely
<davmor2> morning all
<jibel> morning davmor2
<pitti> cyphermox: ubiquity commit 6376> please never ever use a blank "except:" statement
<pitti> cyphermox: this is always wrong, it hides stupid things like SyntaxError and the like
<cjwatson> yep, should always be "except Exception:" if you specifically want a catch-all
<pitti> I'm reverting that, and put in the proper fix for bug 1547956
<ubot5> bug 1547956 in ubiquity (Ubuntu Xenial) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.InvalidArgs: No such interface '/org/freedesktop/UPower'" [Critical,In progress] https://launchpad.net/bugs/1547956
<davmor2> pitti: I commented on https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1547793 with the steps I'd take, I can reproduce it really quickly and force an ssh channel onto it if that will help, at all?
<ubot5> Launchpad bug 1547793 in Upower "upowerd crashed with SIGSEGV in g_variant_is_trusted()" [Critical,In progress]
<pitti> davmor2: nevermind, it's all figured out
<pitti> davmor2: see #u-release
<davmor2> pitti: awesome
<davmor2> pitti: we're in u-release aren't we
<pitti> davmor2: argh, sorry, so we are
<pitti> davmor2: I have my IRC windows the wrong way around
<davmor2> ah u-quality
<davmor2> pitti: ok so I grab the latest pending iso and then boot the live session enable proposed and install what package to confirm it is fixed?
<pitti> davmor2: it's not yet
<pitti> davmor2: ubiquity with the fix is FTBFS
<pitti> so, no debs to test
<davmor2> pitti: ah right
<pitti> infinity, cyphermox: proper fix for ubiquity crash committed to bzr
<davmor2> pitti: okay well I'm all yours for testing when it's ready, just give me a ping with what to install from where and I'll jump on it :)
<pitti> but the FTBFS due to all these test failures in https://launchpadlibrarian.net/242306075/buildlog_ubuntu-xenial-amd64.ubiquity_2.21.45_BUILDING.txt.gz is still an issue
<pitti> I have an appointment in a few minutes, so I'm afraid I need to disappear for about two hours soon
<pitti> local ubiquity build still fails
 * pitti tries to revert the a11y changes
<infinity> pitti: Just fork from the version in -release, apply critical fix, migrate that, then merge and let cyphermox deal with it?
<pitti> yeah, .44 is more or less that
<pitti> i. e. I reverted both changes from .45, and fixed the upower one
 * pitti tests to build .44 in the meantime, in case it's due to dependency changes
<pitti> c'mon, .46, build
<pitti> screw it, that didn't help
<pitti> so it's a dependency change
<pitti> need to figure this out later, appointment now
<jamespage> bdmurray, any chance we can boot bug 1530913 to updates today?
<ubot5> bug 1530913 in nova (Ubuntu Wily) "[SRU] liberty point releases" [Undecided,Fix committed] https://launchpad.net/bugs/1530913
<jamespage> I'd like to get that released asap
<davmor2> cyphermox: you and me are gonna be buddies for the next few weeks I can feel it, bug #1549277 might be related to the upower stuff in some way
<ubot5> bug 1549277 in ubiquity (Ubuntu) "Ubiquity throws up a ubi-prepare error when using uefi and secureboot" [Undecided,New] https://launchpad.net/bugs/1549277
<davmor2> cyphermox: that is running in vm
<davmor2> jibel: ^
<jibel> davmor2, sounds like a bug in the package intel-microcode
<flocculant> pitti: any progress ?
<flocculant> which sounds a bit open ended - but I'm actually only interested in ubiquity or whatever's causing the b1 issues :D
<davmor2> flocculant: appointment plus travel time, plus lunch, so possibly not for an hour or so
<davmor2> flocculant: soon
<davmor2> jibel: could well be
<jibel> or maybe not
<flocculant> davmor2: ack - I'm only about for 30 minutes now anyway
<jibel> davmor2, or an initramfs bug, in any case a missing dependency somewhere
<jibel> davmor2, is shim-signed installed?
<jibel> davmor2,  it's on hw?
<davmor2> jibel: no this is kvm
<davmor2> jibel: I'm wondering if it might be the new code that turns off secureboot but won't really know for a but I guess
<jibel> cyphermox, could you have a look at bug 1549045? not sure it's on purpose
<ubot5> bug 1549045 in ubiquity (Ubuntu) "Ubiquity drive space and connectivity checks are missing" [High,Confirmed] https://launchpad.net/bugs/1549045
<pitti> could that be related to ubiquity's test failures? they also complain about localechooser, partman etc. not being present
<pitti> or tons of missing labels
<pitti> this for sure feels real enough that "disable the tests" wouldn't give us much -- the package might build, but still not work
<jibel> pitti, possibly, the installer also complains about missing objects to translate, which is obviously the case
<pitti> https://launchpadlibrarian.net/242306075/buildlog_ubuntu-xenial-amd64.ubiquity_2.21.45_BUILDING.txt.gz -> hmm, all the partman tests
<pitti>   * Automatic update of included source packages: hw-detect
<pitti>     1.114ubuntu2.
<pitti> hmm, let's see
<pitti> not sure how http://launchpadlibrarian.net/240232932/hw-detect_1.114ubuntu1_1.114ubuntu2.diff.gz could break ubiquity's tests, though
<pitti> Template parse error near `Binary file (standard input) matches', in stanza #1 of tests/debconfdb
<pitti> that's new, that didn't happen in the previous https://launchpadlibrarian.net/238709629/buildlog_ubuntu-xenial-amd64.ubiquity_2.21.44_BUILDING.txt.gz yet
<pitti> xnox, cjwatson ^ does that ring a bell by any chance?
<pitti> (looking at the ubiquity FTBFS)
<cyphermox> I have been looking at those
<cyphermox> the localechooser test and all are unrelated
<davmor2> pitti, cyphermox: oh that could be why I hit this then https://launchpad.net/bugs/1549277
<ubot5> Launchpad bug 1549277 in ubiquity (Ubuntu) "Ubiquity throws up a ubi-prepare error when using uefi and secureboot" [High,Confirmed]
<pitti> it must be outside of ubiquity itself for sure, so none of the bundled projects
<pitti> as .44 built previously, and now not any more
<davmor2> I'd selected third party drivers
<pitti> and I get the "Template parse error" with building .44 now
<cyphermox> yes, lemme work on this
<jibel> davmor2, it's possible, the detection of secure boot is done in the prepare stage
<cyphermox> davmor2: no, this is different, thanks for reporting
<pitti> debconf hasn't changed since Feb 16
<cyphermox> davmor2: was this on a secureboot system?
<davmor2> cyphermox: sercureboot kvm
<cyphermox> hrm
<jibel> and po-debconf changed on Jan. 7th
<cyphermox> weird, you should have had mokutil available.
<pitti> so we have a new apt, gnutls, perl, procps
<pitti> debianutils, libc6, etc, OMG lots of changes
<davmor2> cyphermox: yeap it asked for password and stuff in syslog it is complaining about the intel-microcode firmware but again might be related to hw-detect if that is broken right?
<cyphermox> not at all
<davmor2> pitti: and mokutil for disabling secureboot from userland
<davmor2> pitti: and apps, and unity7 and
<davmor2> + .....
<pitti> unity, apps etc. aren't relevant for building ubiquity I think
 * pitti is currently cleaning up the build logs to diff them better
 * davmor2 hugs pitti sounds like he needs it
<pitti> http://paste.ubuntu.com/15187518/ â  diff of build deps
<pitti> thanks davmor2 :)
 * davmor2 hugs cyphermox too or he feels jealous 
<jibel> cyphermox, pitti there is lot of changes in ubiquity .45 to rework the accessibility code, including changes to gtk_ui
<cyphermox> jibel: well, I'm not especially worried about that
<cyphermox> looks like things probably fail all because of the same-ish reasons as localechooser is unhappy
<pitti> jibel: they aren't it, already tested
<pitti> jibel: as I said, rebuilding .44 right now fails with the same thing
<pitti> that's the previous version that built on Feb 16
<jibel> ah okay
<pitti> hence the diff of the build deps in http://paste.ubuntu.com/15187518/
<pitti> nothing jumps out on me, though
<cyphermox> nope
<pitti> I mean, could be new grep or whatnot, but I still wonder about whether this debconf template parsing error rings a bell with anyone
<cyphermox> yeah, it's very suspect
<cyphermox> I'm testing a build of localechooser in a PPA
<davmor2> pitti: only thing I see that is new is libkmod2
<davmor2> pitti: no red version of that
<davmor2> oh and dash by the look of it
<davmor2> oh and one final one coreutils
<cjwatson> could well be new grep, maybe needs to run in a UTF-8 locale?
<cyphermox> I was suspecting sed before
<cyphermox> but yeah, grep
<cjwatson> might even need to be fixed in debconf
<pitti> ok, I'll try a build with the previous grep
<cjwatson> though debconf-loadtemplate is perl
<cjwatson> oh, no, it'll be a stage or two before d-l won't iit
<cjwatson> *it
<cjwatson> possibly the install rule in d-i/Makefile
<cyphermox> seems likely, localechooser on its own seems happy enough
<cjwatson> let's see
<pitti> meh, it apparently ignored  my --extra-package=/tmp/grep_2.22-1ubuntu2_amd64.deb
 * pitti builds it with plan B
<pitti> cyphermox, cjwatson: we have a winner!
<cyphermox> yeah
<cjwatson> just seeing if it reproduces locally with LC_ALL=C, I bet it does
<pitti> so, we could revert grep, but I wonder if we can set C.UTF-8 for the build
<pitti> either wholesale, or for the bit that needs it
<cjwatson> let's not revert grep
<pitti> cjwatson: simply sbuilding ubiquity .44 does  reproduce it, yes
<pitti> cjwatson: yeah, I'd like to avoid that too if possible
<wxl> hey folks. any new news on the whole upower/ubiquity thing?
<pitti> wxl: see last 50 lines of backscroll :)
<wxl> pitti: so, you're working on it. got it :)
<pitti> wxl: the upower bug fix is committed, we just need to get ubiquity to build
<wxl> OH
<davmor2> wxl: and then the 50 before that too :)
<cjwatson> I think just export LC_ALL := C.UTF-8 in debian/rules would likely be a good plan
<cjwatson> we intend to do that centrally in launchpad-buildd at some point anyway
<cjwatson> but that's a less trivial thing to change
 * pitti test-builds with that
<pitti> http://paste.ubuntu.com/15187721/ â the changelog is a bit fuzzy
<xnox> pitti, that's obscure =)
<xnox> it must be a milestone week
<pitti> well, we know it's due to grep, we know that UTF-8 fixes it, we are under the gun, so that's all we know about the reason :)
<pitti>   * debian/rules: Build under C.UTF-8 locale. grep 2.23 causes broken debconf
<pitti>     templates to be built under the C locale.
<pitti> how about that
<cjwatson> I've heard of other similar things, e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815620
<ubot5> Debian bug 815620 in debhelper "addsubstvar fails if there are utf characters in the substvar file" [Important,Open]
<pitti> builds fine
<pitti> you have 30 seconds to object :)
<cyphermox> nah, go ahead
<pitti> pushed/dput'ed
<pitti> $ bzr push --tags
<pitti> bzr: ERROR: no such option: --tags
<pitti> bah, git, you spoiled my workflow
<davmor2> pitti: surely you meant https://www.youtube.com/watch?v=Hzlt7IbTp6M
<pitti> infinity, flocculant, wxl: ok, so let's get https://launchpad.net/ubuntu/+source/ubiquity/2.21.46 built, published, and an image rebuilt with that, and the world should be a happier place
<wxl> pitti: get it published and i'll rebuild and test an image or two
<pitti> davmor2: ouch
<cyphermox> cjwatson: pitti: thanks for looking at this
<pitti> yw
 * flexiondotorg_ has been following the backlog regarding ubiquity/grep. Thanks everyone.
<pitti> wxl: it's on the mirrors now, so you should be able to dist-upgrade the live session
<pitti> (except for armhf, that just finished building)
<davmor2> cyphermox, cjwatson, pitti: woohoo!  Thanks all
<davmor2> cyphermox: ummmm I hit an issue with upgrade again,  Upgrade starts now that has been fixed \o/ however now mid upgrade it kicks me out of the system and I can't log back in \o/  You love this don't you I can tell :D
<cyphermox> a desktop?
<davmor2> cyphermox: I can try on a desktop this is kvm and yes secure booted again so might be related to the earlier bug
<cyphermox> that's not what I mean
<cyphermox> what you're trying to upgrade is a desktop, from a logged in session?
<davmor2> cyphermox: trusty to xenial on amd64 bit
<cyphermox> if so, then what kicks you out must be something like restarting X or lightdm
<davmor2> cyphermox: one crash on fontconfig.0.crash
<cyphermox> oh, interesting
<cyphermox> well, please file the bug for that crash
<davmor2> cyphermox: let me see if I can get that uploaded
<davmor2> cyphermox: bug #1549356
<ubot5> bug 1549356 in fontconfig (Ubuntu) "package fontconfig 2.11.1-0ubuntu7 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1549356
<bdmurray> jamespage: the ceilometer package hasn't been available very long
<jamespage> bdmurray, there was an original sru for some point releases which is ready to go
<jamespage> and a subsequent one for ceilometer 5.0.2 and neutron 7.0.3 which is not yet tested
<bdmurray> jamespage: well, ceilometer 5.0.1 was superceded by 5.0.2...
<flocculant> pitti: ty - so I booted current iso - grabbed ubiquity from proposed - started install from desktop - and it's finishing now
<pitti> flocculant: *phew* :)
<flocculant> :)
<flocculant> soon as queuebot says something about it I'll rebuild mine
<jamespage> ah
<davmor2> cyphermox: anything else you need from that before I kill the vm?
<cyphermox> no
<cyphermox> all I really need is my first coffee of the day
 * davmor2 sets up a grip for cyphermox 
<flocculant> pitti: it finished as well - appeared to take a while to get to the 'Remove the install media and press enter' stage - but did
<davmor2> s/grip/drip even
<rbasak> infinity: please could you review my FFe request in bug 1473691?
<ubot5> bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,In progress] https://launchpad.net/bugs/1473691
<jamespage> bdmurray, apologies I'd not realized that had happened
<infinity> cjwatson / pitti: Probably the same as https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1547466 ?
<ubot5> Launchpad bug 1547466 in grep (Ubuntu) "grep switches into binary mode while processing a text file" [High,New]
<infinity> cjwatson / pitti: Didn't realize it was more far-reaching.  If we're subtly breaking translation templates and such, perhaps we either need to "fix" grep or switch buildds to UTF-8 across the board ASAP.
 * Laney heard about another thing that broke because of new grep
<flocculant> pitti: when is it likely to get out of proposed?
<Laney> https://anonscm.debian.org/viewvc/pkg-gnome/tools/gnome-pkg-tools/1/rules/uploaders.mk?r1=47368&r2=47367&pathrev=47368
 * Laney goes blind
<jibel> flocculant, after autopkgtests are done. It's currently waiting for an executor http://autopkgtest.ubuntu.com/running.shtml
<flocculant> thanks jibel :)
<flocculant> guessed it was something like that - never seen that page before :)
<jibel> flocculant, actually the page you should check when you're wondering why something is stuck in proposed is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubiquity which links to the page above
<flocculant> ta
<flocculant> jibel: so new question :) what if something is 'Always failed' eg ubiquity on s390x
<cjwatson> then that doesn't block migration
<infinity> flocculant: "always failed" doesn't prevent migration.
<infinity> cjwatson: Jinx.
<cjwatson> ubiquity is migrating at the moment
<flocculant> ok - thanks both - it's all dutch to me :)
<flocculant> cjwatson: thanks :)
<cjwatson> (as shown on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, in considerably more opaque terms)
<infinity> Or shown in the LP UI by the fact that it randomly disappears. ;)
<cjwatson> hey, it's there now :P
<infinity> Could we not propogate "pending" to that display element?
<cjwatson> it would probably be a good idea
<infinity> The delete/pending behaviour of "it doesn't exist" confuses everyone who isn't us.
<cjwatson> https://launchpad.net/ubuntu/+source/ubiquity/+publishinghistory is the least confusing view despite being ugly
<cjwatson> (and somewhat weird timestamp handling)
<infinity> Right, but people land on the version page and it's blank is the complaint.
<cjwatson> yeah
<infinity> publishinghistory also requires a PhD in LP to read correctly the first time.  But at least it's accurate.
<flocculant> ha ha ha
<cjwatson> I'll have you know I'm merely Mr Watson
<flocculant> oh my ... dad jokes :p
<infinity> flocculant: Well, he does have 37 kids.
<flocculant> :)
 * davmor2 tries a netboot as everything else is broken :D
<davmor2> cjwatson: elementary my dear Watson
<wxl> pitti: welllll i'm finally out of my meeting. i'll check into it. thanks!
<wxl> pitti: it's .45 we need right?
<cyphermox> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1547630
<ubot5> Launchpad bug 1547630 in debian-cd (Ubuntu) "Server 14.04.4 OEM Install option doesn't work" [High,Triaged]
<cyphermox> ^ more for the oops factor than anything else, really
<jibel> wxl, .46
<davmor2> jibel, cyphermox: OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG OMG neboot worked I have a xenial desktop installed \o/
<jibel> davmor2, great, ship it
<wxl> jibel: so a rebuild will get me that, right?
<jibel> wxl, yes
<wxl> jibel: thanks. sorry for being explicit but i want to be sure when i tell all the testers to jump XD
<infinity> davmor2: That's some serious excitement.
<davmor2> infinity: to date every install attempt and upgrade from trusty attempt has failed dismally
<infinity> cyphermox: Ahh, balls.  Want to propose an MP to debian-cd?  We still have one more point release for trusty, may as well fix it.
<cyphermox> infinity: already on it
<infinity> cyphermox: My hero.
<cyphermox> fwiw, 14.04.4 isn't on the wiki on Releases either
<cyphermox> I could only quickly find my Changes document.
<wxl> aw crap i guess i didn't need to rebuild the d-i images :/
<cyphermox> (and 14.04.5 isn't in the trusty release schedule)
<wxl> cyphermox: yeah it would be nice to put it up there!
<infinity> wxl: Clicking rebuild on the d-i images does nothing anyway.
<wxl> um
<wxl> images are marked as rebuilding on the tracker but nothing on lp https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/lubuntu
<infinity> cyphermox: Yeah, I suppose I should put up tentative dates for 16.04.1 and 14.04.5 soon.
<infinity> wxl: The cronjob that kicks them off runs every 5 minutes, patience.
 * wxl breathes heavily
<zequence> We have a rebuild requested, but I seem to remember it needs someone to start it manually. Is that right?
<infinity> zequence: No, it should just magically happen.
<zequence> infinity: Been a while now. A few hours. I accidentally marked the ISOs disabled first. Maybe that ruined it, somehow
<zequence> I could cancel the rebuild, and try again
<infinity> zequence: Well, I see a livefs building for you.
<zequence> Oh, good
<zequence> Ah, yes. I see now
<cyphermox> infinity: https://code.launchpad.net/~mathieu-tl/debian-cd/kernel-cli-separator-trusty/+merge/287089
<infinity> cyphermox: Ta.
<wxl> yofel: darkxst: flexiondotorg_: we now have the ubiquity fix to end all fixes. you need me to rebuild for you?
<darkxst> wxl, great! I just hit re-spin for ubuntu gnome
<wxl> darkxst: triggered. i'll try to keep an eye out when they're done but i assume you're subscribed and get the notifications?
<PaulW2U> wxl, flocculant looks good here on both laptops
<flocculant> wxl: I just did kubuntu and mate
<wxl> PaulW2U: good news. thanks for the confirm!
<flocculant> PaulW2U: thanks \o/
<wxl> flocculant: okie dokie
<wxl> darkxst: oh wait, you said you hit re-spin. jesus. i need more coffee.
<darkxst> wxl, yes I get notifications
<flexiondotorg_> wxl, Yo
<flexiondotorg_> wxl Thank you!
<wxl> np buddy. thank you! if you get to feeling like playing with ppc'
<flexiondotorg_> Just got in from a long day at work. So nice to find a new set of isos to test.
<wxl> s, i'd love it
<flexiondotorg_> wxl I tested Ubuntu MATE PowerPC last night.
<flexiondotorg_> All good.
<wxl> flexiondotorg_: well, i did mean lubuntu, but cool. :)
<flexiondotorg_> It's late here. All I can manage is a smoke test of the new iso.
<flexiondotorg_> I know you mean't Lubuntu :-)
<wxl> XD
<flexiondotorg_> Just letting you know PowerPC "works".
<wxl> i aprpeciate it
<flocculant> hi flexiondotorg_
<flexiondotorg_> wxl I'll smoke test Lubuntu.
<flexiondotorg_> Boot and quick install.
<wxl> flexiondotorg_: thank you so much!
<flexiondotorg_> By quick I mean an hout and a half ;-)
<flexiondotorg_> flocculant, Yo
<wxl> flexiondotorg_: mate's not been getting this, right? https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1547302
<ubot5> Launchpad bug 1547302 in casper (Ubuntu) "Check disc for defects boot option displays no text in Ubuntu Gnome Xenial" [High,Confirmed]
<flexiondotorg_> wxl, Yes.
<flexiondotorg_> But, I've been told is a new UI.
<flexiondotorg_> So, the check only flag up if there is an issue.
<wxl> flexiondotorg_: wait you are or are not?
<flexiondotorg_> wxl.
<flexiondotorg_> Sorry.
<wxl> it's late, i know :)
<flexiondotorg_> Just read that properly.
<flocculant> flexiondotorg_: hang on - I think ^^ is a different issue to the one got marked invalid :)
<flexiondotorg_> That is on my list to test, because I saw other flavours with it.
<flexiondotorg_> Will test it in a sec.
<wxl> k
<wxl> cuz it's NOT in ubuntu
<knome> wxl, please, "cuz" is not a word :)
<wxl> knome: yes, and you didn't use a period at the end of your sentence or capitalize the initial letter so :Ã¾
<knome> wxl, Yes sir.
<wxl> knome: you mean, "Yes, sir." XD
<flexiondotorg_> wxl, You and I will have stuff to discuss on Monday :-)
<knome> letz Ã¥ll chenz to spi-king laik thiz
<flexiondotorg_> h@z u g0tz w@R3z?
<knome> haz meni torrent
<wxl> flexiondotorg_: oooh i like the sound of that
 * flexiondotorg_ l1K3z t0Rr3ntz
<knome> I didn't know the user "wxl" used a screen reader.
<wxl> ok, it's 4 in the morning there. now i understand why knome is being a poo poo butt. XD
<wxl> er.
<wxl> 4 minutes in the morning
 * wxl sighs.
 * wxl drinks more coffee
<knome> tbe, it's midnight here, and the local time doesn't really have anything to do with how my digestion works
<wxl> flocculant: you've already confirmed bug 1547302 does NOT affect xubuntu, correct?
<ubot5> bug 1547302 in casper (Ubuntu) ""Check disc for defects" boot option displays no text some flavors" [High,Confirmed] https://launchpad.net/bugs/1547302
<flocculant> it didn't nope
<flexiondotorg_> bug 1547302 does not appear to affect Ubuntu MATE.
<ubot5> bug 1547302 in casper (Ubuntu) ""Check disc for defects" boot option displays no text some flavors" [High,Confirmed] https://launchpad.net/bugs/1547302
<amjjawad> wxl, are you around?
<wxl> amjjawad: yes, sir?
<flocculant> evening amjjawad
<amjjawad> flocculant, hello :D how are you?
<flocculant> or morning more likely :)
<amjjawad> wxl, hi, you were right :D
<wxl> oh jeez i don't think this bug should be against caspar
<amjjawad> yep, it is 9:30am and I didn't have my breakfast yet
<wxl> amjjawad: i put my feelers out and found out the truth. i was just passing it on :)
<amjjawad> wxl, I took the battery out and you were right, it didn't show up however, I am sure we all know that was not a fix, just a workaround :D
<wxl> amjjawad: yes but it's fixed now!
<flocculant> amjjawad: that bug is fixed now
<flocculant> hah
<amjjawad> haha
<wxl> amjjawad: 20160224.3
<amjjawad> I just logged in so I'll test now and confirm ;)
<amjjawad> http://launchpad.net/bugs/1547302 << I couldn't re-produce this bug
<ubot5> Launchpad bug 1547302 in casper (Ubuntu) ""Check disc for defects" boot option displays no text some flavors" [High,Confirmed]
<amjjawad> did anyone managed to re-produce it?
<wxl> amjjawad: it's bare metal only afaik
<wxl> amjjawad: interestingly it's only lubuntu/gnome, too
<amjjawad> I see ...
<amjjawad> that's explain why I could not see it on Oracle VB
<wxl> right
<wxl> so far that's the only vm i've confirmed it is not reproducible in but i have lots of bare metal reports, so it's a safe assumption at least some vms are out
<wxl> maybe somehow it's how we deal with plymouth???
<flocculant> I've not checked on hardware - can do now
<wxl> oh!
<wxl> did you test on bare mmetal flexiondotorg_ ??
<flexiondotorg_> wxl, Not yet.
<wxl> flexiondotorg_: flocculant: put you guys into the "TO BE TESTED" section of the description XD
<flocculant> done - works
<wxl> kthx
<wxl> oops
<flexiondotorg_> wxl, ?
<wxl> flocculant: you got to come up with a new nick. you're too close to flexiondotorg_ :)
<amjjawad> Sadly, I have no spare hardware to handle UG :(
<wxl> flexiondotorg_: tl;dr let me know how the flavors works out :)
<amjjawad> that is why I use VM
<wxl> amjjawad: you have the hardware you're on, right?
<amjjawad> I can't wxl this is my main
<wxl> amjjawad: all you have to do is boot the iso and run the self check. no installation is needed
<amjjawad> if this will be toasted, I'm dead.
<amjjawad> Ah
<amjjawad> I thought you mean testing the installation hehe
<wxl> nonono
<amjjawad> Yes, that I can do ;)
<wxl> amjjawad: follow the STEPS TO REPRODUCE section XD
<amjjawad> Hehe, yep ;)
<flexiondotorg_> wxl, Couldn't get Lubuntu PowerPC Desktop to boot.
<flexiondotorg_> going to try alternative.
<wxl> aw crap
<flocculant> done draft announcement - waiting on 3 for release notes is all \o/
<flocculant> time for bed said zebedee ...
<amjjawad> wxl, does UNetbootin re-produce this bug: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1547302 I made a boot-able USB with UNetbootin but it seems I am seeing a black screen only .. is this what I am suppose to see?
<ubot5> Launchpad bug 1547302 in casper (Ubuntu) ""Check disc for defects" boot option displays no text some flavors" [High,Confirmed]
<flexiondotorg_> flocculant, amjjawad wxl Are you still seeing LP: #990744 ?
<ubot5> Launchpad bug 990744 in partman-basicfilesystems (Ubuntu) "Ubuntu installer says: The creation of swap space in partition failed" [High,Triaged] https://launchpad.net/bugs/990744
<flexiondotorg_> I was seeing that on yesterdays builds, but all seems fine now.
<flexiondotorg_> Some flavours are still listing it as an issue. So wanted to check in.
<amjjawad> flexiondotorg_, I didn't see it yet
<flexiondotorg_> amjjawad, Thanks.
<stgraber> qatracker is being updated now by Canonical IS, may be down for a few minutes (Drupal update)
<stgraber> upgrade done
#ubuntu-release 2016-02-25
<flexiondotorg_> stgraber, Thanks.
<cyphermox> infinity: new grub in trusty queue with the fixes ^^^
<amjjawad> you welcome flexiondotorg_ sorry, was away
 * wxl is back now too
<wxl> AHHHHHHHHHHHHHHHHH i think https://bugs.launchpad.net/ubuntu/+source/casper/+bug/966480 is back
<ubot5> Launchpad bug 966480 in plymouth (Ubuntu Precise) "The prompt asking for media removal is not shown at the end of the installation" [High,Triaged]
<amjjawad> wxl, it was never away to begin with :D
<amjjawad> I always see it but to be super honest, I didn't bother to report it :P now that I found the bug, I confirmed it and posted a comment as well.
 * wxl siiiighs
<smoser> can someone ack rbasak's https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ?  getting that done will get us a fix for xenial for bug https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1547640
<ubot5> Launchpad bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,In progress]
<ubot5> Launchpad bug 1547640 in squid3 (Ubuntu Xenial) "proxy tries ipv6 and gets 503 when no ipv6 routes" [High,In progress]
<smoser> which we'd like to get into xenial. the SRUs will go in soon.
<ianorlin> any chance  of a fix for bug 990744 anytime soon not sure if lubuntu can get a respin tested if it is not fixed soon
<ubot5`> bug 990744 in partman-basicfilesystems (Ubuntu) "Ubuntu installer says: The creation of swap space in partition failed" [High,Triaged] https://launchpad.net/bugs/990744
<amjjawad> is this bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689 can be re-produced on VM?
<ubot5`> Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
<amjjawad> I tested Ubuntu GNOME i386 20160224.3 on Oracle VB and I didn't see it ..
<ianorlin> amjjawad: I can in lubuntu with encryption on kvm but I can log in if I know it is encrypted
<darkxst> amjjawad, it will only happen on systems that are failing to show plymouth
<darkxst> same with the check disc bug
<amjjawad> so it's a Plymouth thing darkxst ?
<darkxst> amjjawad, yes the password prompt is part of plymouth
<darkxst> (well displayed by plymouth)
<amjjawad> but that should not stop us from releasing the beta 1, right? I mean, is it considered a critical bug?
<ianorlin> if you press a key on the keyboard you get a text mode message to enter your encryption passphrase
<darkxst> amjjawad, there are atleast 3-4 bugs caused by plymouth playing up
<ianorlin> hmm would not using the splash screen like booting without quiet and splash in grub be an effective workaround for the beta
<amjjawad> considering this is an LTS, I find it really painful :(
<ianorlin> when are plymouth problems not painful
<ianorlin> ?
<amjjawad> Over the so many releases of Ubuntu and flavors, Plymouth played a good role of causing lots of issues. I wonder why we could not stop or at least limit that?!
<darkxst> amjjawad, I don't think plymouth has caused that many issues, mainly just the media removal bug that was still never fixed
<amjjawad> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689 is an old bug too from 2014
<ubot5`> Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged]
<darkxst> amjjawad, well that one looks like it was a drm bug in the kernel
<amjjawad> Hi again, Is it okay when the GNOME Software center displays nothing but the installed packages?!
<amjjawad> darkxst, ^^
<darkxst> amjjawad, no, it should show all packages that have valid metadata
<amjjawad> :/
<darkxst> amjjawad, http://appstream.ubuntu.com/
<amjjawad> I am testing now Ubuntu GNOME Desktop amd64 and when I check GNOME software center, I see only the installed packages. It says "No application found" whenever I search for anything :(
<darkxst> amjjawad, maybe try setting require-appdata gsettings key?
 * darkxst is fixing plymouth will check software in a live session later
<amjjawad> darkxst, but it should work by default without checking anything?!
<darkxst> amjjawad, yes lots of apps still have invalid metadata, so will probably set the key before release anyway
<darkxst> but it should show something, other than installed apps
<amjjawad> should I report a bug?!
<darkxst> amjjawad, yes
 * flexiondotorg_ Yawns.
<flexiondotorg_> amjjawad, wxl flocculant How is your testing going?
<flocculant> flexiondotorg_: just in time ... I've never seen swap failing to create - but one of my lot saw oit yesterday
<flexiondotorg_> I was up until 2am and I see no major blockers for Ubuntu MATE.
<flexiondotorg_> flocculant, Right.
<flexiondotorg_> flocculant, I saw it on the builds from 23rd, but only in oem install mode when the disk already had an install on it.
<flexiondotorg_> My testing last night, I didn't encounter it at all.
<flocculant> k
<darkxst> amjjawad, will you scream much if I respin the images?
<amjjawad> darkxst, will that fix the tons of bugs we have?!
<darkxst> it should fix all the plymouth stuff, just for build to waiting to confirm
<amjjawad> Good morning flexiondotorg_ it is 18:35 here and I'm still testing ..
<amjjawad> darkxst, if not, what should we do next?!
<flexiondotorg_> 07:35 here. Just about to go to work.
<darkxst> amjjawad, have more faith in me ;)
<flexiondotorg_> I had to finish my testing last night, because I can't do any today.
<amjjawad> darkxst, of course I do :D
<flexiondotorg_> flocculant, I've just test oem-install again.
<amjjawad> darkxst, go for it ;)
<flexiondotorg_> Works fine.
<amjjawad> flexiondotorg_, interesting enough, your testing is always showing different results :P
<flexiondotorg_> Are we sure the people reporting the swap creation issue are use iso built on 24th?
<darkxst> flexiondotorg_, plymouth is broken for us ;(
<amjjawad> darkxst, https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1549067
<ubot5`> Launchpad bug 1549067 in ubuntu-release-upgrader (Ubuntu) "Ubuntu GNOME Trusty to Xenial release upgrade fails" [Undecided,New]
<amjjawad> did you see this bug ^^ ?
<flexiondotorg_> darkxst, I saw :-(
<flexiondotorg_> Right, off to work. I'll be on here a bit later.
<darkxst> amjjawad, yes
<flocculant> darkxst: this plymouth fix of yours - will it affect globally ?
<darkxst> flocculant, not my upload, but themes moved to /usr/share/plymouth
<darkxst> maybe similar fix for other flavours though
<darkxst> flocculant, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1549623/comments/3
<ubot5`> Launchpad bug 1549623 in plymouth (Ubuntu) "plymouth splash is not being displayed" [Undecided,New]
<amjjawad> will the re-spin fix that upgrade bug darkxst or it's something we can't do much about?
<darkxst> amjjawad, unlikely, no idea what is causing that yet
<flocculant> I haven't touched upgrades this week - I got fails last week though
<flocculant> there'll be a note in our release notes about that along the lines of 'not tested'
<darkxst> amjjawad, besides the images have little to do with upgrades
<darkxst> flocculant, check for hardcoded paths in your plymouth-theme-logo.plymouth file!
<darkxst> I now have a shutdown splash, but no boot splash
<darkxst> oh it came, but way late
<amjjawad> darkxst, you're testing on real hardware?
<darkxst> yes
<flocculant> darkxst: so you're not seeing plymouth at boot/shutdown on hardware as well as vbox?
<flocculant> if that's the case - we only fail on vbox afaik
<darkxst> vbox only gets text mode, so its not affected
<darkxst> our graphical logo theme was pointing to the wrong place
<darkxst> guess didrocks missed that when he did the merge
<flocculant> aah k
<amjjawad> darkxst, are you having problems with the dots under "Ubuntu GNOME"? because I can see that on Oracle VB. Unless you mean something else?
<darkxst> that is the text theme
<darkxst> vbox can't do graphical until it gets KMS drivers
<darkxst> amjjawad, how many times have I told you vbox drivers are rubbish ;)
<flocculant> :)
<darkxst> amjjawad, we are good to go, uploading new theme now
<amjjawad> darkxst, I know but have no other choice at the moment. Maybe when I'll move houses for the 999 times in 2 years, I'll find a real hardware to test Ubuntu GNOME on ;)
<darkxst> amjjawad, vmware player ;)
<amjjawad> could not get it to work here :(
<amjjawad> I prefer real hardware but that should wait until I move ..
<darkxst> their graphics drivers are open-source and in the mainline kernel (Something that will never happen for vbox drivers)
<darkxst> flocculant, when are you planning to release?
<flocculant> darkxst: stgraber is eastern time - working pacific time ish - so hours yet
<flocculant> and I'm off in 20 for ~7 hours too
<flocculant> so if it's about respinning yours and getting testing done you have some time :)
<darkxst> yes, and yes I will re-spin soon
<darkxst> amjjawad, I use a USB harddrive for real hardware testing on my laptop
<flocculant> yofel: what's the story from your corner?
<yofel> flocculant: regarding kubuntu, can you please mark the kubuntu images as not-to-be-released?
<yofel> We wanted to get ubiquity tested, which was successful, but without our FFE approved the beta won't be very useful
<amjjawad> darkxst, is it safer this way a side from the fact that your internal hard won't be touched?
<flocculant> yofel: yea of course - thanks :)
<yofel> flocculant: thanks for the image coordination :)
<flocculant> I'm trying :p
<yofel> ;)
<darkxst> amjjawad, well thats the point, I can't go installing onto my internal hard drive
<amjjawad> darkxst, I'll try to keep that in mind. It might be much easier than allocating a whole machine for testing.
<amjjawad> by the way, darkxst I see no re-spin order yet?!
<darkxst> amjjawad, need to wait for ubuntu-gnome-default-settings to migrate to -release pocket first!
<amjjawad> ok then I am going to have a rest darkxst and then come back later ... we need more hands to help us! I already made 3 posts on 3 different sites but as always, only few will show up if any ..
<darkxst> amjjawad, ok, it will be atleast and hour or 2 until the new images are ready to test
<darkxst> amjjawad, and I think smoke tests and confirming the bugs are fixed is enough at this stage
<amjjawad> do we have time for that darkxst ?
<darkxst> yes
<amjjawad> Ok then, time to rest before I burnout completely .. cya soon darkxst
<darkxst> cya amjjawad
<flexiondotorg_> Morning
<flexiondotorg_> Again.
<flexiondotorg_> darkxst, http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork/revision/57
<flexiondotorg_> darkxst, http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork/revision/58
<flexiondotorg_> Might be helpful for your Plymouth stuf.
<darkxst> flexiondotorg_, I have already fixed, just didrocks missed those on our theme
<flexiondotorg_> :-(
<darkxst> we don't have the scale-2 themes though, guess that is HiDpi stuff?
<flexiondotorg_> Glad you're all set.
<flexiondotorg_> So you fix is not the plymouth itself, but your plymouth themes. Right?
<darkxst> yes essentially http://bazaar.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork/revision/57/usr/share/plymouth/themes/ubuntu-mate-logo/ubuntu-mate-logo.plymouth#usr/share/plymouth/themes/ubuntu-mate-logo/ubuntu-mate-logo.plymouth
<darkxst> didrocks missed that change in our theme
<darkxst> amjjawad, re-spin in progress, give it 30mins: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-gnome
<jibel> davmor2, new desktop builds are now in current/. they were stuck because CI died during the night
<darkxst> amjjawad, ^ builds are ready
<amjjawad> thanks darkxst .. I'll check that once I eat something. It is 21:10 now and I haven't yet eaten anything except breakfast :/
<davmor2> jibel: is it too early for the it still has a werewolf mascot?
<darkxst> amjjawad, oh fuck
<darkxst> amjjawad, glitch in time, ubuntu-gnome-default-settings is completely missing from the new images ;(
<davmor2> darkxst: that reminds me of a song "Glitch in time, glitch in time, Mary Poppins glitch in time, glitch in time, glitch in time, Mary Poppins glitch in time!"
<darkxst> davmor2, I bet Mary Poppins didnt have to deal with bump beta1's
<davmor2> cyphermox, jibel: secureboot and enable 3rd party drivers are still broken badly with the ubi-prepare failed bug from yesterday
<jibel> davmor2, too early to change the mascot
<darkxst> amjjawad, wait for 25.1
<amjjawad> darkxst, :/
<amjjawad> by far, this is the most problematic milestone :(
<darkxst> amjjawad, yes because we skipped the last 2!
<amjjawad> But we did this with 15.10 and things were much less hassle
<darkxst> amjjawad, ^ those should be good
<amjjawad> darkxst, on it ..
<rbasak> Laney: thank you for responding to bug 1473691. I have notes to test against squidguard, squid-deb-proxy and to check upgrade paths more throroughly. Would you prefer that I do this before upload?
<ubot5`> bug 1473691 in squid3 (Ubuntu) "[FFe] squid: Update to latest upstream release (3.5)" [Wishlist,In progress] https://launchpad.net/bugs/1473691
<rbasak> Apart from that it's ready - no known issues.
<rbasak> The disadvantage presumably is that nobody else can also test until I've uploaded.
<rbasak> (easily)
<Laney> rbasak: You could upload and then block in proposed until you've done
<Laney> Up to you
<rbasak> That sounds like a good plan. I'll do that, thanks.
<flexiondotorg_> flocculant, Do you have a release ETA?
<flexiondotorg_> flocculant, My release notes are drafted.
<amjjawad> darkxst, I am using zsync but the download is very slow :(
<amjjawad> My connection is fast, around 40Mbps IIRC but I noticed the download rate will be very slow whenever the images are out from a re-spin .. not sure why ..
<cjwatson> I just replaced the locking mechanism used by cdimage to avoid syncing its local mirror when a build is in progress.  Please let me know if you see anything weird going on with image builds for the next couple of days, although hopefully I'll notice.
<amjjawad> it says 250Kbps O_o
<cjwatson> This should fix the class of problems where the local mirror ends up being stuck and refusing to sync.
<cjwatson> (particularly affected server builds from time to time)
<amjjawad> cjwatson, is what you just did the reason why the images are downloading very slowly? :(
<davmor2> okay so I can use secureboot as long as I don't trigger 3rd party drivers so the bang only happens in the 3rd party driver detection/mokutils part cyphermox jibel
<cjwatson> amjjawad: Totally and utterly unrelated in every possible way.
<amjjawad> cjwatson, any thought why even zsync is giving me 250Kbps while I usually download 1GB in 2-4 mins?
<cjwatson> You're not even downloading from the same machine I was working on, since it's a hidden master.
<cjwatson> amjjawad: No.
<amjjawad> :(
<amjjawad> at this rate, I won't be able to sleep tonight :(
<darkxst> amjjawad, zsyncs take about 5mins here for minor rebuilds
<darkxst> and I am on slow ADSL
<amjjawad> darkxst, it's running for 10 mins now and it says 10%
<darkxst> amjjawad, who is you ISP?
<amjjawad> Optus!
<darkxst> that is your problem!
<amjjawad> I just downloaded 2 ISOs few hours ago, i386 and amd64 and it didn't take 10mins for both!
<amjjawad> but for some odd reason, it is super slow now.
<amjjawad> I'll reboot my modem so will be offline for a while ..
<darkxst> optus gets super congested during peak hours
<amjjawad> darkxst, still no use :'(
<darkxst> amjjawad, your internet or the new images?
<amjjawad> darkxst, my download speed ..
<darkxst> you can't fix optus congestion!
<darkxst> laptop booting with a nice plymouth splash ;)
<darkxst> I'm going to call it a night, hopefully some testing happens while I sleep
<amjjawad> I think there is something wrong with i386 but it's either my ISO on the HDD or the server
<amjjawad> amd64 is zsync nicely
<amjjawad> I think it is downloading the entire i386 from scratch :/
<darkxst> zsync doesnt care about arch
<darkxst> unless you messed up your commands and fed it the wrong link/image
<amjjawad> I copied and pasted the link
<amjjawad> anyway, downloading i386 again from the direct link as it seems for some reason, the ISO is gone. amd64 is done though
<darkxst> there shouldnt be any difference between the two
<darkxst> anyway I am tired, and out for the night
<amjjawad> darkxst, sleep well :)
<darkxst> stgraber, flocculant: our images have been re-spun and should be good to go according to my quick smoke tests, but need to wait on other folks to also test
<darkxst> assume they are not ready, until ali or I give the green light
<darkxst> which given timezones may mean a friday release but oh well....
<amjjawad> it's 23:05 here :'(
<amjjawad> what time exactly we should release all the images?!
<knome> there is never a schedule, it always depends on the situation
<knome> considering stgraber is running the release, it'll likely be hours from now due to his timezone
<amjjawad> The only thing I hate about this place is its time zone :( I'm +11GMT
<darkxst> knome, just making it clear, I have in the past woken to releases when I havent specipically ok'ed them
<amjjawad> speaking of bugs, 1447038 is alive and doing well.
<amjjawad> Have anyone seen this? https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1549787
<ubot5`> Launchpad bug 1549787 in gnome-software (Ubuntu) "GNOME Software is showing "No application found" when searching for new package and it shows only the installed ones" [Undecided,New]
<knome> amjjawad, you mean bug 1548933?
<ubot5`> bug 1548933 in gnome-software (Ubuntu) "It only shows installed apps, not available ones" [High,Confirmed] https://launchpad.net/bugs/1548933
<amjjawad> looks like they're the same knome
<flocculant> darkxst: ack
<amjjawad> knome, the package is different though:  Package: gnome-software 3.19.91~git20160225.dbf5b5d-0ubuntu2
<knome> amjjawad, but the software is same
<amjjawad> yes.
<knome> amjjawad, so you have basically confirmed that the bug exists in a different version of the package.
<amjjawad> should I mark one of them as duplicate?
<Laney> Your one
<Laney> see my comments in the second one, I had already confirmed it in the latest version
<amjjawad> Laney, yes, I know :)
<amjjawad> Done :)
<flocculant> stgraber: fyi - please remove Kubuntu - they've not been able to get done what they needed. Lubuntu, Gnome and Studio left to mark ready, all of who I believe are on top of the situation, announce mail is drafted and just needing a double check from someone for url's
<davmor2> stgraber: and can you please add Ubuntu Desktop and netboot please Thanks :)
<flexiondotorg_> flocculant, Ubuntu MATE is all set. Release notes for blog finalised and ready to post. Images are all ready.
<flexiondotorg_> flocculant, Ping me here around release time :-)
<cyphermox> davmor2: had you filed a bug about that crash?
<davmor2> cyphermox: yes and there is another one now too bug #1549816
<ubot5`> Error: Launchpad bug 1549816 could not be found
<cyphermox> davmor2: launchpad says I've lost something :(
<davmor2> cyphermox: if you enable freesoftware only mode in a non uefi system the installer crashes
<davmor2> cyphermox: try again
<cyphermox> oops
<cyphermox> *sigh*
<amjjawad> I'm sleeping while testing :( it's 1:20 - 26-2-2016 :/
<davmor2> cyphermox: the other was this one from yesterday https://bugs.launchpad.net/bugs/1549277
<ubot5`> Launchpad bug 1549277 in ubiquity (Ubuntu) "Ubiquity throws up a ubi-prepare error when using uefi and secureboot" [High,Confirmed]
<davmor2> cyphermox, jibel: I made the other bug public so anyone can read it
<davmor2> anyway enough of picking on cyphermox time to pick on awe instead \o/
<amjjawad> FINALLY! I'm off to bed. Thanks flocculant in advance and good night from the other side of the world ...
<davmor2> amjjawad: night
<amjjawad> Good night davmor2 and thanks :)
<davmor2> cyphermox: is there anything missing from those bugs that would be useful? they are both pretty easy to reproduce on hw and vm
<davmor2> cyphermox: also do we know what happened with the upgrade bug from yesterday too? or was it the day before they are all merging into one now
<cyphermox> fontconfig is still on my list to look into
<cyphermox> the others I'm verifying the fixes for now
<davmor2> \o/
<stgraber> good morning folks
<stgraber> flocculant: so what's the state of things now, when can I start publishing?
<stgraber> I'll remove kubuntu now
<stgraber> davmor2: Ubuntu doesn't participate in opt-in milestones
<davmor2> stgraber: we are for this one
<davmor2> stgraber: due to it being LTS we wanted to get QA in earlier than normal and cyphermox is so happy we did :)
<stgraber> davmor2: can you have willcooke come confirm this here please? (sorry I need the product owner to confirm for Canonical products)
<davmor2> stgraber: ah fair enough we can keep a manual tracking of it
<stgraber> davmor2: the thing is that if I include it on the tracker, it'll get an actual release out on cdimage.u.c and will be in the announcement, which would be in direct opposition with the current policy of reducing the number of milestones for Canonical owned products.
<stgraber> so I don't mind doing it, but I want to make sure it's been approved by the same folks who want us to do less milestones :)
<davmor2> stgraber: yeap no worries we'll track it separately then, it was more to see what was broken, turns out quite a bit :(
<stgraber> :)
<flexiondotorg_> davmor2, stgraber Did I read that right? Ubuntu are participating in Beta 1?
<davmor2> flexiondotorg_: testing it no in it to win it
<flexiondotorg_> davmor2, Is that a Yes?
<davmor2> flexiondotorg_: No
<flexiondotorg_> Oh, shame.
<davmor2> flexiondotorg_: we are testing it as we speak along with you guys, hence all the pings to cyphermox with why did you break this, :D  I've also done netboot and upgrade testing along with the why did you break this messages :)
<davmor2> to be fair though netboot just works it was beautiful
<flexiondotorg_> Rosco2, Are the Ubuntu Studio images ready?
<flocculant> flexiondotorg_: I'm on top of that
<flexiondotorg_> flocculant, :-)
<flocculant> flexiondotorg_: if you've got 5 minutes can I wing you draft announcement just to check wiki/image urls etc ?
<flexiondotorg_> flocculant, It will be posted here - https://ubuntu-mate.org/blog/ubuntu-mate-xenial-beta1/
<flexiondotorg_> And yes, I will read your draft :-)
<flocculant> I meant the other's too :D
<Rosco2> flexiondotorg_: just starting up for the day. will check tracker and if not - do a quick smoke test
<flocculant> oh damnation
<flocculant> stgraber: you a mod on the devel-announce list?
<flocculant> cjwatson slangasek or infinity - could you blitz the mail I just sent to the devel-announce list by mistake please :)
<flocculant> then I'll have another go at sending it to flexiondotorg_  ...
<stgraber> I am not
<flocculant> nope - I saw on the list info who is :)
<flocculant> stgraber: so - we're waiting for wxl for lubuntu, 32bit studio is rebuilding - didn't get new ubiquity - so they want to smoketest that at least
<stgraber> ok
<flocculant> I've got the announce mail done
<stgraber> well, the list info is rarely accurate, I do have the admin password of a bunch of lists where I'm not listed as an admin :)
<flocculant> so we're almost ready to rock
<flocculant> ha ha ha
<flocculant> I'd assume that those 3 I pinged just after you do have the powers :)
<flocculant> stgraber: looking at lubuntu's results can't see any reason why they'd not mark ready - so looks like just waiting for the studio rebuild
<flocculant> flexiondotorg_: has it turned up - not sure if I have a good address or not - code@ ?
 * flexiondotorg_ has mail
<flocculant> cool - thanks in advance :)
<flocculant> cjwatson infinity slangasek - sorry for the pointless ping(s) reading the approval mail I see I can cancel it myself - sorry guys
<flocculant> Odd_Bloke: I understand you track cloud elsewhere - do you want it on the b1 announcement still? assuming so - got links for image and release notes for me :)
<Odd_Bloke> flocculant: Yep, currently pushing things out to All The Things^WClouds. :)
<flexiondotorg_> flocculant, I'm leaving for home in a few minutes.
<flocculant> ok
<flexiondotorg_> I'll not be online for a couple of hours.
<flocculant> all is peace currently - waiting for wxl and studio
<flexiondotorg_> flocculant, I hear the Lubuntu is ready but wxl fell asleep ;-)
<flexiondotorg_> Catch you later.
<wxl> ok ok i'm here
<wxl> sheesh you people on the other side of the pond XD
<flocculant> wxl: ha ha
<flocculant> wxl: you've got a PM floating about froom me somewhere too
<wxl> flocculant: yeah i saw it up there in the haystack :/
<stgraber> Laney: ^
<Laney> stgraber: feel free to DIY - I'm out the door for mini-vac right now
<Laney> (or get micahg)
<stgraber> ok, it's the usual debdiff and I've test built and test installed it, so I'm happy to self-accept
<wxl> well i guess we're not getting a power pc release :/
<Laney> stgraber: for backports we usually self accept anyway, so no problem here
 * Laney waves
<stgraber> ok, self-accepted
<flexiondotorg_> wxl, I smoke tested PowerPC.
<flexiondotorg_> for Lubuntu.
<flexiondotorg_> But not alternate.
<wxl> i guess i could just call it good
<flexiondotorg_> I think it will be.
<flexiondotorg_> No issues with Ubuntu MATE either.
<flexiondotorg_> So Ubiquity works.
<flexiondotorg_> On PPC.
<stgraber> flocculant: I'll be out for about an hour. I guess things should be good to publish when I get back?
<flocculant> stgraber: should be - studio are just finishing up from what I can see
<flocculant> that works for me as well - kid to feed ...
<bdmurray> xnox, chiluk: can you guys sort out the 2 initramfs-tools uploaded to the trusty -proposed queue?
<apw> bdmurray, thanks for the heads up on that one
<apw> xnox, chiluk, bdmurray, i'll look at that
<chiluk> thanks apw.
<apw> bdmurray, ok that ^ should be the merge of those two, please reject the others once you are happy
<stgraber> flocculant: so how are things looking? ready to start publishing things?
<flocculant> stgraber: chasing down studio
<stgraber> flocculant: okay, looks like you did the smoke testing of the only non-ready image, so if they don't respond I'd be happy to mark it ready and publish everything
<stgraber> there's no rush on my side but I figured that you may want to enjoy some of your evening :)
<wxl> stgraber: it's not even afternoon. no need to rush :)
<flocculant> stgraber: they were 'just finishing' 30 minutes ago
<flocculant> stgraber: thanks for thinking of me :)
<jibel> stgraber, you don't publish any formal beta 1 image for ubuntu, do you?
<stgraber> jibel: nope
<stgraber> ubuntu betas start with beta2
<jibel> stgraber, right, we tested this beta though but don't want to publish anything
<flocculant> stgraber: there we go - full house
<stgraber> flocculant: cool, doing the publishing now, typically takes around an hour for bittorrent and friends to be happy
<flocculant> stgraber: yep - let me know when I can send the mail
<cyphermox> guess it's nearing up on that time I should upload grub-signed too
<flocculant> back in 30 or so
<stgraber> publishing is taking a while
<flocculant> stgraber: :)
<infinity> WARNING: I'm adding apw to ~ubuntu-archive and ~ubuntu-sru to do live training on kernel update procedures, don't panic.
 * davmor2 dials 911/999/119 and holds a finger over the call button, me panic no you must be mistaking me for someone else
<infinity> davmor2: You missed 000
<davmor2> also running out of devices to dial on
<cyphermox> that's not the right number
<rbasak> Also 112
<infinity> 000 is Australia's
<cyphermox> davmor2: you mean 0118 999 881 999 119 7253 ?
<davmor2> that's it I've calling them all you asked for it
<infinity> cyphermox: Seven Two Fiiiive... Three.
 * infinity wonders if queuebot should monitor and report on changes to privileged teams...
<infinity> stgraber: ^ If you're bored. ;)
<stgraber> infinity: the DMB has a script that does that, we get weekly e-mails
<infinity> stgraber: I know, I read them.
<stgraber> but yeah, should be easy enough to copy the logic into queuebot
<infinity> stgraber: But weekly is hardly the appropriate interval to know about archive/sru/release being abused.
<flexiondotorg_> stgraber, flocculant How goes the release?
<stgraber> still waiting for the source cds to finish building
<flexiondotorg_> Ah, OK.
<wxl> i'm checking on one last bug to be sure i don't have to remove it from the release notes but otherwise lubuntu is ready to go
<flocculant> flexiondotorg_: welcome back
<flexiondotorg_> flocculant, Yo. I be cooking meatballs :-)
<flocculant> nice
<flexiondotorg_> Laptop on the counter. I'm ready. I was born ready. Ready to publish things.
 * flexiondotorg_ pokes his head in. Anything?
<flocculant> touch of ennui perhaps
<flexiondotorg_> flocculant, Word of the day! :-)
<flocculant> :)
<stgraber> things should be published now
<stgraber> please check that the links work though
<flocculant> stgraber: I was just going to ask :D
<stgraber> those source images took forever
<flocculant> stgraber: I'll check links in the mail I'm sending then post it
<flocculant> stgraber: look good to me - sending it now
<stgraber> cool
<flexiondotorg_> stgraber, Thanks.
<flexiondotorg_> flocculant, Thanks :-)
<flocculant> stgraber: if someone can deal with allowing the mail to devel-announce that'll be cool :)
<stgraber> I can't, but hopefully infinity or cjwatson are around
<flocculant> yup
<flocculant> wxl: you can publish your blog page now :)
<flocculant> flexiondotorg_ wxl - now we need to try and cajole some of the other flavours into doing this in time for the yy cycle ;)
<flexiondotorg_> flocculant, Too right!
<infinity> stgraber: Did you limit products on the source build (not that that makes them a ton smaller when enough flavours are involved).
<flexiondotorg_> flocculant, Fine job by the way :-)
<flexiondotorg_> infinity, So about Xubuntu Base and Ubuntu MATE Base :-)
<infinity> flexiondotorg_: Yeah, I'll be looking at it this weekend outside work hours.
<infinity> flexiondotorg_: So you can smoketest and iterate a bit before Beta2
 * flexiondotorg_ owes infinity beers!
<flocculant> stgraber: thanks for your help :)
<stgraber> infinity: nope, just ran cron.source, fixed the cdimage tree because that script is still broken and then published
<infinity> stgraber: Kay.  For future reference, check ALL_PROJECTS in etc/config ... For milestones with limited partitpants, 'ALL_PROJECTS="foo bar baz" cron.source' will cut down build time and size a little bit.
<stgraber> ah nice
<stgraber> I did check --help but it was kinda empty :)
<wxl> wait we're good to go?
<wxl> flocculant: blog published
<pleia2> infinity: can you let the email through the queue to -announce so I can post to fridge?
<infinity> pleia2: Yup.
<pleia2> thanks :)
<flocculant> infinity: thanks :)
<flocculant> glad that's done till at least zz
<infinity> Done.
<flocculant> infinity: ty
<flocculant> going mad - I said that already ...
<wxl> flocculant: you're going to make folks worry XD
<flocculant> :)
<infinity> Nah, crazy is our default state.
<infinity> I'd be worried if he wasn't.
<flocculant> ha ha
<wxl> well, i can't argue with that, infinity
<wxl> thanks flocculant flexiondotorg_ infinity stgraber and everyone else for another successful milestone! :)
<knome> infinity, soo... what's the situation with the base merges?
<knome> (now that we got the release out of the schedule)
<wxl> oh and infinity don't forget about the dailies :)
<infinity> 14:28 < flexiondotorg_> infinity, So about Xubuntu Base and Ubuntu MATE Base :-)
<infinity> 14:28 < infinity> flexiondotorg_: Yeah, I'll be looking at it this weekend outside work hours.
<infinity> 14:28 < infinity> flexiondotorg_: So you can smoketest and iterate a bit before Beta2
<stgraber> milestone marked as released and cron restored to normal
<infinity> knome: ^
<knome> ok
<wxl> ah thx stgraber
<knome> infinity, i remember you saying there was some issue with creating another product on our merge proposals; has somebody taken care of that from our side, will you take care of that too, or should we do something?
<infinity> stgraber: Oh, another queubot request.  When it batches items, could you pastebin the batch?  As a general rule in the world o' computing, big changes are the scariest, so it would be nice to have a pointer to quickly review.
<infinity> stgraber: ie: "Event: More than 25 things changed, see http://paste.ubuntu.com/12345")
<stgraber> infinity: yeah, had request for that in the past, it's somewhere on the todo
<infinity> knome: I'll massage it when I review and commit.
 * knome bows and sends infinity a cookie
<infinity> stgraber: I care less about ISO build events, to be fair, but "there were 128 changes to packagesets, lolz" is often a scary message.
<stgraber> infinity: yeah, the original request for the pastebin feature was for packagesets, unsurprisingly :)
<infinity> stgraber: The feature would probably also let you lower the threshold to something less spammy like 5 or 10 too, since we'd not actually ever miss a message, we'd just have to click sometimes.
<infinity> (I noticed I produced some quality spam with my just-under-the-threshold kernel packageset set stuff today)
<infinity> s/set //
<flocculant> stgraber: are dailies back on now for us?
<Odd_Bloke> If an ubuntu-devel-announce person could ACK my update email on cloud images, I'd appreciate it. :)
<Odd_Bloke> flocculant: Maybe you know who to ping ^. :)
<flocculant> Odd_Bloke: infinity seemingly :)
<infinity> flocculant: Dailies are back on for everyone.
<infinity> 14:47 < stgraber> milestone marked as released and cron restored to normal
<stgraber> infinity: bzr branch lp:queuebot, just saying, I know you love python :)
<flocculant> infinity: thanks :)
<infinity> stgraber: Do I ever!
<infinity> stgraber: I'd just fork pastebinit.  Unless it has a module.
<infinity> Odd_Bloke: Accepted.
<Odd_Bloke> infinity: Danke.
<flocculant> Odd_Bloke: nice quote :p
<stgraber> infinity: doesn't have a module but posting to paste.ubuntu.com is also very trivial, just one http POST with the right fields and get the post-redirect URL, it's one of the most trivial pastebins in pastebinit (also the one I wrote that thing for originally)
<Odd_Bloke> flocculant: Thank goodness there was an appropriate one, else I don't know how I'd have let people know. :p
<infinity> stgraber: Fair enough.  Forking's still easier. ;)
<infinity> (Yeah, I can cargo-cult instead)
<flocculant> Odd_Bloke: ha ha ha
<xnox> bdmurray, apw, chiluk - sorry. it's easy to miss that there are things in the queue. =/
<xnox> apw, thanks for merge.
<bdmurray> xnox: I think you were there first, it was that other guy causing problems.
#ubuntu-release 2016-02-26
<xnox> bdmurray, apw causing problems - never. it's always my fault =)
<flocculant> Odd_Bloke: seems I got your bits wrong on the b1 mail - sorry
<flocculant> infinity: once upon a time we spoke about flavours being able to turn off dailies for themselves - did that get any further?
<infinity> flocculant: Nein.
<Odd_Bloke> flocculant: No worries. :)
<davmor2> cyphermox, slangasek: I just had an interesting issue.  I successfully installed 3rd party with uefi + secureboot enabled and got the mokutil uefi menu to disable secureboot.  However when I went to re-enable it with mokutil --enable-validation it told me to install mokutil, when I ran apt install mokutil it told me it was already installed I found no executable for it, I had to purge the package and reinstall
<davmor2> it to use it
<tseliot> infinity: any chance you can approve my nvidia packages in NEW?
<cyphermox> davmor2: ok
<davmor2> cyphermox: key part of that was the thing installed :D
<cyphermox> yay
<cyphermox> I'll look about the reinstalling mokutil part, I think that's the autoremoval magic at the end of ubiquity that's being annoying again
<davmor2> cyphermox: I think so too the odd thing was there was a docs branch for it with nothing in, there was no binary but the package said it was installed from Ubuntu-core iirc :)  just weird
<cyphermox> yeah
<cyphermox> ah, yes, think I found it
<stgraber> oh crap, wrong pocket
 * stgraber removes
<stgraber> done
 * stgraber re-uploads to the right one
<stgraber> that's better
#ubuntu-release 2016-02-28
<flexiondotorg> infinity, Just checking in to make sure you've not got any outstanding questions about Xubuntu Base and Ubuntu MATE Base?
#ubuntu-release 2017-02-20
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Beta 1] (20170219) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Beta 1] (20170219) has been added
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [i386] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [arm64] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: mutter [powerpc] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170220)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] has been updated (20170220)
-queuebot:#ubuntu-release- New binary: mutter [s390x] (zesty-proposed/universe) [3.23.90-0ubuntu2] (desktop-extra, edubuntu, ubuntugnome)
<tsimonq2> flocculant: Around?
<tsimonq2> Oh wait, it's night in the UK isn't it? :/
<valorie> maybe morning
<valorie> date -u
<valorie> Mon Feb 20 02:44:36 UTC 2017
<Bashing-om> GMT 02:44 .
<valorie> very early or pretty darn late
<tsimonq2> I think I pressed the right button...
<tsimonq2> We'll see when the bot comes through in a minute...
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 1] (20170220) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 1] (20170220) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 1] (20170220) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 1] (20170220) has been added
<tsimonq2> Oooooooh I did it I think
<tsimonq2> infinity: Lubuntu Alternate is broken, I think it's related to the net-tools thing O__o http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/zesty/daily-20170220.log
<tsimonq2> Missing debootstrap-required net-tools
<tsimonq2> CD1 missing some packages needed by debootstrap
<tsimonq2> make: *** [/srv/cdimage.ubuntu.com/scratch/lubuntu/zesty/daily/tmp/zesty-i386/packages-stamp] Error 1
<tsimonq2> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<tsimonq2> :/
<tsimonq2> slangasek: ^^^
<infinity> tsimonq2: Fixing.
<infinity> tsimonq2: Should be fixed after the next publisher run (give it an hour or so).
<valorie> infinity: did you see my msg about the missing Lubuntu 16.04.2 i386?
<valorie> at least there is no torrent on http://torrent.ubuntu.com:6969/
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170220)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] has been updated (20170220)
<krytarik> valorie: Funnily enough, yes - but it's here: http://cdimage.ubuntu.com/lubuntu/releases/xenial/release/
<valorie> oh gosh, I wasn't very thorough
<valorie> thanks krytarik
<valorie> I like to seed all the supported releases since I have a good connection
<valorie> now seeding. :-)
<krytarik> Apparently related to valorie's request, I'm getting "Requested download is not authorized for use with this tracker." on that torrent.
<valorie> same here
<valorie> seems to be working on my restarted box, so thanks to whoever or whatever cosmic benificence fixed it
<fossfreedom> tsimong2: infinity: any chance that Ubuntu Budgie can be added to the Beta 1 builds? - just checked the ISO tracker and we are not there.  TIA
<valorie> fossfreedom: have you marked the images as ready?
<fossfreedom> valorie: in the iso-tracker? I've clicked on the beta 1 link and we are not listed.
<flocculant> fossfreedom: pretty sure a few flavours who are in aren't on there yet - but the builds haven't been turned off yet either - so iso's are still building daily
<flocculant> valorie: beta1 hasn't even started yet - no-one should have marked images ready :)
<fossfreedom> flocculant: ah - will wait. Thanks
<valorie> oh, I see what you mean, sorry for the noise
<flocculant> valorie:it's never noise :)
<valorie> flocculant: once the tests are run, before the final ISOs are released, we each have to mark them ready to go
<flocculant> valorie: yea I know :)
<valorie> by tests are run, I mean each flavor's tests
<valorie> not just auto-tests and such
 * valorie is still learning all this stuff as well
<valorie> RM in training
<flocculant> valorie: yup - been doing it for xubuntu for ages :p
<flocculant> valorie: oh cool :)
<valorie> wxl is doing the honors for Kubuntu this round
<flocculant> yea - I've noticed that
 * flocculant is already pondering refusing to release b1 - before it's even started ...
<valorie> no law says ya gotta release it
<flocculant> indeed - we have lock issues - again :(
<valorie> :(
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.27.1+16.10]
<acheronuk> when do the candidate images spin?
<flocculant> ubuntu and lubuntu affected by the same thing
 * acheronuk ponders sneaking plasma 5.9.2 in
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.27.1]
<flocculant> acheronuk: when whoever is doing the canonical side stops iso's building I assume
<valorie> acheronuk: \o/
<valorie> bugfix++
<acheronuk> valorie: yep. running it here and it fixes a few bugs I specifically had in 5.9.1 :)
<valorie> cool
<infinity> valorie: Known, a few torrents got missed, I'll get them added.
<valorie> thanks infinity
 * valorie heads to bed
<infinity> valorie: And fixed (well, once the tracker picks up the change).
<LocutusOfBorg> apw, Archive Admins, what is going on?
<LocutusOfBorg>  virtualbox-ext-pack | 5.1.14-3                | zesty-proposed/multiverse | source
<LocutusOfBorg>  virtualbox-ext-pack | 5.1.14-3                | zesty-proposed/universe   | all
<LocutusOfBorg> this is why it is not migrating
 * apw looks
<apw> LocutusOfBorg, i think that must have just gotten fixed
<apw> oh no, ignore me
<LocutusOfBorg> it makes no sense to me
<LocutusOfBorg> really, your move was correct
<LocutusOfBorg> and britney did let it migrate
<LocutusOfBorg> oh... indeed I got it
<LocutusOfBorg> also -2 was in universe
<LocutusOfBorg> you moved the source package but not the binary :p
<apw> not quite sure how we got here, but i'll get us back to sanity
<LocutusOfBorg> not sure why britney did let it migrate the first time
<LocutusOfBorg> probably due archive reorg you can have different pockets for binaries?
 * LocutusOfBorg leaves
<LocutusOfBorg> thanks
<apw> LocutusOfBorg, done
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Beta 1] (20170219) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Beta 1] (20170219) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Beta 1] (20170219) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Beta 1] (20170219) has been added
<cpaelzer> for tracking of a potential regression-update bug, should we tag it as such once confirmed or once suspect to be one?
<apw> cpaelzer, there seems little harm in tagging it early, and removing it again
<cpaelzer> thank apw, will do so
<jbicha> now that we're past Feature Freeze, powerpc will be dropped? I'm asking because openimageio is holding up the libraw transition
<jbicha> please drop the force-badtest for gjs/armhf from pitti's hints file (since he can't do it himself anymore), s390x is still not working
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [powerpc] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (zesty-proposed) [3.23.90-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (zesty-proposed) [3.23.90-0ubuntu2]
<tsimonq2> infinity: What was the problem?
<jibel> Laney, flocculant who are the contacts for xubuntu and studio for zesty?
<jibel> I'll update the manifest
 * Laney doesn't know, sorry
<jbicha> jibel: could you update Ubuntu GNOME contacts to jbicha / darkxst ?
<jibel> jbicha, doen
<jibel> done*
<tsimonq2> jibel: Update Lubuntu to tsimonq2 / wxl / gilir please
<flocculant> jibel: Xubuntu is me and akxwi-dave, not completely of all of Studio, but sakrecoer is their team lead now
<flocculant> jibel: https://launchpad.net/~rosco2 is Studio's test team lead
<xnox> Laney, Looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html i have no idea how liblog4ada and libaws broken on ppc64el & s390x and rebuilds do not appear to help.
<Laney> Me neither
<xnox> Can those two packages be demoted to -proosed on those two architectures and blocked?
<xnox> and then migrate zlib over?
<Laney> Not by me they can't
<Laney> also, nacc was looking at those packages recently
<xnox> nacc gave up on them too
<xnox> can perl migrate? without the emb thing?
<Laney> Don't know
<Laney> What does your analysis say the failure is caused by?
<xnox> that it redefines symbols and prints that stderr when tests expect no stderr.
<xnox> but it is not broken per se.
<Laney> it prints errors because there's an error ...
<xnox> horum
<Laney> well, I guess it might not be an error, but then the output could be whitelisted
<Laney> analysing the failure would answer that
<xnox> and i can give up at looking at this stuff, until after qt tests finish
<Laney> if an upload triggers < 20 tests it goes into a separate queue
<Laney> and all the queues are processed in parallel
<Laney> so it won't get starved out
<xnox> ah, that's what huge means
<Laney> yes
<Laney> but i'm sure this failure will reproduce locally
<Laney> so you would know it was fixed before uploading anyway
<jibel> tsimonq2, is lubuntu powerpc a product you officially support ?
<jibel> tsimonq2, it's listed in the manifest but not in the products.
-queuebot:#ubuntu-release- New source: gnome-recipes (zesty-proposed/primary) [0.14.2-0ubuntu1]
<tsimonq2> jibel: No more for Zesty Daily
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-38.41~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (xenial-proposed/main) [0.22-1ubuntu5 => 0.22-1ubuntu5.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-38.41~16.04.1]
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (yakkety-proposed/main) [0.23-1ubuntu1 => 0.23-1ubuntu1.1] (ubuntu-desktop)
<rtg> infinity, I've removed the block-proposed tag from bug #1664217. Please update the installer accordingly.
<ubot5> bug 1664217 in Kernel Development Workflow "linux: 4.10.0-8.10 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1664217
#ubuntu-release 2017-02-21
<tsimonq2> cjwatson: Would you happen to know where this is forked from? https://git.launchpad.net/~kubuntu-ci-admins/kubuntu-ci/+git/pangea-tooling/tree/kci/imager/ubuntu-defaults-image
<wxl> tsimonq2: why don't you git blame it?
<tsimonq2> wxl: Because Harald Sitter stole it, not leaving Git history :P
<wxl> bahhhhh
<wxl> just download every repo on lp and grep it :)
<tsimonq2> Bahhhhhhhhh
<wxl> i'm sure that's trivial with the lp api XD
<tsimonq2> wxl: Better to ask the person who originally freaking wrote it ;)
<tsimonq2> Bahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<tsimonq2> infinity: Could you please give the ISO QA tracker a kick? It still doesn't show the new Lubuntu Alternate daily images
<tsimonq2> infinity: Also, if you could, please just disable the Lubuntu Next jobs. We THOUGHT it would be used this cycle, but we had too many blockers, so these images are just wasting space at the moment.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 1] (20170221.2) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 1] (20170221.2) has been added
<infinity> tsimonq2: ^-- Fixed.
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-9.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-9.11]
<handsome_feng> Good morning! everyone! I'm a member of UbuntuKylin, Could someone help to deal with this bug? Bug #1663477 ,I had send an e-mail,but no reply, Thank you!
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,Confirmed] https://launchpad.net/bugs/1663477
<apw> handsome_feng, the status of that bug is really quite unclear by the end, could you add a comment at the bottom detailing the remaining packages you are trying to upload etc
<handsome_feng> apw: I will do that soon, Thank you! :)
<handsome_feng> hi, apw, I have added a comment, can you have a look?
<cjwatson> tsimonq2: sounds like the ubuntu-defaults-builder package
<xnox> apw, can you please split publish binaries generated by src:zfs-linux? bin:zfs-dracut should go into universe, instead of main.
<apw> xnox, perhaps :)
<apw> xnox, ahh new support, yes that seems reasonable to me
<xnox> zfs-dracut/amd64 unsatisfiable Depends: dracut in execuses; and dracut is in universe and i think we want to keep it in universe, hence zfs-dracut should go to universe too.
<xnox> interestingly enough zfs-initramfs is also in universe
<apw> i think you only need that if you do root on zfs
<apw> xnox, done
<tsimonq2> infinity: Awesome thanks
<tsimonq2> cjwatson: Huh? O__o
<tsimonq2> !info ubuntu-defaults-builder zesty
<ubot5> ubuntu-defaults-builder (source: ubuntu-defaults-builder): create Ubuntu customization packages. In component main, is optional. Version 0.55 (zesty), package size 23 kB, installed size 108 kB
<tsimonq2> Weeeeeeeiiiiiiirrrrrrrrrdddddd.
<tsimonq2> cjwatson: Ok, thank you.
-queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.1 => 3.3-2ubuntu7.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: fglrx-installer (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.1 => 2:15.201-0ubuntu0.14.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fglrx-installer-updates (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.1 => 2:15.201-0ubuntu0.14.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: networking-bagpipe (zesty-proposed/primary) [6.0.0-0ubuntu1]
<barry> let's talk about gpgme1.0.  i just uploaded -3ubuntu2 but excuses indicates it blocked by freeze, which is reasonable.  it's been a long slog to get 1.8.0 to build on all archs (LP: #1647204) but -3u2 should work (i can't test s390 or powerpc in my ppa).  i also rebuilt claws-mail (a revdep) against it in my ppa and tested encryption/signing in a vm, both of which worked.  so, should we unblock gpgme1.0-3ubuntu2 and let the normal
<barry> -proposed gate do its thing?  what other testing should be done before that (there are a bunch of other revdeps)?  or should we punt it all to zesty+1?
<ubot5> Launchpad bug 1647204 in gpgme1.0 (Ubuntu) "1.8.0-2 FTBFS in zesty 17.04" [High,Confirmed] https://launchpad.net/bugs/1647204
<sergiusens> RAOF (or slangasek) can we let snapcraft 2.27.1 into xenial-updates and yakkety-updates? the yakkety armhf adt failure is a network timeout, the previous run timed out in a different test; can we take that into consideration?
<slangasek> sergiusens: network timeout> why is it needing to hit a network?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-39.42] (core, kernel)
<cyphermox> cjwatson: any idea why http://people.canonical.com/~ubuntu-archive/apt-mirror.cgi/1480648440/dists/xenial/Release would work, but not the zesty one? this timestamp should bring me to Dec 01, which should have had zesty.
-queuebot:#ubuntu-release- New source: networking-bgpvpn (zesty-proposed/primary) [5.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-82.90] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-110.157] (core, kernel)
<wxl> um
<wxl> is there a reason why the dates for Beta 1 images are all over the map?
<wxl> some are as early as the 19th and yet i wouldn't even expect them to be made available until today
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-64.85] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-110.157~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-64.85~14.04.1] (kernel)
<wxl> ^^ i guess i should direct that question at you Laney
<sergiusens> slangasek: all of our adt tests mostly test against many upstreams
<sergiusens> but other times, they just fail when hitting the ftp.internal deb archive
<sergiusens> these network timeouts we seldom see on x86 fwiw
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-39.42~16.04.1] (no packageset)
<wxl> Laney: if there's hope that the images are not final, that would be great, because plasma 5.9.2 (bugfix release) is in release
<wxl> acheronuk: nice! good job kubuntu team! :)
<wxl> ugh that's the wrongc hannel
<acheronuk> I guessed :P
<slangasek> sergiusens: could the autopkgtest be set up to bypass the CDN using the environment variable that's now honored by snapd?
<slangasek> sergiusens: https://bugs.launchpad.net/snappy/+bug/1653851
<ubot5> Ubuntu bug 1653851 in Snappy "no way to avoid CDN for snap store within launchpad builds" [Undecided,Fix released]
<slangasek> sergiusens: at least, that looks like it would address the most recent failure... but hmm there seem to be a lot of dns resolution failures on armhf that aren't explained by a CDN issue.  So yeah, let's ignore that failure for now (though I'm also poking to see if we can get a good run)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-39.42]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-82.90]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-64.85]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-39.42~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-64.85~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-110.157]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-110.157~precise1]
-queuebot:#ubuntu-release- Unapproved: linux-hwe (xenial-updates/main) [4.8.0-39.42~16.04.1 => 4.8.0-39.42~16.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-armadaxp (precise-updates/main) [3.2.0-1684.111 => 3.2.0-1684.111] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-hwe [sync] (xenial-updates) [4.8.0-39.42~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-armadaxp [sync] (precise-updates) [3.2.0-1684.111]
<cjwatson> cyphermox: not off the top of my head; somebody would need to poke around on snakefruit ...
-queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5 => 2.2.2-5ubuntu0.16.04.1] (mozilla, mythbuntu)
<Laney> wxl: Don't ask me, if you want to have a respin then that's up to you
<tsimonq2> Laney: When I pressed the respin button (got wxl's permission to do for Kubuntu), nothing happened.
<tsimonq2> Laney: What's the deal?
#ubuntu-release 2017-02-22
<infinity> tsimonq2: I see no queued builds for kubuntu.  Of course, you might not have permissions to build it.
<tsimonq2> infinity: Hmmmmmmm
<tsimonq2> infinity: I can for Kubuntu and people like f l o c c u l a n t have rebuilt Lubuntu before, so I'm not sure
<tsimonq2> infinity: But either way rebuild Kubuntu Beta 1 images please ;)
<wxl> weird i was able to rebuild
<tsimonq2> wxl: You in Kubuntu Product Managers?
<wxl> ummm i think so? :)
<infinity> Yeahp, I see wxl's request.
<tsimonq2> infinity: So while you're here, why did Lubuntu Alternate break? O__o
<infinity> tsimonq2: The first time, or the second time?
<tsimonq2> Uhhhh what? ;)
<tsimonq2> Since I asked you last night
<tsimonq2> What's changed and why? :)
<infinity> tsimonq2: The first time, it was because slangasek dropped net-tools from minimal, but didn't change the priority override in the archive, and debootstrap broke.
<infinity> tsimonq2: After I fixed that, I found that my HWE changes for 16.04.2 (which I'd forward-ported to 17.04 for sanity's sake) broke exactly one image -- lubuntu alternate. :P
<tsimonq2> infinity: Hahahahaha :P
<tsimonq2> infinity: Well thanks for taking the time to fix it. :)
<wxl> surprise, surprise, surprise
<infinity> lubuntu alternate really is the oddball these days.  I really think we need to figure out a way to get the desktop image "good enough" for the things you need alternate for (is "low resource machines" the only remaining valid argument?) so we can ditch the alternates.
<infinity> This'll become even more urgent when we eventually move our server images away from using d-i, as we'll want to get rid of all that d-i/debian-cd infrastructure, which only lubuntu will be relying on.
<tsimonq2> Eek.
<lynorian> infinity, is there a timeframe for that?
<tsimonq2> lynorian: Ultimately, unless the archive admins decide to just be inconsiderate and axe it, it's up to us.
<infinity> lynorian: There's a handwavy roadmap goal of 18.04 being a non-d-i server image.  It may or may not happen.  But even without that happening, lubuntu being the only d-i desktop image makes it sufficiently "weird" that it causes us headaches.
<tsimonq2> infinity: What makes Lubuntu Alternate different from Ubuntu Server images?
<wxl> tsimonq2: the GUI
<wxl> infinity: so what will it be replaced with in server/
<tsimonq2> wxl: But Ubuntu Server uses d-i?
<lynorian> tsimonq2, yes
<infinity> In theory, not much.  In reality, quite a bit, since a desktop alternate image has a lot more moving parts.
<tsimonq2> wxl: Lubuntu *Alternate* so one of us is not reading right ;)
<infinity> Lots of special casing in the code, lots more that can go wrong.
<infinity> Plus, an alternate install and a live-based install almost never produce the same results.
<infinity> Which is a bit of a nightmare that I assume you guys just handwave past. :)
<tsimonq2> infinity: The individual who originally vouched for Lubuntu Alternate images is now...gone. I would be happy to reassess the situation and see if it's still worth it, what our community thinks, etc.
<infinity> wxl: In server, the plan is to switch to more of a preimaging-and-first-boot-config style installer (currently known, confusingly, as subiquity, despite having nothing in common with ubiquity).
<infinity> tsimonq2: Ultimately, it comes down to making a solid case for there being a reasonably large number of users who actually *can't* run ubiquity.
<infinity> tsimonq2: If that set of users is very small, then preseeding a d-i netboot (ie: mini.iso) to install lubuntu is a fine workaround for them.
<infinity> tsimonq2: If that set is nonexistant (which might be true by now), then it's even more of a no-brainer.
<infinity> tsimonq2: If 40% of your users have 64MB of RAM, then we need to assess options. :P
<wxl> i look forward to this frankly
<wxl> i mean there's always SOMEONE who will complain, but we don't need to support every edge case
<tsimonq2> +1 wxl
<wxl> usually the contention with netboot is that it requires internet access
<wxl> of course you need internet access to get the iso
<infinity> wxl: Indeed.  And we forced the issue pretty decisively when we dropped non-pae kernels.  I'm having a hard time imagining the intersection of people with PAE-capable CPUs and not enough RAM to run ubiquity is more than about 5 people.
<wxl> or you need someone to get you physical media
<tsimonq2> And I absolutely don't want to paint this as, "Since Simon took over as release manager, he's axing PPC and he's axing alternate images and what now, i386? *grumble*"
<wxl> in which case, with ubiquity,l you have everything anyways
<tsimonq2> s/took over/was given the position of/
<wxl> tsimonq2: ppc was axed because we were forced to
<tsimonq2> (painted in mind of angry person)
<wxl> tsimonq2: and frankly, it would be the same with d-i
<infinity> tsimonq2: PPC is basically out of your hands.
<wxl> the benefit to all this, though, is that we would have our attention divided less and could better support a tighter core
<infinity> d-i will always be in the archive (well, probably always?), but building d-i-based *CDs* for only one flavour is a fairly large maintenance burden on us, so we'd prefer to move away from it if we can, that's all.
<infinity> The infrastructure required to build d-i-based CD images makes shoestring and bubblegum look like steel girders on concrete foundations.
<tsimonq2> wxl, infinity: I would totally be on board with making 17.04 the last release providing the alternate images, provided that we have sufficient documentation for preseeding images and there's not a huge userbase that *absolutely* *needs* the images.
<tsimonq2> You guys +1?
<tsimonq2> I just personally think it's too far in the cycle to make a big change like this.
<infinity> tsimonq2: Sure, I wasn't looking to force a decision today or anything.
<infinity> tsimonq2: Just to seed ideas.
<infinity> tsimonq2: I think a sane first order of business for you would be to float it with your community and get informal polls about how many people use alternate, WHY they use it, and why they THINK they NEED to use it.
<lynorian> infinity, +1
<infinity> tsimonq2: Even if it turns out that all their arguments are bunk, it helps inform contributions that could be made to make ubiquity better, etc.
<tsimonq2> infinity: Totally, I get it, but I'd eventually like to be supporting less images (less overhead etc.), and if the alternate images have a really small userbase, then there's no need to procrastinate.
<tsimonq2> infinity: Absolutely. :)
<infinity> And, yes, "supporting only one image type" was Canonical's driver for dropping the Ubuntu alternates.
<infinity> We had a checklist of things ubiquity had to support before we could do it, we fixed those things, and then bye-bye alternate.
<infinity> QA on two different types of images is costly.
<tsimonq2> For sure.
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Beta 1] has been marked as ready
<infinity> And, to be fair, ubiquity will probably never be as flexible as d-i is for the expert user, but expert people who leverage all of d-i's power do so with netboot and preseeds anyway, not with CD ISOs.
<infinity> I mean, if there's a sysadmin out there who carries CDs around between 1000 corporate desktops, and pops in a floppy with a preseed, I'd like to meet them.  And just stare at them in wonder for a bit.
<tsimonq2> infinity: It would be great if I could get started hacking on Ubiquity, with all of this going on, Kubuntu people have some feature requests, if Lubuntu ever goes LXQt (:P) we'd need to get a Qt but non-KDE Frameworks dependent frontend, etc.
<tsimonq2> infinity: If you have specialized people in Canonical that work on Ubiquity and/or some nice docs, it would be very helpful if you could point me in the right direction. :)
<wxl> tsimonq2: suffice it to say, you should probably start sending out an email to the lubuntu community
<tsimonq2> wxl: Sure, I got it. :)
<wxl> infinity: where is the discussion about this new installer going on at?
<wxl> "new installer"
<tsimonq2> wxl: New installer?
<wxl> tsimonq2: for server
<tsimonq2> Huh?
<infinity> wxl: subiquity stuff is still mostly Canonical-internal, I think, but I've been out of that loop for a while while working on other stuff.
<wxl> tsimonq2: 1628 < infinity:#ubuntu-release> wxl: In server, the plan is to switch to more of a preimaging-and-first-boot-config style installer
<infinity> wxl: If there's a public git and/or docs, slangasek might have a pointer.
<wxl> infinity: um sub-iquity is not a very encouraging name XD
<tsimonq2> ^ lol
<wxl> infinity: i thought you were joking about that :)
<infinity> tsimonq2: cyphermox is the point of contact for all/most things ubiquity right now, try not to drive him insane with questions.
<wxl> welp gotta jet. talk later. thanks for all the info, infinity
<infinity> wxl: It's meant to be short for ServerUbiquity.  You can blame Mark. :P
<wxl> infinity: yeah, well, there be dragons and all XD
<tsimonq2> o/ wxl
<tsimonq2> infinity: I can only try so hard... :P
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.10-2ubuntu2 => 1.6.11-0ubuntu1.16.10.1] (mythbuntu, xubuntu)
<robru> question about http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libseccomp , it was uploaded before freeze but stuck by autopkgtests. those are resolved but now it's blocked by freeze. worth waving through?
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170222)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] has been updated (20170222)
<cyphermox> tsimonq2: it's nowhere near complete enough to spend time testing with more people right now, that's why we haven't really mentioned it -- for now, we're only testing it with a few dozen people, and maybe in a couple weeks we'll announce a way to further test this on ubuntu-devel@ or something
<tsimonq2> wxl: ^^^^^^^^^^^^^
<tsimonq2> cyphermox: Ok :)
<cyphermox> tsimonq2: for now, for your own sanity, I suggest you wait for the announcement. even the images for it are a pain to generate for now >.<
<tsimonq2> cyphermox: Ok, it's just that wxl asked so he's the one who gets an answer. :P
<cyphermox> but if you're really curious, I think things are trivial to find online ;)
<tsimonq2> cyphermox: And are you talking about Ubiquity?
-queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.10-2ubuntu1 => 1.6.11-0ubuntu1.16.04.1] (mythbuntu, xubuntu)
<cyphermox> *s*ubiquity
<tsimonq2> Ohhhhh ok
<cyphermox> ubiquity is the desktop installer, and it's not likely to change in deep ways soon.
<tsimonq2> cyphermox: How about Ubiquity? How can I start contributing there?
<cyphermox> (unless wxl has some fun KDE improvements -- the Qt version of ubiquity needs lovin')
<cyphermox> tsimonq2: the code in at lp:ubiquity. it basically just wraps enough d-i to be useful in the desktop case, and supports preseeding.
<tsimonq2> cyphermox: Hm ok, I'll take a look :P
<cyphermox> not sure what else to tell you about it unless you have questions ;)
<tsimonq2> cyphermox: And yeah, I hope once I can take a look around the ubiquity sources (and if you have any docs for me) I want to help make things better.
<cyphermox> it's python, there are a few gotchas in how things are called, but for most intents and purposes you can add things quickly enough, and fix bugs, etc.
<cyphermox> the doc is mostly from the wiki here: https://wiki.ubuntu.com/Ubiquity
<tsimonq2>  Got something trivial I can start with? :)
<cyphermox> nothing I can think of right now; but I suggest you read at least https://wiki.ubuntu.com/Ubiquity/Testing and maybe https://wiki.ubuntu.com/Installer/Development; those are helpful for how to do the testing and debugging
<cyphermox> tsimonq2: one thing that was reported recently was the "press enter" message not showing up at the end of desktop installs
<cyphermox> I thought we had fixed that, hopefully it hasn't resurfaced.
<cyphermox> that would be more in testing and telling if it's a problem again (probably still is on VMWare, but shouldn't be on qemu or real hardware)
<cyphermox> it's not really ubiquity though
<tsimonq2> Ok
<tsimonq2> cyphermox: I have Saturday completely open, if you have anything I can look at and spend some time on, let me know, otherwise I'll play with that.
<cyphermox> here:
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bugs?field.tag=bitesize
<cyphermox> pick any of those, they should be simple (but they might be already fixed or not applicable anymore)
<cyphermox> on Saturday my wife abandons me again, I was planning on working in the garage, but I could have a laptop around ;)
<tsimonq2> :)
<tsimonq2> cyphermox: My time zone is CST fwiw
<cyphermox> ok
<tsimonq2> I need sleep, have a nice night!
<slangasek> wxl, infinity: I think https://github.com/CanonicalLtd/subiquity might now be public
<lynorian> slangasek, it is
<handsome_feng> Hi, members of ubuntu-release,  I'm a member of UbuntuKylin,I understand that you are occupied, but could anyone do me a favor to deal with this FFe request(Bug #1663477) ?  Thank you in advance!
<ubot5> bug 1663477 in Ubuntu Kylin "[FFe] UKUI desktop environment" [Critical,Confirmed] https://launchpad.net/bugs/1663477
<sergiusens> slangasek: I'll look into the snapd CDN option since you mentioned it
<flocculant> Laney: what are the chances of lightdm coming out of -proposed so I can respin? bug 1656399
<ubot5> bug 1656399 in lightdm (Ubuntu) "Returning to existing session is unreliable and can leave on blank screen" [Critical,In progress] https://launchpad.net/bugs/1656399
 * flocculant is not sure how long things are likely to sit in there - I grab things piecemeal when I need to test something locally ...
<slangasek> infinity: so, we should do something about disabling powerpc, I think.  Any objection to me marking the architecture in proposed-migration as non-blocking?
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.17 => 1.2.2-0ubuntu13.1.20] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.2]
<Laney> flocculant: ok
<Laney> done
<Laney> flocculant: Would be nice if you could get people to chill out over the dates too
<Laney> If anyone wants a respin, just do it, it's meant to be self service
<Laney> You get whatever was latest when the crons were stopped, that's all
<clivejo> does anyone know what is going on with https://launchpad.net/ubuntu/+source/gcc-6/6.3.0-8ubuntu1 ?
<clivejo> arm64 been building for 18 hours now :/
<apw> clivejo, looks to be failing a number of tests, each one in a timeout
<apw> clivejo, it is making progress of a sort
<apw> doko, don't know if this is expected behaviour ^^
<clivejo> it seems to be holiding back calligra
<clivejo> am I right or wrong in that assumption?
<clivejo> not sure why there is a hard dep on gcc like that
<clivejo> :/
<apw> clivejo, i presume it has built against that version of gcc
<apw> clivejo, on the architectures that gcc was complete for
<clivejo> apw: is there any way to poke calligra on?
<acheronuk> hmm.. I see no versioned depends on a particular 1:6.3.0-x version. It build against a previous one anyway
<clivejo> or a nice square kick up the backside with a steal toed boot?
 * acheronuk ponders......
<clivejo> narf
<acheronuk> W: calligra source: intra-source-package-circular-dependency calligra-libs calligrasheets calligrastage calligrawords
<clivejo> time to take over the world?
<acheronuk> maybe that is confusing britney?
<acheronuk> clivejo: that is the plans for tonight!
<acheronuk> same as every night.....
<flocculant> Laney: ack on light dm - and I tried to get people to chill over the date thing yesterday :)
<flocculant> and yea - I knew I could respin - didn't know if lightdm would turn up in time is all :)
<Laney> flocculant: ya, if you need a package from proposed then you have to wait for an unblock
<flocculant> Laney: I see it landed in release 52 minutes ago :)
<Laney> double check with rmadison, then go for the respni
<flocculant> yep - only nipped home for a cuppa - I expect all will be fine when I'm properly home
<flocculant> thanks for the help :)
<Laney> apw: clivejo: acheronuk: On s390x: Depends [...] libgcc1 (>= 1:6.3.0-5ubuntu1)
<Laney> flocculant: only if someone clicks the button
<apw> Laney, as suspected then
<Laney> yep
<apw> s390x must have built relativly recently
<flocculant> Laney: if you mean respin button - I'm totally ok with how that all works :)
<Laney> or it uses a new symbol or something
<apw> don't those shared libarary dependancies get built at package build time, from what we used
<apw> so it is just saying "what i was built with or later"
<Laney> often it finds the maximum version that provides all the used symbols
<Laney> err, minimum
<Laney> flocculant: ok, that's fine, it just sounded a little bit like you were expecting something to happen automatically
 * Laney goes to make a coffee
 * acheronuk plots to kill s390x
<acheronuk> Laney: thx. s390x. grr.
<acheronuk> Laney apw: looking at previous calligra builds, s390x builds do seem to be making a versioned dep against the libgcc1 it was built against each time. whereas other archs seem to be ok with a lower one that obviously is the minimum to provide the symbols on that
<Laney> I don't think it's worth getting overly concerned about
<acheronuk> Laney: no, I guess not. it's just mildly frustrating when GCC is stuck for a bit
<acheronuk> I just prefer when things are stuck to understand why
<acheronuk> Laney: anyway. thanks for spotting that :)
<Laney> np!
<xnox> acheronuk, we maybe missing precise symbols in e.g. libgcc1 itself; hence versioned deps on everything =(
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170222)
<clivejo> what is hold back http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gpgme1.0 ?
<clivejo> the block request?
<rbasak> clivejo: beta 1 freeze + seeded?
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (xenial-proposed) [2.2.2-5ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5 => 2.2.2-5ubuntu0.16.04.1] (mozilla, mythbuntu)
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.1]
<rbasak> Can another ~ubuntu-sru give a second opinion on bug 1313311 please?
<ubot5> bug 1313311 in libscrypt (Ubuntu Trusty) "Broken libscrypt.so symlink" [Undecided,In progress] https://launchpad.net/bugs/1313311
<apw> rbasak, that is a tricky one, things not linking to the static binary is much better for security clearly, do we know if we have had any updates to that library in the life of the release?
<apw> rbasak, as if so, i would be inclinded to say we would want to take it and to want to rebuild the reverse-depends if we can
<rbasak> There have been upstream updates.
<rbasak> I don't know if any of those are security critical.
<apw> yeah but has say the security team updated it in 14.04
<rbasak> But as the uploader points out, we don't know which the reverse depends are.
<rbasak> That'd take some research to figure out, which nobody has done.
<apw> we can likely intuit it from the reverse-depends in the later releases
<rbasak> No. It's in universe.
<rbasak> Good idea.
<rbasak> No previous updates of any form.
<apw> as an approximation obviously
<rbasak> I'm tempted to say "yes, if you sort the reverse depends, but otherwise, no point".
<apw> so ... it being built-in to everything isn't a huge issue, as it hasn't changed
<rbasak> "Yes, once somethingi changes and if you sort the reverse depends, but otherwise, no point".
<rbasak> >
<rbasak> ?
<rbasak> I accept users consuming the library may be impacted. But so might they be if we start shipping the shared library when previously we didn't.
<apw> well they arn't impacted if we are not changing the library anyhow
<rbasak> They don't have a shared library to link against AIUI.
<rbasak> So they're impacted in that they have to worry about rebuilding their own stuff if there's a future security update.
<apw> but yes, i think we need a commitement to research and fix the reverse-depends for this to have any meaning
<rbasak> OK thanks.
<apw> so i think i am agreeing with your middle ground :)
<apw> and feel free to name and shame me in the bug
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (xenial-proposed) [2.2.2-5ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [sync] (xenial-proposed) [3.3-2ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: rejected libscrypt [source] (trusty-proposed) [1-2ubuntu2.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.20]
<jbicha> stgraber: are you able to accept new packages into trusty, xenial? I'm looking for someone to accept bug 1652537
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
-queuebot:#ubuntu-release- Unapproved: pg-repack (yakkety-proposed/universe) [1.3.4-1 => 1.3.4-1ubuntu0.1] (no packageset)
<flocculant> Laney: rebuilt xubuntu ~3 hours ago - lp places show me 64built, 32 bit apparently failed "W: Unable to read /srv/cdimage.ubuntu.com/scratch/xubuntu/zesty/daily-live/apt/zesty-i386/apt/preferences.d/ - DirectoryExists (2: No such file or directory)" not sure where or if I can poke that or needs canonical fingers :)
<Ukikie> Retry the retry, but retry the retry the retry.
<Laney> flocculant: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/xubuntu/+build/91000/+files/livecd.xubuntu.kernel-generic:
<Laney> 2017-02-22 12:48:43 ERROR 503: Service Temporarily Unavailable.
<Laney> that thing you pasted is a warning, the error is after that
<flocculant> Laney: been a long day ... if I hit rebuild - will it - or is it half stuck?
<Laney> second
<Laney> might just be able to run the last bit
<flocculant> might be too late ...
 * Laney zapped it
<flocculant> ninja :)
<Laney> cjwatson: Do you know if something happened to make Launchpad (librarian?) more likely to give 503s lately? I feel like I've been seeing them more often - I implemented some backoff/retry logic in a couple of places for it. Maybe it's always been like that and I only just noticed?
<flocculant> Laney: I assume I can hit rebuild for my 32 bit now?
<Laney> no
<Laney> just wait
<cjwatson> Laney: not that I know of, but I haven't been able to pay a great deal of attention lately
<wxl> Laney: might want to check with sysadmin.
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] has been updated (20170222.1)
<flocculant> Laney: awesome see 22nd on tracker now - thanks :)
<Laney> so if you see that in future, a retry will fix it but a Canonical person can also just rerun the cd-build bit
<Laney> save some CO2 and time
<flocculant> Laney: ack thanks for the help
<Laney> cjwatson: Righto, never mind, thanks for the reply
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-proposed/universe) [4.4.0.1047.39 => 4.4.0.1048.40] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-snapdragon (yakkety-proposed/universe) [4.4.0-1047.51 => 4.4.0-1048.52] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-proposed) [4.4.0.1048.40]
-queuebot:#ubuntu-release- Unapproved: accepted linux-snapdragon [sync] (yakkety-proposed) [4.4.0-1048.52]
<infinity> slangasek: Yes, I object to that.  We need to remove it, not mangle the archive.
<infinity> slangasek: (Marking an arch broken in britney implies that you think it might become broken and raise the uninstallable count, which then leads to weird side effect of uninstallable trading on subsequent migrations, and a degradation of the archive as a whole)
<infinity> slangasek: So, the correct conversation to be had isn't with ubuntu-archive or ubuntu-release about how to work around the arch, it's with wgrant and cjwatson about SQL surgery and steps required to make it so powerpc never existed in zesty.
<slangasek> infinity: that's not true; britney doesn't trade uninstallables across architectures.
<slangasek> the only degradation would be limited to powerpc
<infinity> slangasek: Are you sure?  I thought we'd seen it do so in the past.
<slangasek> not in the past decade
<infinity> slangasek: On the other hand, given that we don't deal with binaries ANYWAY (unlike Debian), we could just literally remove powerpc from britney, rather than marking it in some degraded state.
<slangasek> sure, that's also fine with me
<infinity> We'd end up with the occasional orphaned PPC binary in -proposed when it lags, but those would be removed with the surgery that removes all PPC stuff.
<slangasek> I agree we need to have the LP discussion with wgrant or cjwatson or someone about removing powerpc there, but this is a quick change I can make directly to remove some friction in -proposed
<slangasek> (I was prompted to ask the question precisely because I had a package FTBFS only on powerpc)
<infinity> So, yeah.  I'd prefer to just stop examining binary-powerpc/Packages entirely if your goal is to make britney pretend PPC isn't a thing anymore.
<slangasek> yep, I'm good with that
<infinity> I can just commit that now.
<infinity> Feel like communicating to the world that we're about to completely bugger PPC?
<infinity> Hrm, and by "commit", I mean "edit the config files on snakefruit that aren't in version control".
<infinity> Apparently.
<slangasek> I think the masters are in version control but in a different branch/project
<slangasek> britney1 vs. britney2?
<slangasek> britney1/britney: make_b2_config() ?
<infinity> It sits in b2 in prod.  And definitely isn't a checkout.
<slangasek> yes, but I believe it's generated by the scripts in britney1
<slangasek> actually, it's from suite_arches() in britney1/britney, now to remember where it reads that from
<slangasek> hahaha it trusts LP
 * slangasek whistles and hides under some paperwork
-queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-security/universe) [4.4.0.1048.40 => 4.4.0.1048.40] (kernel) (sync)
<infinity> Oh, well.  That code already has some "if thing, sed 's///'" stuff.
<infinity> Add more!
<slangasek> can do
<slangasek> hmm my britney1 checkout here is bzr, there's a git one now right?
<infinity> Should be.  My b2 checkout is git, my b1 is bzr, which probably means I haven't had a need to fiz b1 in a while.
 * slangasek nods
<infinity> origin	git+ssh://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu (fetch)
<infinity> Going to assume that, with s/britney2/britney2/
<infinity> Or not.
<infinity> Maybe b1 wasn't migrated. :P
<infinity> slangasek: b1 on snakefruit is still bzr.
<infinity> So, I think that answers that.
<slangasek> ok
<infinity> slangasek: Happy to pastebin review a pseudo-MP if you want, but I figure tacking it in in the one place where "precise" appears in the file should be self-evident.
<infinity> s/precise/zesty/; s/ADT_ARCHES/ARCHITECTURES/; s/ppc64el/powerpc/
<slangasek> infinity: JFDI
<infinity> slangasek: Oh, me?  Sure.
<slangasek> infinity: oh
<slangasek> infinity: sorry, I misread - if you haven't already started, I'll do it
<infinity> slangasek: Done now.
<slangasek> ok ;)
<infinity> (Minus comment)
<slangasek> wgrant, cjwatson: so, britney mangling now done, how do we book some time to get powerpc yoinked out of LP for zesty?
<infinity> slangasek: Done.
<infinity> slangasek: Looks like that did the trick.  A bunch of stuff migrated just now without PPC bits.
<infinity> Apparently successful
<infinity> final: ffcall,fnordmetric,gauche,gauche-c-wrapper,gauche-gl,gauche-gtk,golang-github-appc-docker2aci,kodi-pvr-njoy,kodiplatform,libblocksruntime,libc++,libinline-java-perl,mpqc3,oclgrind,open-coarrays,pdns,quantlib-swig,yt
<slangasek> infinity: wunderbar
<infinity> slangasek: So, yeah, can I get you to follow up (well, maybe not literally, I hate losing thread followups when they attach to a mail from months ago) to your original announcement with something about "the breakage has begun, expect PPC to become progressively more broken in zesty until we remove it entirely"?
<slangasek> yes
<infinity> Ta.
<jbicha> thanks, dropping ppc should unlock the libraw transition once the beta freeze is lifted
<slangasek> will do it by EOD tomorrow
<jbicha> (libraw had been stuck because of openimageio not building on ppc)
<infinity> Now I need a new port.
<infinity> mips64el anyone?
<infinity> I guess powerpc had a good run, given the original motivation was "a few Canonical employees have Powerbooks".
<slangasek> let me also disable all powerpc image builds now in the crontab
 * wxl plays taps
<infinity> slangasek: s/crontab/arches/?
<slangasek> infinity: yes
<infinity> slangasek: I thought I hit them all, but lemme have another pass.
<slangasek> infinity: did you?  I don't see it committed to trunk
<slangasek> if you cowboyed it...
<infinity> slangasek: Hah.  Yes.  I did that on purpose.  Let me review my cowboy and commit. ;)
<slangasek> or I can commit this and you can deal with the conflicts
<infinity> Cause I can already see I missed a few cases.
<infinity> Like base needs a new line for zesty-
<wgrant> Hmmm, it's a while since we've done that, but it's not technically hugely difficult.
<wgrant> We're both rather busy atm, but I suppose there's no real urgency?
<infinity> wgrant: Not hugely difficult sounds nice.  I assume it's a tiny bit of SQL surgery to pretend the series doesn't have a DAS for powerpc at all?
<infinity> wgrant: Urgency is "within the next week or two", probably.  Unless we discover that we blow something up by working around it, then "sooner". :P
<infinity> wgrant: But I don't see how we'd break anything right now.
<wgrant> infinity: Not quite. We unset DAS.enabled, then set all the pubs to Deleted.
-queuebot:#ubuntu-release- Unapproved: zypper (xenial-proposed/universe) [1.12.4-1 => 1.12.4-1build0.1] (no packageset)
<wgrant> It's very difficult to actually delete a DAS due to copies etc.
<infinity> wgrant: Well, I guess I'm describing what I want at the UI level, but using (incorrect) DB terms.
<infinity> wgrant: At the UI level, I don't want zesty to claim to have powerpc at all.
<infinity> And, yes, all the pubs deleted.
<infinity> And then I assume I'll need to manually neuter dists after that, which is fine.
<slangasek> infinity: pushed my change, feel free to reconcile with your cowboy :)
<wgrant> Right, that's a fairly similar effect. The same thing we did with maverick's two deaths.
<wgrant> (DAS.enabled was in fact added for maverick)
<infinity> slangasek: Conflicts assume you did something differently. :P
 * infinity looks.
<infinity> Ahh.
<infinity> Yeah, I dropped powerpc entirely from mate because they also don't build it for point releases.
<infinity> Ditto for the * entry.
<infinity> So, I'll revert to my version here, plus other fixes I'm spotting.
<slangasek> well if we're not going to keep it historically accurate, there's a /lot/ of cleanup that could be done
<slangasek> :)
<Laney> Why ARCHITECTURES and not OUTOFSYNC_ARCHES or whatever it was called, OOI?
<infinity> This isn't so much about history as it is about xenial *not* building powerpc anymore for non-server/base.
<infinity> Laney: Because I want to completely ignore it, not make a mess in excuses.
<slangasek> infinity: hmm, it doesn't seem a given to me that they wouldn't build it for point releases just because they didn't do so yet, if you see what I mean
<slangasek> infinity: but, well, if I were doing this from scratch I would drop all the EOLed releases from that file
<Laney> 'k
<slangasek> rather than being a permanent record of "here's a list of architectures you could fail to build jaunty images for"
<infinity> slangasek: Sure, I don't disagree that removing EOL stuff might be a solid plan.
<infinity> slangasek: Just saying that it documents current runtime desire, so the xenial entries should reflect that. :)
<infinity> slangasek: (And the reason for not doing powerpc desktop point releases is that we don't have a powerpc HWE kernel there)
<infinity> slangasek: I suppose from the historical POV, it would be most accurate to list a yakkety line with powerpc, but xenial and zesty- without, but meh.  I'd rather drop all the cruft in a follow up instead.  This isn't Colin's toy anymore, so we can break his data-retention policy if we want. :P
<infinity> (Also, a VCS has history, weird)
<slangasek> :-)
<infinity> slangasek: I suspect dropping everything pre-trusty would reduce us to entries for server, base, mate, lubuntu, and star (and a only a few series ranges).  Which would be nice.  And much more compact.
<infinity> Maybe I'll do that now. :P
<infinity> (Could realistically drop everything pre-xenial, but then I know someone will pay us bazillions to do a 14.04.6 we hadn't planned on, just to spite me)
<sbeattie> can someone accept the linux-meta-snapdragon in the yakkety-security unapproved queue so that my cron job about kernel ABI breakages will stop bugging people?
<infinity> How or why did it end up in unapproved in the first place?
<infinity> But looking/fixing.
<infinity> sbeattie: Done.
<sbeattie> infinity: thanks
<infinity> apw: ^-- That was you, BTW.  Manual copy instead of sru-release, and no --auto-approve means manual love.
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-security) [4.4.0.1048.40]
<slangasek> kernel-sru-release is good for this :)
<infinity> slangasek: I doubt it.
<infinity> slangasek: This was a xenial SRU that needed to be copied forward to yakkety and zesty.
<infinity> slangasek: The copy forward is where one copy went wrong.
-queuebot:#ubuntu-release- Unapproved: accepted zypper [source] (xenial-proposed) [1.12.4-1build0.1]
<slangasek> infinity: ahh ok
<apw> infinity, yeah that _was_ me, and i forgot to accpet it the second time after launchapd had a nice little internal error paddy over it the first time
<slangasek> top
<slangasek> that... did not give me the feedback I was looking for kthx
<infinity> apw: All good.  That's why the security team has their nag script. :P
<apw> infinity: they have their uses!
<barry> rbasak, clivejo i'm hoping we can still get gpgme1.0 1.8.0 into zesty after beta 1 freeze
<clivejo> hope so
<barry> took a long while to get the ftbfs fixed, but it appears now to be, and this one's holding up a few other promotions
<wxl> Laney: et al do you know where Lubuntu Desktop's image went? all thee is is 20170219 http://cdimage.ubuntu.com/lubuntu/daily-live/
<wxl> Laney: to be clear the tracker says the version is 20170220. maybe someone screwed up naming it correctly on the tracker. i'll assume that for now
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 1] has been marked as ready
<Laney> wxl: dunno, but it's easy to fix
<wxl> Laney: i just want to make sure the image we're testing is the right image :)
<Laney> there
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170219)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 1] has been updated (20170219)
<wxl> thx
<wxl> now i just need to figure out where synaptics went
<wxl> didn't realize it but it wasn't there in zesty either
<wxl> alpha 1 i mean
<wxl> doesn't seem xserver-xorg-input-synaptics has changed any since yakkety
<wxl> was there something that has changed about the ubuntu seed?
<wxl> i can't find any changes in the seed that would have resulted in this
<flocculant> wxl: we still have it
<wxl> that's uncanny
<flocculant> wxl: re oem - working fine here - at least using kvm
<wxl> we do use * Feature: no-follow-recommends
<wxl> (and have for a long time)
<wxl> is synaptics now in recommended?
<wxl> flocculant: yeah that's been our experience here. vbox only it seems.
<flocculant> wxl: apt-cache show blah-blah-synaptic doesn't show as a task for Lubuntu
<wxl> i think the no recommends is our problem
<wxl> compare http://packages.ubuntu.com/yakkety/xserver-xorg-input-all with http://packages.ubuntu.com/zesty/xserver-xorg-input-all
<nacc> could someone take a look at perl in z-p? the tests finally are all passing
<nacc> and it's holding up a few other migrations
<nacc> slangasek: --^ fyi
<slangasek> nacc: so this is blocked for the beta freeze; how high risk is it to those images? if there are significant behavior changes we might want to hold it until the beta image prep is done
#ubuntu-release 2017-02-23
<nacc> slangasek: i think we can hold off -- i'm genuinely not sure on the behavioral changes -- we are going from a 5.24.1~rc4 upstream to 5.24.1. I think it's ok to hold it
<nacc> well, I said that twice as I gathered my thoughts :)
<nacc> slangasek: the only thing i've yet to fully track down is the libaws/liblog4ada regression on p/z only. It's not just a rebuild needed (or if it is, it's a rebuild needed of several packages). I've shot an e-mail off to doko  and will try and get it resolved.
-queuebot:#ubuntu-release- Unapproved: wine1.6 (xenial-proposed/universe) [1:1.6.2-0ubuntu14.1 => 1:1.6.2-0ubuntu14.2] (no packageset)
<tsimonq2> Laney, slangasek, and infinity: Bug 1667128 might be blocking Beta 1 for Lubuntu and I don't have access to the seed, and I haven't confirmed it's a bug because I don't have a laptop, so if it could get confirmed and fixed by a wonderful, kind person, I can add a beer tally. ;)
<ubot5> bug 1667128 in lubuntu-default-settings (Ubuntu) "zesty beta1 does not have xserver-xorg-synaptics so my touchpad mousewheel does not work" [Undecided,New] https://launchpad.net/bugs/1667128
<tsimonq2> (Oxford comma ftw, hah pleia2 :P)
<cyphermox> tsimonq2: ok, I can do that
<cyphermox> xserver-xorg-input-all recommends -synaptics already (Timo added it) but lubuntu doesn't follow recommends.
<Ukikie> Causes a lot of headaches, but it does limit the junk they pull in. :/
<cyphermox> well, scrolling is kinda helpful.
<cyphermox> I tend to question whether stuff some people classify as junk really is worth the hassle, but it's definitely not my call ;)
<cyphermox> /usr/bin/germinate-update-metapackage: Installed debootstrap is older than in the previous version! (1.0.81ubuntu3 < 1.0.86)
<cyphermox> o.O?
<cyphermox> ah, pitti was naughty and used Debian's debootstrap to update the meta... which I don't think I really need to update anyway
<tsimonq2> cyphermox: Got it? :)
<cyphermox> nearly done, last thing I do before going to bed
<tsimonq2> Yay
<tsimonq2> cyphermox: Don't pull a GitLab :P
<cyphermox> the what?
<tsimonq2> (OK, that was mean, I'm sorry...)
<tsimonq2> cyphermox: GitLab imploded a few weeks ago because the sysadmin did something right before bed
<cyphermox> well, it's exactly what I'm doing
<Ukikie> \o/
<cyphermox> but I don't think it's much likely to explode too much
<tsimonq2> cyphermox: Good read after some sleep to get why that was a cruel joke. :P https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
<cyphermox> tsimonq2: don't worry, I know enough about the Friday PM rule from years as a sysadmin before Canonical.
<cyphermox> I've had my share of "oops, this system probably won't boot again if you stop it"
<cyphermox> or weird pages during the night because some machine died... or the occasional lalala ran the wrong command on the wrong system and (all the network is down|I need to get to the datacenter to turn this back on)
<tsimonq2> Yyyeeeaaahhh :P
<tsimonq2> cyphermox: Ping me when you're done and I can respin Lubuntu images
<cyphermox> tsimonq2: it's mostly done, the lubuntu-meta is building, but I don't think it's worth respinning right now
<tsimonq2> Oh?
<cyphermox> my wild guess is that they should spin again very soon on the normal cron
<tsimonq2> cyphermox: Uhm, Beta 1 froze everything up, are you sure about that?
<tsimonq2> It's supposed to land tomorrow :P
<tsimonq2> cyphermox: Why not respin?
<cyphermox> I'm not saying "you should not", more like "you're probably not helping, it should spin again".
<cyphermox> I'm not sure, but I don't think we stop spinning dailies for these milestones
<tsimonq2> Ah k
<tsimonq2> cyphermox: Yes we do :P
<cyphermox> you got that stopped on Sunday?
<tsimonq2> Yep
<tsimonq2> cyphermox: Blame Laney :P
<cyphermox> okay then
<tsimonq2> :)
<cyphermox> the alternate isn't stopped though
<tsimonq2> Uh WHAT?
<cyphermox> oh wait
<tsimonq2> You sure?!?
<cyphermox> sorry, that's my bad, it might well be, just got respun a lot more than the desktop one
<tsimonq2> I see
<tsimonq2> Yep, that's accurate
<cyphermox> full disclosure: I'm not in the release team, I don't have access to see the crontab, I can only deduce from what I see in logs, etc.
<cyphermox> it doesn't really say if it's a cron
<tsimonq2> Got it ;)
<cyphermox> heh, since I modified stuff, I might as well babysit this for a bit
<cyphermox> you might not want to respin for a few minutes, I updated lubuntu-meta, you might as well wait for it to be out of -proposed before respinning.
<tsimonq2> Ok
<tsimonq2> cyphermox: Do you have the ability to let it pass?
<cyphermox> it needs to take the time to be seen by britney
<tsimonq2> Ok
<cyphermox> ETA ~30 minutes, maybe?
<tsimonq2> Alright, I'll keep an eye on it.
<tsimonq2> cyphermox: Thanks. :)
<cyphermox> tsimonq2: ok, lubuntu-meta shows up, but it's obviously blocked by freeze. I can't unblock that, you'll need to ask someone else
<cyphermox> you can probably still respin and things would work
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (xenial-proposed/universe) [1.1.93-1ubuntu1 => 1.1.93-1ubuntu1.1] (no packageset)
<tsimonq2> cyphermox: Ok
<tsimonq2> ARCHIVE ADMINS: please someone let lubuntu-meta through, and when you do, respin Lubuntu Zesty Beta 1 Alternate *and* Desktop images.
<slangasek> tsimonq2: ftr you need release team, not archive admins
<slangasek> (unblocked)
<tsimonq2> slangasek: Ah yes it's 11 PM so yeah :P
<tsimonq2> slangasek: I want someone else pressing buttons this late :P
<tsimonq2> (and yet I'm writing an English essay, procrastination is awesome >__<
<tsimonq2> )
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-111.158] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-111.158]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.22.3 => 2.22.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.22.3+16.10 => 2.22.6+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.22.3~14.04 => 2.22.6~14.04] (no packageset)
<Laney> tsimonq2: less of the gratuitous blaming please
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 1] has been updated (20170223)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 1] has been updated (20170223)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170223)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 1] has been updated (20170223)
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.3 => 1.11.8-0ubuntu0.4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3 => 1.13.4-3ubuntu0.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.1 => 1.13.4-1ubuntu1.2] (kubuntu, ubuntu-desktop, ubuntu-server)
<tsimonq2> Laney: I apologize, I meant it as a joke.
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] has been marked as ready
<Laney> tsimonq2: Ok, np, I saw a lot of reacting to a false claim that the builds weren't stopped
<tsimonq2> Laney: Got it, I was casually joking around ;)
<Laney> nod
<Laney> tsimonq2: So ... on topic
<tsimonq2> Yes... :)
<Laney> if everyone gets ready in the next 5 hours then I can release before I finish working
<Laney> otherwise, a few hours after that I'll be around again
<Laney> maybe you can do some hassling
<Laney> think some people would like the freeze to be lifted :-)
<tsimonq2> sakrecoer: Looks like Ubuntu Studio needs some testing yet, if you could take a look, that would be wonderful. :)
<tsimonq2> Laney: Oh that's right, you're in the UK, by the time I get out of school, it'll already be late for you... :/
<tsimonq2> Well, I think I can make something work. I have lunch at 11:35ish PM CST, we can release then?
<Laney> that's a late lunch
<tsimonq2> Not really for local time ;)
<Laney> do you mean UTC?
<tsimonq2> No, I didn't convert it, hold on
 * Laney is confused
<tsimonq2> Laney: s/11:35ish PM/17:35ish UTC/
<Laney> Anyway, you don't have to be there
<tsimonq2> Oh?
<Laney> If they're ready when I'm around then I can push buttons
<Laney> and you just send some announcement email whenever
<tsimonq2> Ok cool
<tsimonq2> Alright :)
<Laney> Just get them marked on the tracker
<Laney> and I think you mean 11:35 AM
<tsimonq2> Ah yes gah :P
<tsimonq2> Off to school I go, ttyl o/
<handsome_feng> Hi, jbicha, flexiondotorg, could you help to upload the ukui-menu(bug #1664229) or ukui-indicators(bug #1664232)? We are waiting for this to decide what to do next.Thank you!
<ubot5> bug 1664229 in Ubuntu Kylin "[FFe] ukui-menu" [Critical,New] https://launchpad.net/bugs/1664229
<ubot5> bug 1664232 in Ubuntu Kylin "[FFe] ukui-indicators" [Critical,New] https://launchpad.net/bugs/1664232
<flexiondotorg> Laney Any chance you could help handsome_feng out with the UKUI uploads for Ubuntu Kylin?
<Laney> flexiondotorg: Not right this second, maybe later ...
<Laney> Aren't there like 7 packageS?
<Laney> That's quite an ask
<handsome_feng> Thanks, flexiondotorg, Laney, Maybe you can upload one or two packages first in these two days?
<jbicha> is there anyone around who can accept new packages into stable releases? we're starting to run out of time for bug 1652537
<ubot5> bug 1652537 in chrome-gnome-shell (Ubuntu Xenial) "Update chrome-gnome-shell to version 8 in all supported releases" [High,In progress] https://launchpad.net/bugs/1652537
<rbasak> sil2100: were you looking at this? ^
<rbasak> W
<rbasak> Or was that on the basis that Yakkety already had the package?
<sil2100> Let me remind myself of the context for that one
<sil2100> Yeah, so that one had a yakkety release already, so it was just a matter of reviewing the SRU
<sil2100> But I have no formal power to accept NEW packages
<sil2100> So it would have to have some real archive admin looking into that
<rbasak> If we did have the formal power, would there be anything in Launchpad stopping us?
<rbasak> Because this came up with the letsencrypt stuff too. And we expect to be backporting more stuff back generally with the new feature exception.
<rbasak> So it might be worth asking the TB to give us the formal power when the package is a straight backport from the development release (since it'd have had AA eyes on it already).
<rbasak> One caveat might be that the interactions with other packages may be different for a previous release, so we would need to check that.
<rbasak> It might be reasonable to conclude that AA eyes *are* required. But at least then we'll know and not be stuck in limbo.
<jbicha> I believe slangasek accepted snapd into trusty, but is he the only one that can do this?
-queuebot:#ubuntu-release- New: rejected gnome-recipes [source] (zesty-proposed) [0.12.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-bgpvpn [source] (zesty-proposed) [5.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-bagpipe [source] (zesty-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted os-faults [source] (zesty-proposed) [0.1.10-0ubuntu1]
-queuebot:#ubuntu-release- New binary: os-faults [amd64] (zesty-proposed/none) [0.1.10-0ubuntu1] (no packageset)
<Laney> sil2100: Pretty sure you do have the power
<Laney> I know I can do NEWing for -backports
<sil2100> Power, yes, formal permission, no
<Laney> You said "formal power"...
<sil2100> Yeah, formalities I mean in overall
<sil2100> For now I'm only to use this for kernel SRU purposes
-queuebot:#ubuntu-release- New binary: networking-bagpipe [amd64] (zesty-proposed/universe) [6.0.0-0ubuntu1] (no packageset)
<Laney> 'k, I see what you mean
<Laney> I think that the TB's delegation includes NEWing things as appropriate, but maybe that's just me :P
<rbasak> We should just ask the TB.
<rbasak> Then we'd know.
<jbicha> especially if none of the active SRU members are full AAs
<rbasak> Which packages raise this question? chrome-gnome-shell, letsencrypt, anything else?
<jbicha> https://launchpad.net/ubuntu/xenial/+queue?queue_state=0
<Laney> Do what you want, obviously.
<jbicha> I'm also trying to get flatpak (with ostree and bubblewrap) into xenial
<jbicha> flatpak also would be better with xdg-desktop-portal and xdg-desktop-portal-gtk so I'll probably work on those once these others are done
<rbasak> technical-board@ email sent.
<LocutusOfBorg> hi cjwatson , can I sync acct? the delta says: "Remove stop links from rc0 and rc6."
<LocutusOfBorg> is this still a problem with systemd? I guess this was an upstart issue
<cjwatson> no time to look this week, sorry.
<cjwatson> that sort of change was generally from https://wiki.ubuntu.com/Teardown
<cjwatson> I don't know what effect it has with systemd
<LocutusOfBorg> asked pitti on -devel :)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted puppet [source] (yakkety-proposed) [4.5.2-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted puppet [source] (xenial-proposed) [3.8.5-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (yakkety-proposed) [0.23-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (xenial-proposed) [0.22-1ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted pg-repack [source] (yakkety-proposed) [1.3.4-1ubuntu0.1]
<tsimonq2> Could we please get some testers on Lubuntu and Ubuntu Studio for Zesty Beta 1?
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.8-0ubuntu1~ubuntu16.04.1 => 2.0.9-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.4]
<tsimonq2> Laney: So I guess it'll be a few hours?
<Laney> Well, not everybody is ready, so ...
-queuebot:#ubuntu-release- Unapproved: rejected lxd [source] (xenial-proposed) [2.0.9-0ubuntu1~16.04.2]
<tsimonq2> Laney: I'll be leaving in 15 mins, be back for 4 PM CST
<Laney> I'll just publish whatever is ready in 4 hours or so
<Laney> Others can have a late release if they want it, but the freeze will be lifted then
<tsimonq2> When Lubuntu is fully tested, you have my permission to mark as ready
<tsimonq2> Gotcha
-queuebot:#ubuntu-release- Unapproved: accepted wine1.6 [source] (xenial-proposed) [1:1.6.2-0ubuntu14.2]
<tsimonq2> (not that you need my permission :P)
<slangasek> tsimonq2: get some testers> you're also asking this question in the flavor community channels, right?
<tsimonq2> slangasek: Yep
<slangasek> ok
<flocculant> next time around - I'll try and be the community lead if laney is doing the canonical bits - might help some to have same timezone
<tsimonq2> flocculant: Good idea
<slangasek> tsimonq2: it's no problem for you to ask here, just want to make sure the flavor communities are on board with doing this milestone since it's their responsibility to do the testing :)
<tsimonq2> slangasek: Yep ;)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.8-0ubuntu1~ubuntu16.04.1 => 2.0.9-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
<tsimonq2> I'm the Lubuntu guy now, I've been trying...
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.9-0ubuntu1~16.04.2]
<stgraber> bdmurray: wow, that's express service, I didn't even see it hit the queue before you accepted it! Thanks! :)
<bdmurray> stgraber: just a coincidence! is there going to be one for trusty?
<stgraber> bdmurray: LXD in trusty is in -backports so I'll just backport the xenial package once it hits updates
<bdmurray> stgraber: okay
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.0 => 20160930-0ubuntu3~14.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-111.158~precise1] (kernel)
<tsimonq2> Laney: Clear for launch ;)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 1] has been marked as ready
<Laney> tsimonq2: Righto, let's get started then
 * Laney thanks past slangasek for fixing publish-image-set wrt budgie
<tsimonq2> Laney: Awesome :)
<tsimonq2> Laney: I'll be home in 30, I'll send the announcement right away
<Laney> Unlikely to be quite that fast
<Laney> but you can start writing it
<Laney> sakrecoer: tsimonq2: Ubuntu Studio is ready for amd64 only, FYI
<tsimonq2> Ok
<tsimonq2> Laney: On mobile? :/
<Laney> Can publish that one later if necessary
<Laney> Or just leave it out
<tsimonq2> I think it's sakrecoer's or Rosco2's choice ^^^^
<Laney> Sure
<Laney> I'm going to lift the freeze now too
<slangasek> Laney: hey, why doesn't present slangasek get any credit
<flocculant> slangasek: were you present and correct :)
<Laney> Any credit is strictly time limited and must be redeemed within 10ns
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (xenial-proposed) [2.26.1-1ubuntu1~16.04.4]
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Beta 1] has been marked as ready
 * tsimonq2 verifies everything is published
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.22.6+16.10]
<tsimonq2> Laney, infinity, slangasek: Am I just too impatient, or is Ubuntu Budgie not publishing correctly?
<Laney> The first one.
<tsimonq2> Laney: Aaaaha
-queuebot:#ubuntu-release- Unapproved: thermald (yakkety-proposed/main) [1.5.3-4 => 1.5.3-5] (core)
<tsimonq2> Laney: Are you publishing Ubuntu Studio i386? It's marked as ready.
 * tsimonq2 is waiting to send the announcement until all the images show up
<Laney> Already done
<Laney> You should in fact wait for me to tell you I've finished :P
<Laney> Waiting for the last thing
<tsimonq2> ok
<Laney> tsimonq2: ok, once studio appears you can go
<tsimonq2> Laney: Ok, sleep well ;)
<Laney> ah, what great timing, there it is
<Laney> night
<Laney> oh I should say - cron builds are back on and the milestone is marked as released
<Laney> -> back to dailies
<tsimonq2> Yay ok thanks :)
#ubuntu-release 2017-02-24
<tsimonq2> Could someome please approve my message in the ubuntu-devel-announce mailing list queue?
<tsimonq2> *someone
<cjwatson> tsimonq2: done
<tsimonq2> cjwatson: kthx
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (yakkety-proposed/universe) [8-2ubuntu3~ubuntu16.10.1 => 8-2ubuntu3~ubuntu16.10.2] (no packageset)
-queuebot:#ubuntu-release- New source: chrome-gnome-shell (xenial-proposed/primary) [8-2ubuntu4~ubuntu16.04.0]
-queuebot:#ubuntu-release- New source: chrome-gnome-shell (trusty-proposed/primary) [8-2ubuntu4~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: chrome-gnome-shell (yakkety-proposed/universe) [8-2ubuntu3~ubuntu16.10.1 => 8-2ubuntu4~ubuntu16.10.1] (no packageset)
<Mirv> I don't know quite how to explain the i386 only camitk autopkgtest failure at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src but also it seems unlikely the tray icon patches would cause the error of detecting unknown CamiTK version..
<Mirv> anyway, that one would be the only one blocking the migration of that patch update
-queuebot:#ubuntu-release- Unapproved: rejected chrome-gnome-shell [source] (yakkety-proposed) [8-2ubuntu3~ubuntu16.10.2]
-queuebot:#ubuntu-release- New: rejected chrome-gnome-shell [source] (xenial-proposed) [8-2ubuntu3~ubuntu16.04.0]
-queuebot:#ubuntu-release- New: rejected chrome-gnome-shell [source] (trusty-proposed) [8-2ubuntu3~ubuntu14.04.1]
<apw> jbicha, chrome-gnome-shell ... i think these backports look reasonable, but can you explain the odd numbering on xenial please
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (yakkety-proposed) [8-2ubuntu4~ubuntu16.10.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-111.158~precise1]
<Laney> oops, probably didn't mean to uncomment edubuntu :-)
<fossfreedom_> jbicha: thanks - was aware of that issue for the yakkety gnome-control-center.  Little surprised the GTK+3.24 gnome-control-center/libinput still having the same issues :/
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-65.86] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-65.86]
<ogra_> can someone let snapd out of the unapproved queue on xenial ?
<apw> ogra_, right now it is holding for a potential regression between it and apparmor
<ogra_> apw, thanks for the info
<ogra_> apw, any info what that regression is ?
<apw> ogra_, hopefully the comment from me on the SRU bug says which bug we are waiting on
<ogra_> ah
<apw> ogra_, oh yeah i even included the bug #
<ogra_> apw, yeah, i see it ... zyga has concerns though
<zyga> apw: hey, I'm interested in the kernel regression and snapd
<zyga> apw: jjohansen has informed me (also in the bug report) that this is not a regression but a feature
<apw> ogra_, it looks from the last two comments he was happy
<zyga> apw: and that snapd should be updated to cope
<apw> zyga, are you happy :)
<zyga> apw: not sure
<zyga> apw: it's raining, my mother in law is coming today and we have medium fire in snapd all over ;-)
<zyga> apw: seriously, not sure what to do yet
<zyga> apw: if the bug just affects classic + jailmode snaps the this is irrelevant
<apw> with my "SRU member dealing with these snapd updates" hat on i think i am waiting for updates to snapd for all series z down
<zyga> apw: if it affects more then we need to fix it in snapd and push this out ASAP
<apw> zyga, well it is affecting your tests :)
<zyga> apw: one specific test that checks a very niche usecase
<zyga> apw: we also have a wide-spread problem that .6 is addressing
<jjohansen> zyga: it potentially affects more, I can't say where it will surface
<zyga> apw: I'd trade the wide spread problem for the niche one any day
<zyga> jjohansen: I see
<zyga> jjohansen: so the rule you mentioned should land to the base template
<zyga> jjohansen: is it sufficient for libc or should we open up 'm' to all the thnigs in core?
<apw> jjohansen, that is the one jamie suggests in comment #1 right ?
<jjohansen> zyga: I am not sure, I would just go libc but I tend to be conservative
<zyga> jjohansen: I see
<zyga> jjohansen: I'll prepare a patch but we will also need to refresh all the profiles in snapd on startup
<zyga> (like we do with seccomp now)
<apw> jjohansen, have those changes been submitted for Y/X/T yet ?
<jjohansen> apw: yes
<jjohansen> apw: well not trusty, I need to  look at its kernel more
<apw> so i am reading that to say the current pending snapd in y/x/y are all only "as bad" as the one in -updates
<jjohansen> sounds right
-queuebot:#ubuntu-release- New source: chrome-gnome-shell (xenial-proposed/primary) [8-2ubuntu4~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: rejected chrome-gnome-shell [source] (xenial-proposed) [8-2ubuntu4~ubuntu16.04.0]
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [source] (xenial-proposed) [8-2ubuntu4~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: chrome-gnome-shell [amd64] (xenial-proposed/universe) [8-2ubuntu4~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [source] (trusty-proposed) [8-2ubuntu4~ubuntu14.04.1]
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [amd64] (xenial-proposed) [8-2ubuntu4~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: chrome-gnome-shell [i386] (trusty-proposed/none) [8-2ubuntu4~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted chrome-gnome-shell [i386] (trusty-proposed) [8-2ubuntu4~ubuntu14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.22.6]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.22.6~14.04]
<apw> ogra_, ok the old and new snapd will be equally affected by the incoming apparmor changes so i have accepted those snapd updates
<ogra_> zyga, ^^^
-queuebot:#ubuntu-release- Unapproved: pepperflashplugin-nonfree (yakkety-proposed/multiverse) [1.8.2+nmu1ubuntu1 => 1.8.2+nmu1ubuntu1.1] (no packageset)
<zyga> apw: thank you
<zyga> apw: I'm sure we'll work on 2.22.7 with a reaction to kernel changes
-queuebot:#ubuntu-release- Unapproved: pepperflashplugin-nonfree (xenial-proposed/multiverse) [1.8.2ubuntu1 => 1.8.2ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu3~14.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-40.43] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected thermald [source] (yakkety-proposed) [1.5.3-5]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-40.43]
-queuebot:#ubuntu-release- Unapproved: thermald (yakkety-proposed/main) [1.5.3-4 => 1.5.3-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: wget (xenial-proposed/main) [1.17.1-1ubuntu1.1 => 1.17.1-1ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (yakkety-proposed/main) [1:2.0.10-2ubuntu1 => 1:2.0.10-2ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2 => 1:2.0.10-1ubuntu2.1] (core)
#ubuntu-release 2017-02-25
<cyphermox> hi, can I please have a feature freeze exception for two new versions of packages we have in Ubuntu but are now in Debian (with newer versions). both are leaf packages that won't otherwise affect the flavors: bug 1667502 and bug 1667498
<ubot5> bug 1667502 in tpm2-tools (Ubuntu) "[FFE] Sync tpm2-tools from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1667502
<ubot5> bug 1667498 in tpm2-tss (Ubuntu) "[FFe] Sync tpm2-tss 1.0-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1667498
-queuebot:#ubuntu-release- Unapproved: pepperflashplugin-nonfree (trusty-proposed/multiverse) [1.3ubuntu1 => 1.3ubuntu1.1] (no packageset)
<jbicha> cyphermox: I'm not a Release Team member but I think unseeded universe generally don't need a FFe?
-queuebot:#ubuntu-release- New binary: mongo-cxx-driver-legacy [s390x] (zesty-proposed/universe) [1.1.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mongo-cxx-driver-legacy [ppc64el] (zesty-proposed/universe) [1.1.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mongo-cxx-driver-legacy [amd64] (zesty-proposed/universe) [1.1.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mongo-cxx-driver-legacy [i386] (zesty-proposed/universe) [1.1.2-5ubuntu1] (no packageset)
<cult-> hello
<cult-> my question is when this is going to be released to -updates? 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-, assuming there are no other issues found it looks like it hit 7 days today, so likely monday
<cult-> cool, can't wait
<bdmurray> I uploaded backuppc to the xenial queue 2 times yesterday and I received no email and don't see it in the queue...
<apw> bdmurray: expired key? unsigned? as is the package is not validly signed no email is sent
<apw> last upload showing in that queue is 18hrs ago
<apw> bdmurray: is your gpg key really 1024 bit DSA key?
<apw> I didn't think we accepted those any more
<cjwatson> bdmurray: 2017-02-25 00:16:10 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20170225-001512-000700/ubuntu/backuppc_3.3.1-2ubuntu3.2_source.changes': Unable to find mandatory field 'Date' in the changes file.
<cjwatson> hand-edited or something?
<cjwatson> (I think it's a bug that this doesn't send notifications - I had a branch in progress a while back to try to improve this, but I don't think I finished it
<cjwatson> )
-queuebot:#ubuntu-release- New source: ibm-java80 (xenial-proposed/partner) [8.0.4.1-0ubuntu1]
<cyphermox> jbicha: I know you can upload bugfixes any time, even past "main" final freeze for the unseeded packages up until very close to release day; but AFAICT Feature Freeze applies to everything.
<cyphermox> either way, this leaves around documentation that these packages changed
<cyphermox> (and I'm going back to my woodshop)
-queuebot:#ubuntu-release- New binary: tpm2-tss [amd64] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [s390x] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [i386] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [ppc64el] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [arm64] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [powerpc] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm2-tss [armhf] (zesty-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tpm2-tss [amd64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [armhf] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [powerpc] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [s390x] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [arm64] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [ppc64el] (zesty-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted tpm2-tss [i386] (zesty-proposed) [1.0-1]
#ubuntu-release 2017-02-26
-queuebot:#ubuntu-release- New source: gnome-recipes (zesty-proposed/primary) [0.16.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dianara (trusty-backports/universe) [1.3.2-1~ubuntu14.04.1 => 1.3.6-1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dianara (yakkety-backports/universe) [1.3.4-1 => 1.3.6-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dianara (xenial-backports/universe) [1.3.2-2build1 => 1.3.6-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [i386] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mongo-cxx-driver-legacy [amd64] (zesty-proposed) [1.1.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted mongo-cxx-driver-legacy [ppc64el] (zesty-proposed) [1.1.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-bagpipe [amd64] (zesty-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mongo-cxx-driver-legacy [i386] (zesty-proposed) [1.1.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted os-faults [amd64] (zesty-proposed) [0.1.10-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mongo-cxx-driver-legacy [s390x] (zesty-proposed) [1.1.2-5ubuntu1]
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (zesty-proposed/universe) [1.15.1+dfsg0-1~exp1ubuntu2] (no packageset)
#ubuntu-release 2018-02-19
-queuebot:#ubuntu-release- New: accepted ntpsec [amd64] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ntpsec [armhf] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ntpsec [ppc64el] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ntpsec [arm64] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ntpsec [s390x] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ntpsec [i386] (bionic-proposed) [1.0.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [armhf] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [ppc64el] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [arm64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [s390x] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sfnt2woff-zopfli [i386] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ignition-fuel-tools [amd64] (bionic-proposed) [1.0.0+dfsg4-2]
-queuebot:#ubuntu-release- New: accepted ignition-fuel-tools [armhf] (bionic-proposed) [1.0.0+dfsg4-2]
-queuebot:#ubuntu-release- New: accepted ignition-fuel-tools [ppc64el] (bionic-proposed) [1.0.0+dfsg4-2]
-queuebot:#ubuntu-release- New: accepted ignition-fuel-tools [arm64] (bionic-proposed) [1.0.0+dfsg4-2]
-queuebot:#ubuntu-release- New: accepted ignition-fuel-tools [i386] (bionic-proposed) [1.0.0+dfsg4-2]
-queuebot:#ubuntu-release- New: accepted apticron [amd64] (bionic-proposed) [1.2.0]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-zglob [amd64] (bionic-proposed) [0.0~git20171230.4959821-1]
-queuebot:#ubuntu-release- New: accepted proxy-switcher [amd64] (bionic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted python-jpype [arm64] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-jpype [i386] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-jpype [s390x] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted bulk-media-downloader [amd64] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-jpype [amd64] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-jpype [ppc64el] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted mithril [amd64] (bionic-proposed) [1.1.6-2]
-queuebot:#ubuntu-release- New: accepted python-jpype [armhf] (bionic-proposed) [0.6.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted knot-resolver [amd64] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted knot-resolver [armhf] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted knot-resolver [ppc64el] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted knot-resolver [arm64] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted knot-resolver [i386] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New binary: browserpass [s390x] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: browserpass [amd64] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: browserpass [ppc64el] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: browserpass [arm64] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: browserpass [armhf] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: browserpass [i386] (bionic-proposed/universe) [2.0.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.8 => 3.20.5-0ubuntu0.16.04.9] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gcc-8-cross-ports [ppc64el] (bionic-proposed/universe) [2ubuntu2] (no packageset)
<fossfreedom_> jbicha, I know the new tilix package is stuck in bionic-proposed due to a ppc build issue - but please can we block tilix from migrating once the ppc build is unblocked? Need to investigate this high priority issue that would make tilix unusable.  thanks https://bugs.launchpad.net/ubuntu/+source/tilix/+bug/1750322
<ubot5> Ubuntu bug 1750322 in tilix (Ubuntu) "Tilix Background Transparency" [High,Confirmed]
-queuebot:#ubuntu-release- New: accepted browserpass [amd64] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted browserpass [armhf] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted browserpass [ppc64el] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted browserpass [arm64] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted browserpass [s390x] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted browserpass [i386] (bionic-proposed) [2.0.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-36.40]
-queuebot:#ubuntu-release- New binary: gcc-8-cross [i386] (bionic-proposed/universe) [5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-8-cross [amd64] (bionic-proposed/universe) [5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-themes-standard [source] (artful-proposed) [3.22.3-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (artful-proposed/main) [3.22.3-1ubuntu1 => 3.22.3-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-themes-standard [source] (artful-proposed) [3.22.3-1ubuntu2]
<jbicha> fossfreedom_: add the block-proposed tag to that bug
-queuebot:#ubuntu-release- New binary: gcc-8-cross [arm64] (bionic-proposed/universe) [5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-8-cross [amd64] (bionic-proposed) [5ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross [i386] (bionic-proposed) [5ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross [arm64] (bionic-proposed) [5ubuntu2]
<xnox> apw, autopkgtests look clean; however 4.15.0-9-*udebs need cleanup / removal
<xnox> and then good to release linux 4.15?
<apw> xnox, as in nbs in -proposed i assume
<apw> xnox, yes, that; ok eraser applied
<jbicha> sil2100: could you accept LP: #1644662 for xenial too?
<ubot5> Launchpad bug 1644662 in gnome-themes-standard (Ubuntu Xenial) "Icons missing when appearance setting is "high contrast"" [High,In progress] https://launchpad.net/bugs/1644662
<superm1> I've uploaded backports for bug 1748583 to trusty-backports and xenial-backports, can I please get someone to review them?
<ubot5> bug 1748583 in Xenial Backports "Please backport libsmbios 2.4.0-1 (main) from bionic-proposed" [Undecided,New] https://launchpad.net/bugs/1748583
<jbicha> fossfreedom_: sounds like you may want to add a vte2.91 task to that bug to keep that from migrating until the tilix bug is fixed too
-queuebot:#ubuntu-release- New source: bolt (bionic-proposed/primary) [0.1-0ubuntu1]
<sil2100> jbicha: will review it in a moment
<sil2100> I was in an area without internet
<jbicha> scary place to be ;)
<sil2100> Yeah, usually there were no internet issues with my parents place but this time was somehow unlucky
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3 => 0.6.5.11-1ubuntu3.1] (core)
-queuebot:#ubuntu-release- New binary: gcc-8-cross-ports [amd64] (bionic-proposed/universe) [2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu18 => 0.6.5.6-0ubuntu19] (no packageset)
<acheronuk> iso issue? http://cdimage.ubuntu.com/ubuntu/daily-live/current/
<acheronuk> has not been updated since the 14th
<sil2100> jbicha: I had to reject the first g-t-s upload and reupload, so don't be surprised by a rejection message
-queuebot:#ubuntu-release- Unapproved: rejected gnome-themes-standard [source] (xenial-proposed) [3.18.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (xenial-proposed/main) [3.18.0-2ubuntu1 => 3.18.0-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-themes-standard [source] (xenial-proposed) [3.18.0-2ubuntu2]
-queuebot:#ubuntu-release- New binary: gcc-8-cross-ports [i386] (bionic-proposed/universe) [2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.9]
-queuebot:#ubuntu-release- New binary: x2goserver [s390x] (bionic-proposed/none) [4.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lavacli [amd64] (bionic-proposed/none) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: visidata [amd64] (bionic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [amd64] (bionic-proposed/none) [4.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [i386] (bionic-proposed/none) [4.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-dracclient [amd64] (bionic-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: likwid [i386] (bionic-proposed/none) [4.3.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: likwid [amd64] (bionic-proposed/none) [4.3.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [ppc64el] (bionic-proposed/none) [4.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [i386] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [s390x] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [ppc64el] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [amd64] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [arm64] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgnome-games-support [armhf] (bionic-proposed/main) [1.3.90-1] (ubuntu-desktop)
<tsimonq2> acheronuk: There's ISOs in pending which means that automated tests aren't passing for Ubuntu Desktop
<acheronuk> :/
<tsimonq2> sil2100, slangasek: Can I please get a review on calamares-settings-ubuntu? The total size is like 1.6 MB with most of that being PNGs, and I'd like to switch Lubuntu Next over to Calamares sooner rather than later.
<acheronuk> 14th will be good enough for what I want :)
-queuebot:#ubuntu-release- New binary: x2goserver [arm64] (bionic-proposed/universe) [4.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x2goserver [armhf] (bionic-proposed/universe) [4.1.0.0-1] (no packageset)
<tsimonq2> juliank: Thanks for the apt upload!
<sil2100> tsimonq2: where is that?
<sil2100> Ah, bionic NEW
<sil2100> hm, ok, I can look into that, since I see there's quite a backlog - I'm still an AA 'in training' so I don't do regular reviews yet
<ahasenack> apw: hi, remember zstd? The artful package is also in the same "new" state: https://launchpad.net/ubuntu/artful/+queue
<ahasenack> rbasak: ^
<sil2100> Didn't I approve those?
<sil2100> Oh, was that for xenial?
<sil2100> Ah yes, for xenial
<sil2100> ahasenack: I can look at those as I did the previous ones IIRC
<ahasenack> sil2100: thanks
<ahasenack> sorry, I thought it had been apw
-queuebot:#ubuntu-release- New: accepted libzstd [amd64] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted libzstd [armhf] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted libzstd [ppc64el] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted libzstd [arm64] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted libzstd [s390x] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted libzstd [i386] (artful-proposed) [1.3.1+dfsg-1ubuntu0.1]
<ahasenack> yay \o/
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-ports [amd64] (bionic-proposed) [2ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-ports [ppc64el] (bionic-proposed) [2ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-ports [i386] (bionic-proposed) [2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [amd64] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [armhf] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [ppc64el] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [arm64] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [s390x] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted libgnome-games-support [i386] (bionic-proposed) [1.3.90-1]
-queuebot:#ubuntu-release- New: accepted lavacli [amd64] (bionic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted likwid [i386] (bionic-proposed) [4.3.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted visidata [amd64] (bionic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted likwid [amd64] (bionic-proposed) [4.3.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted python-dracclient [amd64] (bionic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [amd64] (bionic-proposed) [4.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [armhf] (bionic-proposed) [4.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [ppc64el] (bionic-proposed) [4.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [arm64] (bionic-proposed) [4.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [s390x] (bionic-proposed) [4.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted x2goserver [i386] (bionic-proposed) [4.1.0.0-1]
<LocutusOfBorg> slangasek, can you please move node-babel, node-gulp-babel, node-babylon to universe from multiverse? rationale is: now the bootstrap is finished, and Debian switched from contrib to main too... do you prefer a bug?
<slangasek> LocutusOfBorg: "now the bootstrap is finished"? it's not done at all in Ubuntu yet
<LocutusOfBorg> yes, it is :p
<LocutusOfBorg> it is publishing right now from my silo :)
<slangasek> ah? ok
<slangasek> LocutusOfBorg: are those the only three packages that need promoting?
<LocutusOfBorg> I'm uploading a no-change rebuild from the -release pocket, just to be sure everything is in place
<LocutusOfBorg> yes, I think they are the only packages, but I might be wrong...
<slangasek> ok, moving
<LocutusOfBorg> I'm not really sure how to check that
<LocutusOfBorg> thanks!
<LocutusOfBorg> in case I guess the new no-change rebuilds will complain if some bits are still in multiverse?
<slangasek> LocutusOfBorg: "complain" in that they'll wind up stuck in dep-wait, yes
<LocutusOfBorg> slangasek, node-regenerator-transform please :)
<LocutusOfBorg> slangasek, regenerator-transform is the only one, according to the build logs of the versions in release (they all picked only that package from multiverse)
-queuebot:#ubuntu-release- New binary: node-babel-loader [amd64] (bionic-proposed/universe) [7.1.2-4] (no packageset)
<LocutusOfBorg> hurray stuff is unblocking :)
<tsimonq2> \o\ /o/ \o\
<LocutusOfBorg> maybe apw or somebody else can do the node-regenerator-transform move to universe?
 * LocutusOfBorg falls asleep
<LocutusOfBorg> g night
-queuebot:#ubuntu-release- New binary: golang-github-ugorji-go-codec [s390x] (bionic-proposed/universe) [1.1+git20171228.f2ec36a-3] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [s390x] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ugorji-go-codec [amd64] (bionic-proposed/universe) [1.1+git20171228.f2ec36a-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-warnings.v0 [amd64] (bionic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ugorji-go-codec [ppc64el] (bionic-proposed/universe) [1.1+git20171228.f2ec36a-3] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [i386] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [amd64] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ugorji-go-codec [arm64] (bionic-proposed/universe) [1.1+git20171228.f2ec36a-3] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [ppc64el] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [arm64] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New binary: osmo-libasn1c [armhf] (bionic-proposed/universe) [0.9.28-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [amd64] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [armhf] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [ppc64el] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [arm64] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [s390x] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted osmo-libasn1c [i386] (bionic-proposed) [0.9.28-2]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-warnings.v0 [amd64] (bionic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-babel-loader [amd64] (bionic-proposed) [7.1.2-4]
#ubuntu-release 2018-02-20
-queuebot:#ubuntu-release- Unapproved: accepted supermin [source] (xenial-proposed) [5.1.14-2ubuntu1.1]
<slangasek> LocutusOfBorg: done, thanks!
-queuebot:#ubuntu-release- New binary: node-console-group [amd64] (bionic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-ugorji-go-codec [amd64] (bionic-proposed) [1.1+git20171228.f2ec36a-3]
-queuebot:#ubuntu-release- New: accepted golang-github-ugorji-go-codec [ppc64el] (bionic-proposed) [1.1+git20171228.f2ec36a-3]
-queuebot:#ubuntu-release- New: accepted golang-github-ugorji-go-codec [arm64] (bionic-proposed) [1.1+git20171228.f2ec36a-3]
-queuebot:#ubuntu-release- New: accepted node-console-group [amd64] (bionic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ugorji-go-codec [s390x] (bionic-proposed) [1.1+git20171228.f2ec36a-3]
-queuebot:#ubuntu-release- New binary: node-postcss-filter-plugins [amd64] (bionic-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-buble [amd64] (bionic-proposed/universe) [0.18.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-fbjs [amd64] (bionic-proposed/universe) [0.8.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-babel-preset-env [amd64] (bionic-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-vue-template-compiler [amd64] (bionic-proposed/universe) [2.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-katex [amd64] (bionic-proposed/universe) [0.8.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-uglifyjs-webpack-plugin [amd64] (bionic-proposed/universe) [0.4.6-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-babel-plugin-precompile-charcodes [amd64] (bionic-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-babel-plugin-transform-decorators-legacy [amd64] (bionic-proposed/universe) [1.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-babel-plugin-transform-define [amd64] (bionic-proposed/universe) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-escope [amd64] (bionic-proposed/universe) [3.6.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-babel-plugin-precompile-charcodes [amd64] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted node-babel-plugin-transform-define [amd64] (bionic-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted node-buble [amd64] (bionic-proposed) [0.18.0-1]
-queuebot:#ubuntu-release- New: accepted node-fbjs [amd64] (bionic-proposed) [0.8.16-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-filter-plugins [amd64] (bionic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-vue-template-compiler [amd64] (bionic-proposed) [2.4.2-1]
-queuebot:#ubuntu-release- New: accepted node-babel-plugin-transform-decorators-legacy [amd64] (bionic-proposed) [1.3.4-2]
-queuebot:#ubuntu-release- New: accepted node-escope [amd64] (bionic-proposed) [3.6.0+ds-2]
-queuebot:#ubuntu-release- New: accepted node-uglifyjs-webpack-plugin [amd64] (bionic-proposed) [0.4.6-4]
-queuebot:#ubuntu-release- New: accepted node-babel-preset-env [amd64] (bionic-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted node-katex [amd64] (bionic-proposed) [0.8.3+dfsg-1]
<LocutusOfBorg> hello slangasek, I still see node-regenerator-transform in multiverse...
<slangasek> LocutusOfBorg: sorry, I fixed binary but not source; fixing now
<LocutusOfBorg> slangasek, also please node-webpack
<LocutusOfBorg> I see a lot of nodejs stuff old 40 days ago, and they will need some moving to sto being dep-wait
<slangasek> right, well node-webpack also needs node-uglifyjs-webpack-plugin to publish first so that it actually builds; but yeah, overridden now
<LocutusOfBorg> yes slangasek I'm following also uglifyjs-webpack, in one hour I'll know if anything else is missing, but BTW they seems to be already all in universe
<LocutusOfBorg> so, with some luck by the end of today, we will see ~20 new packages :)
<slangasek> yep :)
<slangasek> now, any idea why there are arm-specific autopkgtest regressions with new nodejs? :/
<LocutusOfBorg> tsimonq2, ^^ wants to merge new openssl from Debian? should we keep the ssl delta now that we have 1.1?
<LocutusOfBorg> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
<LocutusOfBorg> the regressions are mostly uninstallabilities...
<LocutusOfBorg> maybe something hasn't been built correctly
<slangasek> LocutusOfBorg: node-babel-preset-env -> node-browserslist -> node-caniuse-lite also needs bootstrapped
<slangasek> LocutusOfBorg: and blocks node-webpack, via node-webpack -> node-acorn-dynamic-import -> node-babel-preset-airbnb -> node-babel-preset-env
<LocutusOfBorg> ack wilco
<LocutusOfBorg> after coffee :)
<acheronuk> hi. is there an issue with flavours shipping a ppa sources list in /etc/apt/sources/ even if disabled by default? I vaguely recall this was a red line 'thou shall not cross', but could be wrong?
<acheronuk> *sources.d/
 * acheronuk is not overly keen on the idea
<acheronuk> but it is being discussed by some people in kubuntu
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.20 => 20101020ubuntu451.21] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.21]
<slangasek> acheronuk: why would you ship it if it's disabled by default?  But yes, it is a red line
-queuebot:#ubuntu-release- New binary: node-caniuse-lite [amd64] (bionic-proposed/universe) [1.0.30000792+dfsg-1build1] (no packageset)
<acheronuk> slangasek: so that users can get newer KDE stuff more easily was the idea. i.e. enable a source already there in the software centre
<acheronuk> personally I don't like the idea anyway, so if a red line, good
<acheronuk> we do a lot via our backports PPA for people who want new shiny stuff, but support on it is very limited, and adding that in by default (even if disabled) sends the wrong message on that IMO
<LocutusOfBorg> node-canuse please do *not* accept it, I'm going with a new bileto
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-36.40~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted node-caniuse-lite [amd64] (bionic-proposed) [1.0.30000792+dfsg-1build1]
<LocutusOfBorg> damn
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-36.40~16.04.1]
<chrisccoulson> hi, it looks like ubuntu-drivers-common 1:0.4.17.6 is ready to copy from xenial-proposed to xenial-updates (see bug 1728547)
<ubot5> bug 1728547 in HWE Next "SRU: Add support for keeping the dGPU on in power saving mode" [Undecided,New] https://launchpad.net/bugs/1728547
<chrisccoulson> I've got an update to publish to xenial-security, which is kinda blocked on this at the moment
-queuebot:#ubuntu-release- New binary: node-acorn-dynamic-import [amd64] (bionic-proposed/multiverse) [2.0.2-3build3] (no packageset)
<apw> chrisccoulson, that has one bug which is verified and one which is not ?
<chrisccoulson> apw, if you're referring to bug 1731873, it looks like a later upload to xenial-proposed dropped that change
<ubot5> bug 1731873 in OEM Priority Project "Backport amdgpu-pro support" [High,New] https://launchpad.net/bugs/1731873
<chrisccoulson> might be worth confirming that with tseliot though
<tseliot> chrisccoulson, apw: yes, we had to drop that code, since nobody was available to test it, and I don't have the hardware here
-queuebot:#ubuntu-release- New binary: node-acorn-dynamic-import [amd64] (bionic-proposed/multiverse) [2.0.2-3build4] (no packageset)
<doko> trying to understand:
<doko> gcc-8-powerpc-linux-gnuspe/i386 unsatisfiable Depends: libgcc-8-dev-powerpcspe-cross (>= 8-20180218-1ubuntu1cross1)
<doko> libgcc-8-dev-powerpcspe-cross is an arch all package
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (trusty-proposed/main) [2:9.4.0-1280544-5ubuntu6.3 => 2:9.4.0-1280544-5ubuntu6.4] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: node-acorn-dynamic-import [amd64] (bionic-proposed/multiverse) [2.0.2-3build5] (no packageset)
<LocutusOfBorg> please accept node-acorn-dynamic-import!
<LocutusOfBorg> doko, maybe that arch:all depends on some arch:any not available on i386?
<cjwatson> The gcc-8-cross-ports thing seems to have been a double-override accident.  I've done a self-copy to recover it.
<LocutusOfBorg> whoever will accept node-acorn-dynamic-import, please move it to universe when accepting it
<LocutusOfBorg> (it is in main now in Debian, and the bootstrap is complete)
-queuebot:#ubuntu-release- New binary: node-preact [amd64] (bionic-proposed/universe) [8.2.5-1] (no packageset)
<LocutusOfBorg> AAping :)
<LocutusOfBorg> accepting node-acorn will unblock ~20 nodejs packages
<LocutusOfBorg> (or better, will make node-webpack build and then unblock ~20 nodejs packages)
<cjwatson> doing
<LocutusOfBorg> <3
<tsimonq2> LocutusOfBorg: sure
<LocutusOfBorg> oh please move to universe cjwatson :)
<cjwatson> I did
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- New: accepted node-acorn-dynamic-import [amd64] (bionic-proposed) [2.0.2-3build3]
-queuebot:#ubuntu-release- New: accepted node-acorn-dynamic-import [amd64] (bionic-proposed) [2.0.2-3build5]
<LocutusOfBorg> it is hard to bootstrap such circular deps
-queuebot:#ubuntu-release- New: accepted node-acorn-dynamic-import [amd64] (bionic-proposed) [2.0.2-3build4]
-queuebot:#ubuntu-release- New: accepted node-preact [amd64] (bionic-proposed) [8.2.5-1]
<LocutusOfBorg> I hope you did also move the source to universe, not only the binary...
<LocutusOfBorg> maybe slow publisher is tricking me
<cjwatson> LocutusOfBorg: yes, I did
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- New binary: node-grunt-babel [amd64] (bionic-proposed/universe) [7.0.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu19]
<slangasek> acheronuk: right - so the people proposing this for kubuntu know about the integration of snaps?  Is that not a solution for what they're looking for here?
-queuebot:#ubuntu-release- New: accepted node-grunt-babel [amd64] (bionic-proposed) [7.0.0-3]
<LocutusOfBorg> thanks! whoever accepted it
<acheronuk> slangasek: I'm sure they do. probably not good for this LTS though. especially as we are talking about things like plasma release upgrades
<jbicha> the red line is a bit fuzzier with what mate-welcome doesâ¦
<slangasek> acheronuk: ok
<slangasek> jbicha: what is that, exactly?
<acheronuk> adds ppas for some apps in it? if you chose to install?
 * acheronuk could be wrong
<jbicha> slangasek: I thought the Tech Board was aware of how mate-welcome makes it very easy for users to get certain apps from ppas
<slangasek> jbicha: I have had zero visibility on the specifics of a mate-welcome ui.  We obviously allow everyone to enable any ppa simply through add-apt-repository, so wrapping that with an equivalent UX is fine
<slangasek> jbicha: the red line is "don't enable third party sources by default or add additional non-Canonical-controlled keys to the keyring by default"
<jbicha> I wouldn't describe MATE's Software Boutique as merely a frontend to add-apt-repository
<jbicha> if you do have a red line, I think you really should look into it for yourself so you're aware of how the line has been fuzzy for several releases now
<slangasek> mm
<slangasek> jbicha: anyway, to say that the TB was aware of this... I don't remember seeing it on the tb list or in any meetings I was at
<jbicha> hmm, I thought I had hinted about it before but I don't see logs of that
<jbicha> I mean I'm a bit uncomfortable with setting things in motion that could mean the removal of a popular Ubuntu MATE featureâ¦
<jbicha> maybe just adding more explanatory text would alleviate any TB concerns
<jbicha> it's pretty to test. Just boot Ubuntu Mate 17.10 iso, run the Software Boutique, click say the Internet (globe) category and install the Brave browser
-queuebot:#ubuntu-release- Unapproved: libgcrypt20 (xenial-proposed/main) [1.6.5-2ubuntu0.3 => 1.6.5-2ubuntu0.4] (core)
<jbicha> I guess that one's not technically a PPA, it's a 3rd party repo but the same idea
<jbicha> there is a details button that tells you the source of the package if you click on it
<nacc> yeah, iirc, i brought this up as well a while ago
<nacc> had a user in #ubuntu thinking they were running supported software from ubuntu
<nacc> when they were not
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.29.4.2~14.04 => 2.31.1~14.04] (no packageset)
<jbicha> I guess the cat's out of the bag now and I should send a formal email
<jbicha> when's the next TB meeting scheduled?
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.4.2+17.10 => 2.31.1+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.4.2 => 2.31.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: node-jquery [amd64] (bionic-proposed/universe) [2.2.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-filesize [amd64] (bionic-proposed/universe) [3.5.11+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntirpc [s390x] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: auto-complete-el [amd64] (bionic-proposed/universe) [1.5.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntirpc [ppc64el] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [s390x] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libmonitoring-icinga2-client-rest-perl [amd64] (bionic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [amd64] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: ntirpc [amd64] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-truncdist [amd64] (bionic-proposed/none) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntirpc [i386] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [i386] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [ppc64el] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: ntirpc [arm64] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntirpc [armhf] (bionic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [arm64] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [armhf] (bionic-proposed/universe) [0.10-4] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12.2 => 234-2ubuntu12.3] (core)
-queuebot:#ubuntu-release- Unapproved: python-apt (xenial-proposed/main) [1.1.0~beta1build1 => 1.1.0~beta1ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (xenial-proposed) [1.1.0~beta1ubuntu0.16.04.1]
<LocutusOfBorg> why did I try to bootstrap node stuff?
<LocutusOfBorg> damn me
<LocutusOfBorg> everything build-depends on itself
<nacc> LocutusOfBorg: welcome to hell :)
<jbicha> slangasek: please review https://code.launchpad.net/~jbicha/britney/update-gvfs/+merge/337772
-queuebot:#ubuntu-release- New: accepted auto-complete-el [amd64] (bionic-proposed) [1.5.1-0.1]
-queuebot:#ubuntu-release- New: accepted libmonitoring-icinga2-client-rest-perl [amd64] (bionic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-filesize [amd64] (bionic-proposed) [3.5.11+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ntirpc [amd64] (bionic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted ntirpc [armhf] (bionic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted ntirpc [ppc64el] (bionic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-truncdist [amd64] (bionic-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [arm64] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [i386] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [s390x] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted node-jquery [amd64] (bionic-proposed) [2.2.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ntirpc [i386] (bionic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [amd64] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [ppc64el] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted ntirpc [arm64] (bionic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [armhf] (bionic-proposed) [0.10-4]
-queuebot:#ubuntu-release- New: accepted ntirpc [s390x] (bionic-proposed) [1.6.1-1]
<slangasek> LocutusOfBorg: you just found rollup, didn't you? :)
<slangasek> jbicha: looking
<slangasek>                     "apt-key-url": "http://deb.playonlinux.com/public.gpg",
<slangasek> jbicha: yeaaaaahhh this is going to need a critical bug
<jbicha> when's your next scheduled TB meeting?
<slangasek> jbicha: next Tuesday @ 20:00 London time
<slangasek> jbicha: wrt the mp, 1.34.1-2ubuntu2 is in bionic now so we should retain the badtest for that version and cycle off 1.34.1-1ubuntu4 instead
<slangasek> jbicha: (I'll fix that up here, just letting you know)
<slangasek> jbicha: that will set libgphoto2's test back to 'regression', but they can just be retried with the newer version
<jbicha> maybe we don't even need the 1.34 hint? (I was thinking it was for artful but that doesn't match here either)
<slangasek> jbicha: update_excuses definitely shows 1.34.1-2ubuntu2/s390x failures which are being ignored only because of this hint.  I don't like to drop badtest hints for versions while they're still the release version, that just makes more work for people trying to get packages through
<jbicha> it should migrate on the next run though
<jbicha> but I think I understand what you're saying now
<slangasek> jbicha: right - even if it does migrate, the other packages in -proposed that have been tested against the current release version will now also newly show up as regression, and would need re-tested against the new release version just to have the tests fail with the right version ;)
<jbicha> lol, yeah that's a waste of energy :)
-queuebot:#ubuntu-release- New binary: node-d3-transition [amd64] (bionic-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-jschardet [amd64] (bionic-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-array [amd64] (bionic-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-dispatch [amd64] (bionic-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-time [amd64] (bionic-proposed/universe) [1.0.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-prop-types [amd64] (bionic-proposed/universe) [15.6.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-axis [amd64] (bionic-proposed/universe) [1.0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-handlebars [amd64] (bionic-proposed/universe) [3:4.0.10-5] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-path [amd64] (bionic-proposed/universe) [1.0.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-ease [amd64] (bionic-proposed/universe) [1.0.3-2] (no packageset)
<LocutusOfBorg> slangasek, sigh
<LocutusOfBorg> anyhow, in the next few hours, a lot of node will build and unblock
<LocutusOfBorg> if you can accept it, the next run will mostly be the final one
-queuebot:#ubuntu-release- New binary: node-d3-polygon [amd64] (bionic-proposed/universe) [1.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-js-beautify [amd64] (bionic-proposed/universe) [1.7.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-selection [amd64] (bionic-proposed/universe) [1.1.0-3] (no packageset)
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- New binary: node-d3-queue [amd64] (bionic-proposed/universe) [3.0.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-color [amd64] (bionic-proposed/universe) [1.0.3-3] (no packageset)
<slangasek> LocutusOfBorg: yep, thanks!
<slangasek> LocutusOfBorg: I'm also almost to the bottom of the "uninteresting" autopkgtest failures blocking nodejs... leaving only the "interesting" ones
-queuebot:#ubuntu-release- New: accepted node-d3-array [amd64] (bionic-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted node-d3-color [amd64] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted node-d3-ease [amd64] (bionic-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted node-d3-polygon [amd64] (bionic-proposed) [1.0.3-3]
-queuebot:#ubuntu-release- New: accepted node-d3-selection [amd64] (bionic-proposed) [1.1.0-3]
-queuebot:#ubuntu-release- New: accepted node-d3-transition [amd64] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted node-js-beautify [amd64] (bionic-proposed) [1.7.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-prop-types [amd64] (bionic-proposed) [15.6.0+ds-1]
-queuebot:#ubuntu-release- New: accepted node-d3-axis [amd64] (bionic-proposed) [1.0.8-2]
-queuebot:#ubuntu-release- New: accepted node-d3-path [amd64] (bionic-proposed) [1.0.5-3]
-queuebot:#ubuntu-release- New: accepted node-d3-time [amd64] (bionic-proposed) [1.0.7-2]
-queuebot:#ubuntu-release- New: accepted node-jschardet [amd64] (bionic-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-d3-dispatch [amd64] (bionic-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted node-handlebars [amd64] (bionic-proposed) [3:4.0.10-5]
-queuebot:#ubuntu-release- New: accepted node-d3-queue [amd64] (bionic-proposed) [3.0.7-3]
<slangasek> jbicha: fwiw I'm still comfortable with the UbuntuKylin exception such as it was written, and there are reasons why snaps may not be a fit in the near term; but what MATE is doing is something quite different in terms of roots of trust
<jbicha> ok
<xnox> jbicha, slangasek - speaking of roots of trust, i believe last time i bought ubuntu preinstalled on dell, it had, in addition to ubuntu.com repositories, some .canonical.com repository, and some .dell.com repository =/
<xnox> but that was some years ago, i hope, more things are upstream now, with less of .canonical.com or .dell.com things pre-installed =/
<xnox> i think it was broadcom stuff and bluetooth things
-queuebot:#ubuntu-release- New binary: node-d3-time-format [amd64] (bionic-proposed/universe) [2.0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-drag [amd64] (bionic-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-quadtree [amd64] (bionic-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postcss [amd64] (bionic-proposed/universe) [6.0.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-interpolate [amd64] (bionic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-rw [amd64] (bionic-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-random [amd64] (bionic-proposed/universe) [1.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-chord [amd64] (bionic-proposed/universe) [1.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-shape [amd64] (bionic-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-geo [amd64] (bionic-proposed/universe) [1.9.0-4] (no packageset)
<LocutusOfBorg> we are mostly there
<slangasek> xnox: partner images are a different kettle of fishy keymatter
-queuebot:#ubuntu-release- New binary: node-d3-collection [amd64] (bionic-proposed/universe) [1.0.4-2] (no packageset)
<slangasek> xnox: you bought it preinstalled.  Turns out, the hardware vendor has control over what went on there
<slangasek> ;(
-queuebot:#ubuntu-release- New: accepted node-d3-chord [amd64] (bionic-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- New: accepted node-d3-quadtree [amd64] (bionic-proposed) [1.0.3-2]
<slangasek> ;) rather
-queuebot:#ubuntu-release- New: accepted node-postcss [amd64] (bionic-proposed) [6.0.16-1]
-queuebot:#ubuntu-release- New: accepted node-d3-geo [amd64] (bionic-proposed) [1.9.0-4]
-queuebot:#ubuntu-release- New: accepted node-d3-shape [amd64] (bionic-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted node-d3-drag [amd64] (bionic-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted node-d3-random [amd64] (bionic-proposed) [1.1.0-4]
-queuebot:#ubuntu-release- New: accepted node-rw [amd64] (bionic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted node-d3-interpolate [amd64] (bionic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted node-d3-time-format [amd64] (bionic-proposed) [2.0.5-2]
<LocutusOfBorg> thanks!
<slangasek> LocutusOfBorg: and with node-evp-bytestokey and node-temporary autopkgtest results trickling in, all the other autopkgtest regressions on nodejs are "real" - either some sort of ARM-specific breakage of nodejs, or non-trivial incompatibilities
<slangasek> (well, non-trivial to me)
<LocutusOfBorg> ack... I plan to try harder rollup tomorrow probably
<LocutusOfBorg> and with a publisher run we will kick the last node-d3* packages in release
<LocutusOfBorg> 4 are missing, one FTBFS in debian too
<LocutusOfBorg> and then I'll forget about node for some time
<LocutusOfBorg> I would appreciate your opinion about libunistring migration
<LocutusOfBorg> freeipa is sad for unrelated reasons ( tjaalton is looking at it)
<LocutusOfBorg> but I see a regression in tracker, and moving some bits in a test at the bottom "fixes" the test, but I don't understand why the new libunistring is ordering them differently, and I don't understand how sane is to patch tracker that way
<LocutusOfBorg> look at test.patch here https://launchpadlibrarian.net/357395526/tracker_2.0.3-1ubuntu4_2.0.3-1ubuntu5.diff.gz
<jbicha> could you file a tracker bug to ask the upstream maintainers what they think?
<LocutusOfBorg> some bits are just moved at the bottom of the file, and they start passting testsuite
<LocutusOfBorg> jbicha, I can try yes
<LocutusOfBorg> I had to disable a lot of new asserts, not sure how they will answer to that
 * LocutusOfBorg goes AFK
<slangasek> and then there are the node packages that are dep-wait on things which seem not to have been uploaded anywhere, meh (node-globby -> babeljs)
<slangasek> oh, provided by node-babel-cli
<LocutusOfBorg> slangasek, of course stuff in debian new queue is excluded from the 4 packages that will migrate once d3 are missing
<slangasek> so just needs a manual kick because the dep-wait didn't autoclear
<LocutusOfBorg> slangasek, there are 3-4 packages that runtime depends on some stuff that has not yet cleared debian new queue
 * slangasek nods
<LocutusOfBorg> e.g. node-csv-spectrum
<LocutusOfBorg> but with 165 new node modules in debian new queue, finding them is difficult
<LocutusOfBorg> (I saw people asking on #debian-ftp to process some of them for the same reason, so I hope things will move forward)
<LocutusOfBorg> "please review node-date-time and node-babel-plugin-buble (dependency of rollup which was accepted recently but uninstallable now)"
<tsimonq2> Oh boy :)
 * tsimonq2 wants to just sync nodejs already so my name isn't on it :P
-queuebot:#ubuntu-release- New: accepted node-d3-collection [amd64] (bionic-proposed) [1.0.4-2]
<slangasek> fyi if node-d3-timer builds successfully on retry, that just means node has flaky handling of clocks, pay it no mind
<slangasek> and node-d3-format fails to upload because there's a d3-format source package with an epoch that fights it for the binary; somebody could look to see what is meant to be happening with those in Debian
-queuebot:#ubuntu-release- New binary: node-d3-timer [amd64] (bionic-proposed/universe) [1.0.7-3] (no packageset)
<slangasek> ^^ there. node doesn't know how clocks work. enjoy.
-queuebot:#ubuntu-release- New: accepted node-d3-timer [amd64] (bionic-proposed) [1.0.7-3]
-queuebot:#ubuntu-release- New binary: sdformat [s390x] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
<slangasek> http://autopkgtest.ubuntu.com/packages/n/node-glob-base/bionic/amd64 - oh, so with the new version of node-is-glob, the node-glob-base regression test which checks for "isGlob" has just changed from false to true; I'm sure that's not serious
<nacc> lol
-queuebot:#ubuntu-release- New: accepted sdformat [s390x] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New binary: sdformat [i386] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: sdformat [amd64] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted sdformat [amd64] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted sdformat [i386] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New binary: sdformat [armhf] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted sdformat [armhf] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New binary: sdformat [arm64] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.30]
<tsimonq2> New Plasma coming in
-queuebot:#ubuntu-release- New binary: sdformat [ppc64el] (bionic-proposed/universe) [6.0.0+dfsg-3] (no packageset)
 * acheronuk hides
<tsimonq2> I've volunteered to look after it while acheronuk sleeps, fwiw
<acheronuk> it's a bugfix release, so should hopefully not be much hassle
<tsimonq2> Right
<tsimonq2> But, y'know, autopkgtests ;)
<acheronuk> shhhhhhhhhh
<tsimonq2> :D
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.31.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.30~14.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.30+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.31.1~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.31.1+17.10]
#ubuntu-release 2018-02-21
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.23 => 1:16.04.24] (core)
-queuebot:#ubuntu-release- New binary: node-d3-force [amd64] (bionic-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-scale [amd64] (bionic-proposed/universe) [1.0.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-brush [amd64] (bionic-proposed/universe) [1.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-zoom [amd64] (bionic-proposed/universe) [1.6.0-2] (no packageset)
<tsimonq2> slangasek: If you're around, it would be good to get bug 1750318 processed
<ubot5> bug 1750318 in node-tilelive-vector (Ubuntu) "RM: broken and poorly maintained" [High,New] https://launchpad.net/bugs/1750318
<tsimonq2> slangasek: That reminded me to file bug 1750716 about indi-sbig as well ;)
<ubot5> bug 1750716 in indi-sbig (Ubuntu) "RM: obsolete and Ubuntu-only" [High,New] https://launchpad.net/bugs/1750716
-queuebot:#ubuntu-release- New: accepted node-d3-brush [amd64] (bionic-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- New: accepted node-d3-scale [amd64] (bionic-proposed) [1.0.6-3]
-queuebot:#ubuntu-release- New: accepted sdformat [arm64] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted node-d3-force [amd64] (bionic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted sdformat [ppc64el] (bionic-proposed) [6.0.0+dfsg-3]
-queuebot:#ubuntu-release- New: accepted node-d3-zoom [amd64] (bionic-proposed) [1.6.0-2]
<tjaalton> maybe I should upload a client-only freeipa until server actually works again..
<slangasek> tsimonq2: node-mapnik sorted; now maybe you want to figure out node-grunt-contrib-concat, which has actual non-trivial revdeps :)
<tsimonq2> slangasek: Is that an RM candidate as well or does it just need sorting in general? :)
<slangasek> I think it's going to need actual sorting rather than removal
<tsimonq2> Sure; it's approaching 1 AM and I have to be up for 6 so I need to sleep but I'll sort it within the next day ;)
<tsimonq2> Jeez, dbus-cpp has *super* racy tests :/
-queuebot:#ubuntu-release- New binary: gazebo [ppc64el] (bionic-proposed/universe) [9.0.0+dfsg5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gazebo [i386] (bionic-proposed/universe) [9.0.0+dfsg5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gazebo [amd64] (bionic-proposed/universe) [9.0.0+dfsg5-2] (no packageset)
<tjaalton> cyphermox: hi, updated libglvnd MIR, should be good now. tests will arrive with a later upload soon
-queuebot:#ubuntu-release- Unapproved: net-snmp (xenial-proposed/main) [5.7.3+dfsg-1ubuntu4 => 5.7.3+dfsg-1ubuntu4.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gazebo [armhf] (bionic-proposed/universe) [9.0.0+dfsg5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.8 => 2.10.95-0ubuntu2.9] (core)
-queuebot:#ubuntu-release- New binary: gazebo [arm64] (bionic-proposed/universe) [9.0.0+dfsg5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.21 => 20101020ubuntu451.22] (core)
-queuebot:#ubuntu-release- New source: node-mapnik (bionic-proposed/primary) [3.6.2+dfsg-3.1~build1]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.22]
<xnox> apw, it looks like linux/4.15.0-10.11 "regressed" on s390x w.r.t. autopkgtests; could you please badtest linux/4.15.0-10.11 on s390x as well? it is already ignored on other arches
<apw> xnox, am i sure i want to ignore those tests on any architecture ?
<apw> not that we track regressions for linux packages anyhow, so i am not sure how that is affecting anything either way
<xnox> apw, s390x used to pass, because it used to run in a lxc container. At the moment linux/4.15.0 is amd64,i386,ppc64el ignored failures; with arm64 as always failed; armhf pass; s390x regression
<xnox> apw, it is affecting migration of packages. For example openssl1.0 is blocked from migrating due to linux/s390x "regression"
<apw> as i say though we don't keep history for linux packages, as an exception, so how is it counting a regression
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openssl1.0
<xnox> it somehow passed....?
<xnox> from http://autopkgtest.ubuntu.com/packages/l/linux/bionic/s390x it was passing in december
<apw> how is it debian never needed a way to suppress old tests like this ...
<apw> xnox, right pass or not i didn't think we considered history of linux, oh well, most only be when the primary is linux
<apw> what a mess
<apw> if we are not going to fix britney to have a switch for this, we need to just remove all these old results
<apw> they are just a damn pain in the butt
<xnox> slangasek, i'm questioning the usefulness of the open-iscsi test. as it does not test any of the triggered-by packages in the mix at all, it seems, and simply retests the downloaded maas/cloud image instead
<apw> xnox, anyhow, done
<xnox> apw, thanks.
<xnox> slangasek, it feels like the boot test should move to the cloud test framework / image build validation.
-queuebot:#ubuntu-release- New binary: ganeti [amd64] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [i386] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
<LocutusOfBorg> please accept node-mapnik, I fixed it in Debian too, this will make node-tilelive-mapnik  node-tilelive-bridge node-tilelive-vector  migrate
-queuebot:#ubuntu-release- New binary: ganeti [s390x] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [ppc64el] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [arm64] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (trusty-proposed) [2:9.4.0-1280544-5ubuntu6.4]
<tsimonq2> slangasek: LocutusOfBorg fixed up node-mapnik ^^^^o
-queuebot:#ubuntu-release- New binary: ganeti [armhf] (bionic-proposed/universe) [2.16.0~rc2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (xenial-proposed) [5.7.3+dfsg-1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (xenial-proposed) [2.10.95-0ubuntu2.9]
-queuebot:#ubuntu-release- New binary: webkit2gtk [s390x] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: webkit2gtk [ppc64el] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: webkit2gtk [amd64] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
<slangasek> LocutusOfBorg: why do you do fake syncs?  the real sync would've been auto-accepted by now
-queuebot:#ubuntu-release- New binary: webkit2gtk [i386] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libgcrypt20 (xenial-proposed/main) [1.6.5-2ubuntu0.3 => 1.6.5-2ubuntu0.4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected libgcrypt20 [source] (xenial-proposed) [1.6.5-2ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.1 => 229-4ubuntu21.2] (core)
-queuebot:#ubuntu-release- New: rejected node-mapnik [source] (bionic-proposed) [3.6.2+dfsg-3.1~build1]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [source] (bionic-proposed) [1]
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (bionic-proposed/universe) [1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: hw-detect (xenial-proposed/main) [1.117ubuntu2.2 => 1.117ubuntu2.3] (core)
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [amd64] (bionic-proposed) [1]
<tsimonq2> xnox: I think I talked to you at one point about a switch too Calamares for Lubuntu Next. Is  there anything I should keep in miind before sswapping the packkages out later?k
<tsimonq2> (excus.te
<tsimonq2> (excuse my typos, I'm on mobile)
<xnox> tsimonq2, that's not me to discuss with =/ i'm not release team, i'm not cdimage team, i'm not TB, etc...
<xnox> tsimonq2, try slangasek Laney infinity => people like that.
<tsimonq2> OK
<tsimonq2> Thanks
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.4 => 1.34.0-0ubuntu8.5] (no packageset)
-queuebot:#ubuntu-release- New binary: webkit2gtk [armhf] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libgcrypt20 [source] (xenial-proposed) [1.6.5-2ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (xenial-proposed) [1.34.0-0ubuntu8.5]
-queuebot:#ubuntu-release- New binary: webkit2gtk [arm64] (bionic-proposed/main) [2.19.91-1ubuntu1] (desktop-core, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [s390x] (bionic-proposed/none) [1.1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-showmax-go-fqdn [amd64] (bionic-proposed/none) [0.0~git20160909.2501cdd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [s390x] (bionic-proposed/none) [0.17.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [i386] (bionic-proposed/none) [1.1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mapnik [s390x] (bionic-proposed/none) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: privacybadger [amd64] (bionic-proposed/none) [2018.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [amd64] (bionic-proposed/none) [0.17.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [amd64] (bionic-proposed/none) [1.1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mapnik [i386] (bionic-proposed/none) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mapnik [amd64] (bionic-proposed/none) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [arm64] (bionic-proposed/none) [0.17.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [armhf] (bionic-proposed/none) [1.1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [arm64] (bionic-proposed/none) [1.1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mapnik [arm64] (bionic-proposed/none) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mapnik [armhf] (bionic-proposed/none) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [s390x] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (xenial-proposed) [1.117ubuntu2.3]
-queuebot:#ubuntu-release- New binary: wxpython4.0 [amd64] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [i386] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [armhf] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
<LocutusOfBorg> slangasek, the package got removed from bionic, isn't autosync not working for that?
-queuebot:#ubuntu-release- New binary: wxpython4.0 [arm64] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
<LocutusOfBorg> (btw I still don't get how somebody removed it without removing the runtime reverse-deps)
<LocutusOfBorg> node-tilelive-vector, node-tilelive-bridge and node-tilelive-mapnik
<tsimonq2> LocutusOfBorg: Demoted, not RMed
<slangasek> LocutusOfBorg: node-tilelive-* do not require source changes to become installable again; so removing, rather than demoting, means they wouldn't come back again without another unrelated sourceful upload in Debian
<slangasek> therefore I default to demoting of dependent packages
<slangasek> LocutusOfBorg: and no, autosync is now enabled by default for new packages also
<slangasek> lp:~vorlon/ubuntu-archive-tools/sync-removals-by-default
<slangasek> LocutusOfBorg: sorry, I should say, for removed+new packages
-queuebot:#ubuntu-release- New binary: node-mapnik [ppc64el] (bionic-proposed/universe) [3.6.2+dfsg-5] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [ppc64el] (bionic-proposed/universe) [0.17.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.35 => 2.39.2] (no packageset)
-queuebot:#ubuntu-release- New binary: xserver-xorg-video-ast [ppc64el] (bionic-proposed/universe) [1.1.5-1.1] (no packageset)
<LocutusOfBorg>  slangasek this is awesome! I wasn't aware of this great feature thanks!
<LocutusOfBorg> now node-mapnik is ready to go :) built on all archs
-queuebot:#ubuntu-release- Unapproved: libservicelog (xenial-proposed/universe) [1.1.16-0ubuntu1 => 1.1.16-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: wxpython4.0 [ppc64el] (bionic-proposed/universe) [4.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [ppc64el] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [ppc64el] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted node-mapnik [amd64] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted node-mapnik [armhf] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted node-mapnik [ppc64el] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted privacybadger [amd64] (bionic-proposed) [2018.2.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [arm64] (bionic-proposed) [0.17.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [amd64] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [armhf] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [s390x] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [arm64] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted node-mapnik [arm64] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted node-mapnik [s390x] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted ruby-prof [ppc64el] (bionic-proposed) [0.17.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [i386] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [armhf] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted node-mapnik [i386] (bionic-proposed) [3.6.2+dfsg-5]
-queuebot:#ubuntu-release- New: accepted wxpython4.0 [arm64] (bionic-proposed) [4.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [amd64] (bionic-proposed) [0.17.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [amd64] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted ganeti [amd64] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted ganeti [armhf] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted ganeti [ppc64el] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted gazebo [amd64] (bionic-proposed) [9.0.0+dfsg5-2]
-queuebot:#ubuntu-release- New: accepted gazebo [armhf] (bionic-proposed) [9.0.0+dfsg5-2]
-queuebot:#ubuntu-release- New: accepted gazebo [ppc64el] (bionic-proposed) [9.0.0+dfsg5-2]
-queuebot:#ubuntu-release- New: accepted ruby-prof [s390x] (bionic-proposed) [0.17.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [s390x] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted ganeti [arm64] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted ganeti [s390x] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted gazebo [i386] (bionic-proposed) [9.0.0+dfsg5-2]
-queuebot:#ubuntu-release- New: accepted xserver-xorg-video-ast [i386] (bionic-proposed) [1.1.5-1.1]
-queuebot:#ubuntu-release- New: accepted ganeti [i386] (bionic-proposed) [2.16.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-showmax-go-fqdn [amd64] (bionic-proposed) [0.0~git20160909.2501cdd-1]
-queuebot:#ubuntu-release- New: accepted gazebo [arm64] (bionic-proposed) [9.0.0+dfsg5-2]
<sergiusens> can someone please accept snapcraft 2.39.2 into xenial-proposed?
<sergiusens> slangasek: has there been any progress on the DNS timeouts issue on armhf for autopkgtests?
<slangasek> sergiusens: no
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.5-0ubuntu1 => 8.0.5.10-0ubuntu1] (no packageset)
<slangasek> sergiusens: I am certainly willing to ignore snapcraft test failures on armhf while this is ongoing
-queuebot:#ubuntu-release- Unapproved: compiz (xenial-proposed/main) [1:0.9.12.3+16.04.20171116-0ubuntu1 => 1:0.9.12.3+16.04.20180221-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity (xenial-proposed/main) [7.4.5+16.04.20171201.3 => 7.4.5+16.04.20180221-0ubuntu1] (ubuntu-desktop) (sync)
#ubuntu-release 2018-02-22
<tjaalton> bah, I need nss-pem in order to fix freeipa server setup..
<mwhudson> anyone here who can promote golang-1.10 and golang-1.10-race-detector-runtime to main?
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.22 => 1:2.5+dfsg-5ubuntu10.23] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.5 => 9.4ubuntu4.6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.6]
<apw> mwhudson, can you point me at the mir for that, there presumably is a general one for golangs
<mwhudson> apw: sil2100 did it, but thanks :)
<tjaalton> cpaelzer: hi, is nss maintained on a git branch?
<tjaalton> cpaelzer: I need to add the files for nss-pem or freeipa server won't work..
<cpaelzer> hi tjaalton
<cpaelzer> yes I have found an upstream git
<cpaelzer> just a sec
<cpaelzer> https://github.com/nss-dev/nss.git
<cpaelzer> tjaalton: it is the mirror of the actual mercurial repo
<cpaelzer> linked from the top of the GH page
<cpaelzer> if you are fine with mercurial https://hg.mozilla.org/projects/nss
<cpaelzer> tjaalton: ^^
<tjaalton> cpaelzer: I meant for ubuntu
<tjaalton> there are tons of branches on usd-import-team repo
<tjaalton> but anyway, maybe I'll just propose a change
-queuebot:#ubuntu-release- New binary: alttab [ppc64el] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [ppc64el] (bionic-proposed/none) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alttab [s390x] (bionic-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [s390x] (bionic-proposed/none) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [i386] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
<cpaelzer> cpaelzer: there is a branche for each release/pocket combo
<cpaelzer> you likely want to MP and base off from ubuntu/bionic-devel
-queuebot:#ubuntu-release- New binary: alttab [amd64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [amd64] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alttab [i386] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
<sergiusens> slangasek: thanks for the heads up on that
<sergiusens> sil2100: hey, mind looking at snapcraft-2.39.2 and getting it accepted into xenial-proposed ?
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [i386] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
<acheronuk_> adding ppas to local autopkgtest lxd containers now seems broken in bionic
<acheronuk_> add-apt-repository fails with:
<acheronuk_> [Errno 2] No such file or directory: 'S.gpg-agent.ssh'
-queuebot:#ubuntu-release- New binary: alttab [arm64] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: alttab [armhf] (bionic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [arm64] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libusbauth-configparser [armhf] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: remmina [ppc64el] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [s390x] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [amd64] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
<acheronuk_> xnox: this breaks add-apt-repository in a container? https://launchpad.net/ubuntu/+source/gnupg2/2.2.4-1ubuntu1
-queuebot:#ubuntu-release- New binary: remmina [i386] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [arm64] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
<xnox> acheronuk_, cute, do you have a bug report?
<xnox> acheronuk_, and S.gpg-agent.ssh should only be created for those that do use ssh agent.... do you?
-queuebot:#ubuntu-release- New binary: dolfin [armhf] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
<acheronuk_> xnox: that is in a autopkgtest lxd container, so don't know on that
<acheronuk_> same error in Kubuntu CI docker containers
<xnox> acheronuk_, can you give me url to the failure you are seeing?
<acheronuk_> xnox: it's a local container made with 'autopkgtest-build-lxd images:ubuntu/bionic/amd64'
-queuebot:#ubuntu-release- New binary: remmina [armhf] (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-3ubuntu1] (ubuntu-desktop)
<xnox> acheronuk_, this is not enough details at all. please open a bug report, with steps to reproduce and logs.
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (bionic-proposed/universe) [2017.2.0.post0-2] (no packageset)
<acheronuk_> xnox: ok
<acheronuk_> xnox: https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1751053
<ubot5> Ubuntu bug 1751053 in gnupg2 (Ubuntu) "2.2.4-1ubuntu1 breaks adding ppa with add-apt-repository in a autopkgtest/docker container" [Undecided,New]
<acheronuk_> anything else needed for that, please shout
<sil2100> sergiusens: hey! I'll try taking a look at it :)
<sil2100> (in between point-releasey stuff)
<xnox> apw, could please re-promote cloud-initramfs-dyn-netconf back into main?
<xnox> apw, it was a mistake to drop it, which we are reverting back in now (smoser & I)
<xnox> https://people.canonical.com/~ubuntu-archive/component-mismatches.txt -> see binary only movements to main
<xnox> or maybe sil2100 can do that too?
<xnox> or rbasak ?
<apw> xnox, will do
<apw> it is dangerous to get more than one person looking at it with the LP bug
<xnox> apw, i was hoping for a double-override, to delay the whole thing to annoy smoser for a couple of days longer, but alas =)
<apw> xnox, i guess i can just run !! for you
<xnox> whoop whoop \o/
<xnox> but on the serious note, please don't =)
<xnox> as i do kind of want to fix open-iscsi tests, to unblock cryptsetup transition of doom.
-queuebot:#ubuntu-release- New source: percona-xtradb-cluster-5.7 (bionic-proposed/primary) [5.7.20-29.24-0ubuntu1]
<jamespage> xnox: finally ready ^^
<jamespage> ;)
<xnox> jamespage, whoop whoop
<LocutusOfBorg> jbicha, <k0m_> se sei novello o meno
<LocutusOfBorg> sorry jbicha https://bugzilla.gnome.org/show_bug.cgi?id=793724
<ubot5> Gnome bug 793724 in Tests "testsuite broken in 2.0.3 with new libunistring 0.9.8" [Normal,New]
<LocutusOfBorg> I opened a bug report, if you want to add some info, feel free!
<LocutusOfBorg> I also opened a bug report about the new asserts in 2.0.3 that fails
<LocutusOfBorg> https://bugzilla.gnome.org/show_bug.cgi?id=793723
<ubot5> Gnome bug 793723 in Tests "testsuite broken in 2.0.3 (regression since 2.0.1)" [Normal,New]
<LocutusOfBorg> please enlight me, this is the first time I open a bug report for gnome tools (or it has been too much time that I forgot the guidelines)
<LocutusOfBorg> also, FYI https://bugzilla.gnome.org/show_bug.cgi?id=793599
<ubot5> Gnome bug 793599 in general "Please run testsuite with V=0" [Normal,New]
<ginggs> would someone please remove gazebo's binaries on s390x from bionic? ignition-common does not build on big-endian
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.24]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.39.2]
-queuebot:#ubuntu-release- New binary: liblouisutdml [ppc64el] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouisutdml [s390x] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouisutdml [amd64] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouisutdml [arm64] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouisutdml [i386] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouisutdml [armhf] (bionic-proposed/main) [2.7.0-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ctdopts [amd64] (bionic-proposed/none) [1.2-1] (no packageset)
<infinity> ginggs: Doing.
-queuebot:#ubuntu-release- New binary: clojure1.8 [amd64] (bionic-proposed/none) [1.8.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-rollup-plugin-node-resolve [amd64] (bionic-proposed/none) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-node-localstorage [amd64] (bionic-proposed/none) [1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gegl [s390x] (bionic-proposed/universe) [0.3.28-2] (edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: inetsim [amd64] (bionic-proposed/none) [1.2.7+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [i386] (bionic-proposed/none) [3.0-1] (no packageset)
<infinity> ginggs: And done.
-queuebot:#ubuntu-release- New binary: node-coa [amd64] (bionic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-flashclust [s390x] (bionic-proposed/none) [1.01-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-sidekiq-limit-fetch [amd64] (bionic-proposed/none) [3.4.0-2] (no packageset)
<ginggs> infinity: ta!
-queuebot:#ubuntu-release- New binary: node-postcss-load-config [amd64] (bionic-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [s390x] (bionic-proposed/none) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-uniq [amd64] (bionic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-flashclust [i386] (bionic-proposed/none) [1.01-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-flashclust [amd64] (bionic-proposed/none) [1.01-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [amd64] (bionic-proposed/none) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spec-alpha-clojure [amd64] (bionic-proposed/none) [0.1.143-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gegl [ppc64el] (bionic-proposed/universe) [0.3.28-2] (edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New binary: gegl [amd64] (bionic-proposed/universe) [0.3.28-2] (edubuntu, ubuntugnome)
<ginggs> infinity: so when will i be able to do stuff like that? :)
<infinity> ginggs: When I no longer feel the need to double-check all your requests (and probably some time after you stop asking).
-queuebot:#ubuntu-release- New binary: r-cran-flashclust [ppc64el] (bionic-proposed/universe) [1.01-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [ppc64el] (bionic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gegl [i386] (bionic-proposed/universe) [0.3.28-2] (edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-390 (bionic-proposed/primary) [390.25-0ubuntu1]
<tsimonq2> Oh yay. Lubuntu's ISOs FTBFS on an uninstallable kernel.
<wxl> only lubuntu?
<bdmurray> xnox: Can you add a test case or something to bug 1618188?
<ubot5> bug 1618188 in systemd (Ubuntu Artful) "systemd journal should be persistent by default: /var/log/journal should be created" [Undecided,In progress] https://launchpad.net/bugs/1618188
<xnox> bdmurray, doing
<acheronuk_> tsimonq2: gulp
<tsimonq2> wxl: Not sure.
 * tsimonq2 is ofc on mobile
<wxl> can you send a link to the logs, @tseliot ?
<wxl> ugh
<wxl> sorry
<wxl> tsimonq2:
<tsimonq2> wxl: You should have gotten the email ;)
<acheronuk_> tsimonq2: 5.15 migrating and just bad timing?
 * wxl sighs
<acheronuk_> *4.15
<wxl> nope
<xnox> bdmurray, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 updated. hope i didn't miss more.
<ubot5> Ubuntu bug 1618188 in systemd (Ubuntu Artful) "systemd journal should be persistent by default: /var/log/journal should be created" [Undecided,In progress]
<acheronuk_> i.e. that weird limbo between -proposed and -release when things don't install?
<acheronuk_> tsimonq2: ^
<tsimonq2> Maybe
<tsimonq2> Dunno
<acheronuk_> who can poke a rebuild?
<tsimonq2> I can, and J w,
<tsimonq2> *I will right now :)
<bdmurray> xnox: I'll let you know - like bug 1734167
<ubot5> bug 1734167 in systemd (Ubuntu Artful) "DNS doesn't work in no-cloud as launched by ubuntu" [High,In progress] https://launchpad.net/bugs/1734167
<acheronuk_> fingers crossed, it sorts itself....
<xnox> bdmurray,  bah
-queuebot:#ubuntu-release- New: accepted alttab [amd64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted alttab [armhf] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted alttab [ppc64el] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted clojure1.8 [amd64] (bionic-proposed) [1.8.0-4]
-queuebot:#ubuntu-release- New: accepted alttab [arm64] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted alttab [s390x] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted alttab [i386] (bionic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ctdopts [amd64] (bionic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted dolfin [armhf] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted inetsim [amd64] (bionic-proposed) [1.2.7+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [arm64] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [i386] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [s390x] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [armhf] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted dolfin [i386] (bionic-proposed) [2017.2.0.post0-2]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [ppc64el] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [amd64] (bionic-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [amd64] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [armhf] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [ppc64el] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted node-coa [amd64] (bionic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-load-config [amd64] (bionic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted node-uniq [amd64] (bionic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-flashclust [i386] (bionic-proposed) [1.01-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-flashclust [s390x] (bionic-proposed) [1.01-2-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [arm64] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [s390x] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-node-resolve [amd64] (bionic-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-flashclust [ppc64el] (bionic-proposed) [1.01-2-1]
-queuebot:#ubuntu-release- New: accepted libusbauth-configparser [i386] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted r-cran-flashclust [amd64] (bionic-proposed) [1.01-2-1]
-queuebot:#ubuntu-release- New: accepted node-node-localstorage [amd64] (bionic-proposed) [1.3.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-sidekiq-limit-fetch [amd64] (bionic-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted spec-alpha-clojure [amd64] (bionic-proposed) [0.1.143-1]
<wxl> first error i see in alternate is bzr: ERROR: Not a branch: "https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/platform.bionic/".
<bdmurray> xnox: and bug 1737570
<ubot5> bug 1737570 in systemd (Ubuntu Artful) "Add support for RequiredForOnline in networkd" [Undecided,In progress] https://launchpad.net/bugs/1737570
<xnox> bdmurray, clearly i have missed a bunch of them, despite doing it for many of them.
 * xnox is a failure
<wxl> live dies immediately
<bdmurray> xnox: just fix less bugs!
<acheronuk_> wxl: The following packages have unmet dependencies:
<acheronuk_>  linux-generic : Depends: linux-image-generic (= 4.15.0.10.11) but it is not going to be installed
<acheronuk_>                  Depends: linux-headers-generic (= 4.15.0.10.11) but it is not going to be installed
<acheronuk_> was what I saw
<xnox> bdmurray, https://bugs.launchpad.net/cloud-init/+bug/1734167 updated
<ubot5> Ubuntu bug 1734167 in systemd (Ubuntu Artful) "DNS doesn't work in no-cloud as launched by ubuntu" [High,In progress]
<wxl> there's also a bunch of unknown packages
<xnox> slangasek, cyphermox - i believe nplan source package should be renamed to netplan.io
<infinity> acheronuk_: That's resolve now, I think.  meta got published before linux. :/
<xnox> slangasek, cyphermox that way it is not confusing, and non-conflicting with netplan package
<wxl> looks like linux-base there is 4.5ubuntu1
<acheronuk_> infinity: yeah. that is what it seemed
<infinity> wxl: linux-base doesn't relate to any of that.
<acheronuk_> thanks
<acheronuk_> just bad timing on that iso build!
<tjaalton> my xorg-server upload to bionic is getting rejected, and I don't understand why
<tjaalton> dpkg-source failed for xorg-server_1.19.6-1ubuntu2.dsc [return: 2]
<infinity> Badness with britney promotions racing the publisher, actually, but sure, we'll blame the build timing.
<infinity> tjaalton: There's no more than that line
<infinity> tjaalton: ?
<tjaalton> [dpkg-source output:   dpkg-source: info: extracting xorg-server in xorg-server-1.19.6]
<tjaalton> etc
<infinity> etc isn't the most helpful line. ;)
<tjaalton> etc being the changelog
<tjaalton> https://pastebin.com/TUuj3103
<infinity> tjaalton: I mean... Try it locally?  dpkg-source -x foo.dsc ; echo $?
<tjaalton> works fine
<xnox> bdmurray, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1737570 updated
<ubot5> Ubuntu bug 1737570 in systemd (Ubuntu Artful) "Add support for RequiredForOnline in networkd" [Undecided,In progress]
<infinity> tjaalton: Toss the source package somewhere?
<xnox> bdmurray, i'm off to volleyball, if there is more to fix, it will have to wait til later
<tjaalton> ok..
<tjaalton> infinity: http://aaltoset.kapsi.fi/xserver/
<tjaalton> first rejection was due to .source_changes missing the .asc
<infinity> dpkg-source: error: unrecognized file for a v1.0 source package: xorg-server_1.19.6.orig.tar.gz.asc
<tjaalton> uh
<tjaalton> ok
<tjaalton> stupid uscan
<xnox> infinity, tjaalton - yeah i hate that, i constantly have to rm *.asc
<tjaalton> actually
<tjaalton> I'm pretty sure debian accepts these
<xnox> infinity, tjaalton - then build source package, then sign, then upload
-queuebot:#ubuntu-release- New binary: gegl [arm64] (bionic-proposed/universe) [0.3.28-2] (edubuntu, ubuntugnome)
<xnox> tjaalton, oh, we are meant to upload these?
<tjaalton> xnox: well, it shouldn't be a reason to reject
<cjwatson> was that a rejection from LP?  maybe just an old dpkg-dev
<xnox> tjaalton, i don't know about you, i'm failing to build _source.changes when i have a left over .asc =/
<cjwatson> we rely on the dpkg-source on our systems being able to unpack stuff
<infinity> That's xenial's dpkg-source, yes.
<xnox> maybe i have something weird locally.
<cjwatson> right, but does newer dpkg-source accept it?
<infinity> Optionally  the
<infinity>        original  tarball  might be accompanied by a detached upstream signature .orig.tar.gz.asc,
<infinity>        extraction supported since dpkg 1.18.5.
<infinity> And xenial is 1.18.4 :P
<cjwatson> if so, a bug explaining the situation and asking us for a backport would be good.
<infinity> So yes, probably a trivial backport.
<tjaalton> i'm on bionic..
<infinity> tjaalton: Yes, but ftpmaster isn't.
<tjaalton> ah :)
<cjwatson> ftpmaster is xenial plus https://launchpad.net/~canonical-is-sa/+archive/ubuntu/launchpad/+packages
<infinity> cjwatson: I'll SRU for that, it seems like one I'd rather not trip over.
<cjwatson> that works too
<infinity> tjaalton: Want to file a bug for me?
<tjaalton> i can yes
<infinity> tjaalton: Something along the lines of "xenial dpkg-source hates my packages built on bionic, and my freedom".
<infinity> tjaalton: Ta.
<infinity> tjaalton: But for now, yes, the easy answer is "sed -i -e '/\.asc/d' ../*dsc && dpkg-genchanges -S > ../*changes && debsign ../*changes"
<infinity> Or delete the .asc before building the package.
<infinity> Which is likely easier.
<slangasek> xnox: oh, interesting suggestion
<tjaalton> yeah, i hit this on debian not too long ago, and it got fixed there once jcristau complained :)
<slangasek> cyphermox: ^^ I'm on board with that package name change
<tjaalton> just forgot about it already
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (artful-proposed) [234-2ubuntu12.3]
<tjaalton> hmm or was it that long ago.. could be
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1751114
<ubot5> Ubuntu bug 1751114 in dpkg (Ubuntu Xenial) "dpkg-source on xenial doesn't support .asc file in .dsc for v1.0 source format" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted compiz [sync] (xenial-proposed) [1:0.9.12.3+16.04.20180221-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (xenial-proposed) [7.4.5+16.04.20180221-0ubuntu1]
<slangasek> tsimonq2: was it you asking about unistring before?
<slangasek> ah no, it was LocutusOfBorg
<slangasek> LocutusOfBorg: I'm looping back around to this because curl is going to entangle it via kamailio
<slangasek> do we still need eyeballs on https://launchpadlibrarian.net/357395526/tracker_2.0.3-1ubuntu4_2.0.3-1ubuntu5.diff.gz ?
<cyphermox> slangasek: ok, will look into it for the next upload
<tseliot> slangasek: nvidia-graphics-drivers-390 is in bionic NEW, just FYI ;)
<slangasek> tseliot: \o/
<tseliot> :)
-queuebot:#ubuntu-release- New binary: usbauth [i386] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth [amd64] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth [ppc64el] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [arm64] (bionic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth [arm64] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-leaps [armhf] (bionic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth [armhf] (bionic-proposed/universe) [1.0~git20180119-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gegl [amd64] (bionic-proposed) [0.3.28-2]
-queuebot:#ubuntu-release- New: accepted gegl [i386] (bionic-proposed) [0.3.28-2]
-queuebot:#ubuntu-release- New: accepted gegl [s390x] (bionic-proposed) [0.3.28-2]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [arm64] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [i386] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [s390x] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted usbauth [arm64] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted usbauth [i386] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted gegl [arm64] (bionic-proposed) [0.3.28-2]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [amd64] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [ppc64el] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted usbauth [armhf] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted gegl [ppc64el] (bionic-proposed) [0.3.28-2]
-queuebot:#ubuntu-release- New: accepted usbauth [amd64] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New: accepted r-cran-leaps [armhf] (bionic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted usbauth [ppc64el] (bionic-proposed) [1.0~git20180119-1]
-queuebot:#ubuntu-release- New binary: okular [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<tjaalton> I guess someone who cares about NSS should review https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1751140
<ubot5> Ubuntu bug 1751140 in nss (Ubuntu) "nss-pem needs additional headers, static libs to build" [Undecided,Triaged]
-queuebot:#ubuntu-release- New binary: okular [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<slangasek> tjaalton: oh, this is the other NSS than the one I care about ;)
-queuebot:#ubuntu-release- New binary: okular [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu1] (kubuntu)
<slangasek> LocutusOfBorg: ok, have looked at your delta; very interesting, and I think that's clearly a regression in libunistring which should not be worked around in tracker, as 'ORDER BY ?description' should definitely not have changed to yield different output (in particular, causing all strings with non-ascii characters anywhere in them to be sorted last)
<jbicha> slangasek: could you remove tilix/ppc64el and onedrive/ppc64el? ldc upstream doesn't support that architecture
<jbicha> that should allow the ldc transition to complete
<slangasek> jbicha: why is tilix not dep-wait on ppc64el like it is on the other archs?  should those gtk-d/ppc64el binaries also be removed?
<xnox> slangasek, cyphermox - s/nplan/netplan.io/
<slangasek> (since gtk-d also build-depends on ldc, and has built there)
<xnox> slangasek, if cyphermox missed the suggestion
<slangasek> xnox: got it, yes :)
<jbicha> uh, I wish ximion was here to help answer these ldc questionsâ¦
<tjaalton> slangasek: nintendo super system? :)
<slangasek> tjaalton: name switch service
<jbicha> tilix um wants to build with ldc, but ximion has it set up so that ldc isn't offered as a Build-Depends for tilix with https://anonscm.debian.org/cgit/pkg-d/dh-dlang.git/tree/debian/control
<tjaalton> slangasek: of course..
<jbicha> when I asked ximion earlier, he pointed to https://github.com/ldc-developers/ldc/issues/2356 as justification
<jbicha> I guess it's a tilix bug for not allowing to build with gdc instead
<slangasek> jbicha: or arguably a bug in dh-dlang on Ubuntu, if we have an ldc here that works? (unproven)
<slangasek> jbicha: anyway, I'm happy to remove the binaries, just noticed the inconsistency and wondered if there were more things that ought to be removed
<jbicha> oh you can remove gtk-d/ppc64el too, ximion just pushed an update to unstable that switched its Build-Depends from ldc to dh-dlang
-queuebot:#ubuntu-release- New binary: ctdconverter [amd64] (bionic-proposed/universe) [2.0-3] (no packageset)
<slangasek> jbicha: but gtk-d has an Ubuntu delta; I'll wait for removals until I see this change in -proposed
<jbicha> ok
-queuebot:#ubuntu-release- New: accepted ctdconverter [amd64] (bionic-proposed) [2.0-3]
<tsimonq2> slangasek: indi-sbig> I thought we already discussed that these are leaf modules that are out-of-date and shouldn't be separate source packages anyways? I just triggered a no-change rebuild, sure, but it should be RMed anyways...
<tsimonq2> slangasek: Although a stronger justification can be made now that indi-sbig is FTBFS :P
#ubuntu-release 2018-02-23
<slangasek> tsimonq2: due diligence; I don't want to be in the middle of an argument with someone else saying "you could've just rebuilt it"
<tsimonq2> slangasek: Fair then. Thanks.
 * tsimonq2 hopes that libindi will now migrate on next run
<tsimonq2> slangasek: node-grunt-contrib-concat> Is that still something that needs sorting
<tsimonq2> ?
<slangasek> tsimonq2: it is
<tsimonq2> OK, on it.
 * tsimonq2 plays with migration-assistant.py to see if it can save some time for me here
<tsimonq2> ;)
<tsimonq2> slangasek: node-grunt-contrib-concat> Are we talking about in the context of node-source-map? There's nothing in -proposed and it isn't blocking nodejs...
<slangasek> tsimonq2: yes, it's wrt node-source-map
<tsimonq2> slangasek: OK
-queuebot:#ubuntu-release- New binary: r-cran-factominer [amd64] (bionic-proposed/universe) [1.39-1] (no packageset)
<tsimonq2> slangasek: I'll try to keep digging, but the test fails because of this error recently added: https://github.com/mozilla/source-map/compare/0.5.7...0.6.1#diff-2368fdc0767745eceb91f57c68952728R341 -- I'm not sure why the heck these values are empty in the tests...
<tsimonq2> (To be fair, the codebase hasn't been touched since 2016...)
<tsimonq2> slangasek: Either way, from what I can tell, this is the tests, not the codebase itself bitrotting, but I'd like an ACK from you before disabling these
<tsimonq2> (to be safe)
<slangasek> tsimonq2: if I knew anything about this code, I probably wouldn't have tried to pawn it off ;)
<slangasek> I can't tell from that link what 'error' you're referring to
<tsimonq2> Click on the diff tab
<tsimonq2> GitHub is stupid :P
<tsimonq2> slangasek: hah :P
<slangasek> it's a large diff
<tsimonq2> bahh, let me just pastebinit...
<tsimonq2> https://paste.ubuntu.com/p/75b6kZFmsQ/
<slangasek> ok
<tsimonq2> libindi migrated \o/
<slangasek> so, the setting of 'line' and 'column' is being done by the test suite, not the code?
<tsimonq2> The tested files come from the tests dir
<tsimonq2> I guess from my (somewhat bad, to be fair) understanding of this, yeah
<tsimonq2> I guess what makes me say that is that the tests that fail are 2/3 of the tests that use the exact same function
<slangasek> right, it's not clear to me that this translates to the test suite doing something wrong, vs the code doing something wrong
<tsimonq2> Me neither :P
<tsimonq2> (this is why I'm not "just uploading" a test override, tbf)
<slangasek> that is normally what I expect to understand before I disable a test
<slangasek> but this is node code, and I don't have a handle on how it's put together
<tsimonq2> Right
<tsimonq2> Me neither, lol
<cyphermox> is there an archive admin around? I'm trying to check if "remove-package -a s390x androguard -m ANAIS" is indeed the right course of action for androguard.
<cyphermox> same story for bpfcc; I want to double check that "remove-package -a armhf -a i386 -a s390x bpfcc-lua libbpfcc -m ANAIS
<cyphermox> is indeed the right command
<infinity> cyphermox: Asking if the command is the correct form (it's not), or if it's the right course of action (dunno without investigating)
<nacc> infinity: since you responded, would you be able to do the removals in LP: #1749745 ? if not, it's ok, we're just about upload the last thing that will let php-defaults migrate
<ubot5> Launchpad bug 1749745 in zoneminder (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New] https://launchpad.net/bugs/1749745
<nacc> but i think it'll get stuck since php-mcrypt is gone
<cyphermox> infinity: both, really
<infinity> cyphermox: So, it built everywhere, the Debian maintainer reacted to an ancient bug report by arch-restricting, and we think that's the sane path forward? :P
<infinity> Well, "ancient".  But a bug report against 0.4.0
<infinity> While 0.5.0 doesn't appear to actually have the issue?
<cyphermox> infinity: well I looked at the changelog and debian does seem to have drop arches, I'm not exactly in a position to know whether it makes sense or not without a lot more investigation, in that sense I care more about command form
<infinity> Ahh, no, it was us who was carrying a patch to make it build everywhere.
<infinity> And then LocutusOfBorg dropped that patch in his merge?
<infinity> LocutusOfBorg: Why?
<infinity> cyphermox: The form of the command is missing a -b
<cyphermox> ah
<infinity> And ANAIS is an archaic term from when we used to control arch build via Packages-arch-specific, and only slangasek seems to use it to mean the exact inverse of what it used to mean. :P
<cyphermox> I didn't know about it until slangasek suggested it the other day
<cyphermox> it does kind of match "there used to be a build for that arch"
<infinity> It stands for "Architecture Not Allowed In Source", and goes back to the days where which arch picked up a build was controlled by Packages-arch-specific, a text file maintained by the buildd maintainers.
<cyphermox> sure, I understand that
<infinity> As in, it literally meant "setting the arch in your source package doesn't do any good, but we'll fix that", not "the source doesn't allow this build", which seems to be how Steve uses it. :)
<infinity> Very confusing to me, s'all.
<cyphermox> heh
<cyphermox> I can change that to ANISA
<infinity> *smirk*
<infinity> WBNBSONR
<cyphermox> architecture not in source anymore
<cyphermox> *blink*
<infinity> Will Be NBS On Next Revision!
<cyphermox> OFC
<infinity> Duh.
<cyphermox> well, you and Steve can bikeshed this all you want :P
<infinity> Well, I don't like anything that implies these removals would be remotely copy-paste automated.
<infinity> Since "it doesn't build anymore" isn't a valid reason for a removal in itself.
<cyphermox> no
<infinity> And, thus, I also like removal comments to be useful and explain WTF.
<cyphermox> ok
<infinity> Not including a '-m' at all in your sample output helps there.
<infinity> Since copying and pasting it will fail.
<cyphermox> well, I see the script being more a "this is likely the issue, but you should still damn well make sure"
<cyphermox> and since you need to be an archive admin to run this anyway, you'd know better?
<infinity> Nice theory. ;)
<cyphermox> I know, right?
<cyphermox> theory about AA's knowing better, or about it being used the way I think?
<infinity> Yes.
<infinity> We have a precedent for reports that generate commands being somewhat fail-safe for near mindless copy-pasta.
<infinity> I'm less keen on reports that generate commands that one shouldn't run.
<infinity> It's very "if everyone had a gun, no one would shoot anyone".
<cyphermox> infinity: remove-packag -d ubuntu -s bionic -b libokular5core7  about right form? (though definitely not to be run right now)
<infinity> cyphermox: Assuming you want all arches of that binary removed, yes.
<cyphermox> it's an NBS, so yeah
<infinity> Right, NBS has a report that DTRT. ;)
<cyphermox> yeah, that's what I took the command from ;)
<infinity> Oh look, every gcc version ever depends on an NBS realpath.
-queuebot:#ubuntu-release- New binary: r-cran-clustergeneration [amd64] (bionic-proposed/none) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-animation [amd64] (bionic-proposed/none) [2.5+dfsg-1] (no packageset)
<slangasek> infinity: ANAIS is frequently used by the Debian ftp team in removal messages :)
<slangasek> cyphermox: wrt those commands, you also need '-b', which I failed to include in the first command I pasted to you
<slangasek> cyphermox: ah, infinity covered that also
<LocutusOfBorg> infinity, I remember having a talk with Ritesh (Debian Maintainer), and he told something around "hey you can make it build but it won't work at all"
<LocutusOfBorg> sil2100, ppp merge please?
<LocutusOfBorg> (connman is in dep-wait now)
<sil2100> LocutusOfBorg: ACK
<acheronuk> is there as issue with the ppc64el and s390x test builders? lots of tests queuing up, and none or virtually none running?
<LocutusOfBorg> thanks sil2100 <3
<acheronuk> yeah. seems like ppc64el and s390x test builders are not really processing their queues :/
<acheronuk> at least no movement in past hr
<Laney> things are being restarted atm, it's back online now
<acheronuk> great. thanks
<tjaalton> could an archive admin remove nvidia-304 from bionic, fixes bug 1748000 and would clear the way for xserver & mesa et al
<ubot5> bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Undecided,New] https://launchpad.net/bugs/1748000
-queuebot:#ubuntu-release- New: accepted r-cran-animation [amd64] (bionic-proposed) [2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-factominer [amd64] (bionic-proposed) [1.39-1]
-queuebot:#ubuntu-release- New: accepted r-cran-clustergeneration [amd64] (bionic-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New binary: r-cran-phytools [amd64] (bionic-proposed/universe) [0.6-44-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zfs-linux [s390x] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [i386] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [amd64] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [ppc64el] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [armhf] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [arm64] (bionic-proposed/main) [0.7.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- New: accepted zfs-linux [amd64] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [armhf] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [ppc64el] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [arm64] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [s390x] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted zfs-linux [i386] (bionic-proposed) [0.7.5-1ubuntu2]
-queuebot:#ubuntu-release- New binary: udisks2 [s390x] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: udisks2 [i386] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: udisks2 [ppc64el] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: udisks2 [amd64] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: udisks2 [arm64] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: udisks2 [armhf] (bionic-proposed/main) [2.7.6-1ubuntu1] (desktop-core, ubuntu-desktop, ubuntu-server)
<xnox> sil2100, https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1555904 i don't believe we have systems available to verify this actually, thus we rely on IBM QA, which are most likely in eastern timezones, and thus are end of week now.
<ubot5> Ubuntu bug 1555904 in debian-installer (Ubuntu Xenial) "opal-prd not installed by default on ppc64el systems" [Critical,In progress]
<xnox> sil2100, i'd be inclined to mark this as verification-done, spin up RC, and see how the testing goes next week.
<xnox> sil2100, however, I also want to upload partman-auto today with swap fixes =/ and respin with that, because I am a twat like that.
<sil2100> xnox: how much time you need for the partman-auto changes?
<xnox> sil2100, should be a couple of hours
 * xnox 's famous last words
<sil2100> I guess I'll be spinning candidates a bit later anyway, so you still might make it!
<xnox> sil2100, http://paste.ubuntu.com/p/4nyBSRMh8Q/ preview of the crazy thing i want to ship
<sil2100> xnox: hm, I'm not sure it's something we'd like to introduce so late in the .4 cycle
<xnox> sil2100, yeah, we will.
<xnox> sil2100, we kind of need it to certify high-ram systems, with small disk spaces, by default.
<xnox> sil2100, because currently systems with e.g. 1TB of RAM, yet only 250GB of disk space, fail to install. because we try to create a 1TB swap partition....
<xnox> sil2100, this is fix released in bionic, effectively, due to move to swapfiles, but we cannot move to swapfiles in xenial - as it is too risky....
<LocutusOfBorg> lovely sil2100 :)
<sil2100> xnox: looking at the change again, I guess it's not as big enforcement as I originally saw, as it's just capping the RAM parameter for the default swap size calculation
<sil2100> xnox: so ok, I'm more convinced to get this in
<sil2100> LocutusOfBorg: yw o/
<xnox> sil2100, apart from that pastebin, had a typpo on the comparison =))))) anyway, rebuilt that correct, and retesting now.
<sil2100> blackboxsw: hey! How much more is needed to get LP: #1747059 verified?
<ubot5> Launchpad bug 1747059 in cloud-init (Ubuntu Artful) "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
<nacc> slangasek: iiuc, if the removals in LP: #1749745 are processed, src:php7.1 can be demoted (already possibly per c-m) and then removed once the new php-defaults is fully migrated
<ubot5> Launchpad bug 1749745 in zoneminder (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,New] https://launchpad.net/bugs/1749745
<acheronuk> hi
<acheronuk> could an archive admin please remove the ppc64el and s390 binaries of https://launchpad.net/ubuntu/+source/parley/4:17.08.3-0ubuntu2
<acheronuk> that should allow the new 17.12.2 version to migrate, which can no longer build on those architectures.
<acheronuk> due to a new non-optional build depend on QtWebEngine
<LocutusOfBorg> hello perl upload
<infinity> LocutusOfBorg: I see no perl upload.  Or was that you registering intent?
<LocutusOfBorg> infinity, just uploaded to Debian unstable
<infinity> LocutusOfBorg: Oh, yes.  Indeed.
<LocutusOfBorg> [17:35:45] <BTS> perl 5.26.1-5 uploaded by Niko Tyni (ntyni) (Closes: #890242, #891196, #891229) https://tracker.debian.org/perl
<LocutusOfBorg> I just want to point it here, in case you want to blacklist the autoimport, and delay it for some days
 * LocutusOfBorg BTW accepting remmina new binaries will make the package go in release
<infinity> LocutusOfBorg: Tempting, since I'm about to break the world with glibc.
<infinity> LocutusOfBorg: OTOH, this new perl upload is to fix it failing to build with the new glibc. :P
<LocutusOfBorg> lol better wait for perl then :) queues are empty
<LocutusOfBorg> and I need the gdbm fix...
<LocutusOfBorg> since it is partially my fault :p
<LocutusOfBorg> infinity, do you mean glibc 2.27?
<infinity> LocutusOfBorg: "wait for perl" as in do glibc after perl?  That's not going to happen.
<infinity> LocutusOfBorg: They won't entangle, though.
<infinity> It'll just be a massive autopkgtest backlog over the weekend.
<sil2100> xnox: how's the partman-auto testing going?
<infinity> LocutusOfBorg: And yes, I mean 2.27
<LocutusOfBorg> WOW!
<LocutusOfBorg> there is also a memory leak fix, so this perl is nice to have...
<infinity> If the (&!^ testsuite would ever finish on i386, it would be copied over...
<infinity> I think I got a dud VM.
<LocutusOfBorg> if you upload glibc *now* you will have ~12h of empty queues to use :p
<infinity> LocutusOfBorg: It'll be "now", ish.
<LocutusOfBorg> :) good luck!
<infinity> LocutusOfBorg: Like I said, just waiting on the i386 build to finish, then it'll binary copy over.
<infinity> The i386 build that should have finished an hour ago, but I think scalingstack might be a tad overcommitted right now.
<infinity> Or I got a compute node with disks from 1932.
<LocutusOfBorg> oh... I though the i386 was for sil not for me :)
-queuebot:#ubuntu-release- Unapproved: apt-xapian-index (xenial-proposed/universe) [0.47ubuntu8.3 => 0.47ubuntu8.4] (kubuntu)
<xnox> sil2100, it's good, uploaded bionic, will upload to xenial shortly.
-queuebot:#ubuntu-release- Unapproved: partman-auto (xenial-proposed/main) [134ubuntu1.1 => 134ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (xenial-proposed) [134ubuntu1.2]
<sil2100> xnox: please verify as soon as possible
<xnox> ack
-queuebot:#ubuntu-release- New binary: unibilium [s390x] (bionic-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: unibilium [ppc64el] (bionic-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: unibilium [amd64] (bionic-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: unibilium [i386] (bionic-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: re2 [s390x] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
<xnox> nacc, congrants on php-defaults
-queuebot:#ubuntu-release- New binary: re2 [ppc64el] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
<nacc> xnox: thanks, big props to xevious for helping out with the last few
-queuebot:#ubuntu-release- New binary: re2 [amd64] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: re2 [i386] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
<jbicha> slangasek: good morning, could you kill gtk-d/ppc64el now? (I guess someone else killed the other ldc/ppc64el stuff)
<slangasek> jbicha: I did kill the other ones based on our conversation yesterday
<slangasek> jbicha: looking at gtk-d now
<jbicha> cool, thanks
-queuebot:#ubuntu-release- New binary: unibilium [arm64] (bionic-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: unibilium [armhf] (bionic-proposed/universe) [2.0.0-2] (no packageset)
<slangasek> jbicha: done
-queuebot:#ubuntu-release- New binary: re2 [arm64] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: re2 [armhf] (bionic-proposed/universe) [20180201+dfsg-2] (kubuntu)
<sil2100> slangasek, infinity: the point-release checklist mentions: "Turn off cron jobs that will auto update into -updates until final images are tested." - is that something you can help me switch off?
<sil2100> Or is it not accurate?
<sil2100> Also, I have prepared the milestone in the ISO tracker for .4 - should I do something with the Daily milestone before I kick the first release candidates?
<infinity> sil2100: "do something with the daily milestone"?
<infinity> sil2100: All dailies while the .4 milestone is in testing will post to both daily and .4, which is what you want.
<infinity> sil2100: (You can use this knowledge to kick off all the builds from the daily milestone on the web ui and build in parallel without having to fiddle on nusakan)
<sil2100> infinity: that's a handy trick!
<sil2100> Thanks ;)
<infinity> sil2100: I believe there's still an outstanding bug where triggering ubuntu-base from the web ui does nothing useful.
<infinity> sil2100: So what I usually do after setting up a new milestone is trigger ubuntu-base manually from nusakan, check that it did all the right things and posted to the milestone, then trigger server and all the desktop flavours from the tracker.
<infinity> sil2100: Also highly recommended before starting that to do a manual 'anonftpsync' on nusakan and tail rsync.log until it's done, just in case some stale lock has screwed you.
<xnox> sil2100, https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1351267 is good. also pinged dannf to test it more as well, on their systems.
<ubot5`> Ubuntu bug 1351267 in partman-auto (Ubuntu Xenial) "partman-auto prefers to give disk to swap, leaving root too small" [Critical,Fix committed]
<xnox> sil2100, i am EOW i think
<tsimonq2> infinity, slangasek: Can I get action on bug 1751347 please, so that the KDE Apps transition isn't held up?
<ubot5`> bug 1751347 in parley (Ubuntu) "ANAIS: ppc64el and s390x binaries no longer build" [Undecided,New] https://launchpad.net/bugs/1751347
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.4] (20180223) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.4] (20180223) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- New: accepted r-cran-phytools [amd64] (bionic-proposed) [0.6-44-1]
-queuebot:#ubuntu-release- New: accepted re2 [armhf] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted re2 [arm64] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted re2 [i386] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted re2 [amd64] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted re2 [s390x] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted unibilium [arm64] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted unibilium [i386] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted unibilium [s390x] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted re2 [ppc64el] (bionic-proposed) [20180201+dfsg-2]
-queuebot:#ubuntu-release- New: accepted unibilium [armhf] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted unibilium [amd64] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted unibilium [ppc64el] (bionic-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.4] (20180223.1) has been added
<slangasek> tsimonq2: parley> done; fwiw I don't usually consider a bug report necessary for binary removals, an irc ping is sufficient
<acheronuk> slangasek: many thanks
<tsimonq2> slangasek: Thanks; acheronuk said something earlier though ;)
<slangasek> tsimonq2: right, "irc ping" vs "irc message that I don't highlight on"
<acheronuk> I didn't 'ping/notice', which in hindsight I should have done.
 * acheronuk looks at what was typed while he was typing :P
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.4] (20180223.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.4] (20180223.1) has been added
<tsimonq2> slangasek: Fair, thanks again
<LocutusOfBorg> infinity, click copy-package button? :)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.4] (20180223.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.4] (20180223.2) has been added
<slangasek> xnox: does https://launchpad.net/ubuntu/+source/prime-phylo/1.0.11-4build3/+build/13627293 ring any bells?  This seems to be an Ubuntu-specific regression not due to boost, but due to icu
-queuebot:#ubuntu-release- New: accepted webkit2gtk [amd64] (bionic-proposed) [2.19.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2gtk [armhf] (bionic-proposed) [2.19.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2gtk [ppc64el] (bionic-proposed) [2.19.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2gtk [arm64] (bionic-proposed) [2.19.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2gtk [s390x] (bionic-proposed) [2.19.91-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted webkit2gtk [i386] (bionic-proposed) [2.19.91-1ubuntu1]
<slangasek> sil2100: hi, please note LP: #1751367
<ubot5`> Launchpad bug 1751367 in pulseaudio (Ubuntu) "package libpulse0 1:10.0-2ubuntu3.1 failed to install/upgrade: trying to overwrite shared '/etc/pulse/client.conf', which is different from other instances of package libpulse0:i386" [Critical,New] https://launchpad.net/bugs/1751367
-queuebot:#ubuntu-release- Unapproved: dpkg (trusty-proposed/main) [1.17.5ubuntu5.7 => 1.17.5ubuntu5.8] (core)
<ddstreet> infinity slangasek rbasak i just uploaded patched dpkg for trusty for lp #1730627; this was uploaded last Dec by infinity but then rejected without any explanation i can find.  the patch is needed as i explain in the lp bug, but if there is some reason it was previously rejected that i don't know about please let me know
<ubot5`> Launchpad bug 1730627 in dpkg (Ubuntu Trusty) "xz compressed control.tar files not supported" [Medium,Confirmed] https://launchpad.net/bugs/1730627
<ddstreet> slangasek just fyi for you as you're sru vanguard today but this dpkg upload can wait until next week
<infinity> ddstreet: You could have just fished my upload out of the rejected queue.
<infinity> ddstreet: As for the "without any explanation", it's in the bug log.
<ddstreet> infinity i didn't find it until i already had that ready - and is it possible to un-reject an upload?
<infinity> ddstreet: Namely, I didn't bother doing the appropriate SRU template bug paperwork (and neither did you :P)
<infinity> ddstreet: Yes, it's possible to do so.
<infinity> ddstreet: I'll just resurrect mine.
<ddstreet> sounds good
<ddstreet> infinity you doing the template as well or should i do that
<infinity> ddstreet: I'm down with teamwork, if you want to mangle the bug up a bit.
<ddstreet> will do thnx
<infinity> Comforting that our uploads were nearly byte-identical.
-queuebot:#ubuntu-release- Unapproved: rejected dpkg [source] (trusty-proposed) [1.17.5ubuntu5.8]
-queuebot:#ubuntu-release- Unapproved: dpkg (trusty-proposed/main) [1.17.5ubuntu5.7 => 1.17.5ubuntu5.8] (core)
<ddstreet> infinity template added to bug, thnx
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.10 => 4.2.4-7ubuntu12.11] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.7 => 4.3.3-5ubuntu12.8] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (artful-proposed/main) [4.3.5-3ubuntu2 => 4.3.5-3ubuntu2.1] (core)
-queuebot:#ubuntu-release- New: accepted remmina [amd64] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [armhf] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [ppc64el] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [arm64] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [s390x] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [i386] (bionic-proposed) [1.2.0-rcgit.27+dfsg-3ubuntu1]
<sil2100> slangasek: noted, more for weekend/Monday as I'll be going EOD now
<sil2100> But ACK
-queuebot:#ubuntu-release- New binary: pocket-lint [amd64] (bionic-proposed/universe) [0.5.31-0ubuntu2] (no packageset)
<slangasek> tsimonq2: it seems there are a number of lubuntu-related SRUs in xenial-proposed that have not been verified.  Did you want these in for 16.04.4?
<slangasek> tsimonq2: (because the window is closing)
<tsimonq2> slangasek: Oh, they haven't been verified?
<tsimonq2> slangasek: Harumph.
<tsimonq2> slangasek: I'll look ASAP
<slangasek> tsimonq2: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows several
 * tsimonq2 grabs an install
<tsimonq2> slangasek: Got a deadline?
<tsimonq2> (Monday?)
<slangasek> tsimonq2: sil2100 already sent mail about 16.04.4 candidates; for SRUs that only affect lubuntu you have some latitude in having them released and images retested, but I don't know what the cutoff is
<tsimonq2> slangasek: When are you expecting to go EOD?
<slangasek> tsimonq2: so I'd say Monday at latest, and probably follow up to ubuntu-release with a list of those you want released
<slangasek> tsimonq2: 5:30ish my time, but also I won't release the SRUs on a Friday
<tsimonq2> slangasek: Sure
<tsimonq2> slangasek: no Friday SRUs> I guess promising I'll be around this weekend to fix things should they break doesn't make that change, does it :/
<slangasek> tsimonq2: indeed not, because I don't promise to be around to process them ;)
<tsimonq2> slangasek: OK
-queuebot:#ubuntu-release- New binary: devhelp [ppc64el] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [s390x] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [amd64] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [armhf] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [i386] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [arm64] (bionic-proposed/main) [3.27.90-1] (kubuntu, ubuntu-desktop)
#ubuntu-release 2018-02-24
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.25-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [amd64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted devhelp [armhf] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted devhelp [ppc64el] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted devhelp [arm64] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted devhelp [s390x] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New: accepted devhelp [i386] (bionic-proposed) [3.27.90-1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [amd64] (bionic-proposed/none) [390.25-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-390 [i386] (bionic-proposed/none) [390.25-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [amd64] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: impass [amd64] (bionic-proposed/none) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [ppc64el] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [s390x] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: drupal7 [amd64] (bionic-proposed/universe) [7.57-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pgpy [amd64] (bionic-proposed/universe) [0.4.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [i386] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [arm64] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: getdns [armhf] (bionic-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted drupal7 [amd64] (bionic-proposed) [7.57-1]
-queuebot:#ubuntu-release- New: accepted getdns [armhf] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted getdns [s390x] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted getdns [arm64] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted getdns [i386] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted getdns [amd64] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted impass [amd64] (bionic-proposed) [0.12-1]
-queuebot:#ubuntu-release- New: accepted getdns [ppc64el] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted python-pgpy [amd64] (bionic-proposed) [0.4.3-3]
-queuebot:#ubuntu-release- New binary: usbauth-notifier [ppc64el] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth-notifier [s390x] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth-notifier [amd64] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth-notifier [i386] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth-notifier [armhf] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
-queuebot:#ubuntu-release- New binary: usbauth-notifier [arm64] (bionic-proposed/universe) [1.0~git20180119-2] (no packageset)
<acheronuk> could someone accept the okular binaries please?
-queuebot:#ubuntu-release- New binary: gnome-keyring [ppc64el] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-keyring [s390x] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-keyring [amd64] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-keyring [i386] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-keyring [arm64] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-keyring [armhf] (bionic-proposed/main) [3.27.4-2ubuntu1] (ubuntu-desktop)
<xnox> apw, as my favourite kernel archive admin, could you please RM old nvidia-graphics-driver dkms which FTBFS with the new kernel? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1748000
<ubot5`> Ubuntu bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Critical,Triaged]
<xnox> actually i wonder if we need to fix all of nvidia anyway
<LocutusOfBorg> hello, does anybody understand why ppp is not migrating?
<LocutusOfBorg>     * amd64: freedombox-setup, indicator-network, lubuntu-desktop, lubuntu-gtk-desktop, lubuntu-qt-desktop, network-manager-fortisslvpn, network-manager-fortisslvpn-gnome, network-manager-l2tp, network-manager-l2tp-gnome, network-manager-pptp, network-manager-pptp-gnome, plinth, pppdcapiplugin, pptpd
<LocutusOfBorg> they are installable to me :/
<xnox> sforshee, https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1748000 maybe you can review the patch mentioned there.
<ubot5`> Ubuntu bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Critical,Triaged]
<xnox> i guess, i don't like the patch as is, since it changes the code, and thus the patch should be applied, only conditionally. I like your patches with if LINUX_VERSION_CODE better.
 * xnox ponders if I can manage to rework it, to be applicable at all times.
<Laney> LocutusOfBorg: e.g. https://paste.ubuntu.com/p/fb9JCmVmkD/
-queuebot:#ubuntu-release- New binary: console-bridge [s390x] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: console-bridge [i386] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: console-bridge [amd64] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [s390x] (bionic-proposed/universe) [1.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: console-bridge [ppc64el] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: console-bridge [arm64] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: console-bridge [armhf] (bionic-proposed/universe) [0.4.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fis-gtm [amd64] (bionic-proposed/universe) [6.3-003A-1] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [arm64] (bionic-proposed/universe) [1.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [ppc64el] (bionic-proposed/universe) [1.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: fis-gtm [i386] (bionic-proposed/universe) [6.3-003A-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-css-color-names [amd64] (bionic-proposed/universe) [0.0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: quintuple [amd64] (bionic-proposed/universe) [0~20171222-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-color [amd64] (bionic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [armhf] (bionic-proposed/universe) [1.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mutate-fs [amd64] (bionic-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-hack [amd64] (bionic-proposed/universe) [3.002-2] (kubuntu, personal-gunnarhj)
-queuebot:#ubuntu-release- New binary: node-err-code [amd64] (bionic-proposed/universe) [1.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containerd-cgroups [amd64] (bionic-proposed/universe) [0.0~git20180223.d578e4e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sat-templates [amd64] (bionic-proposed/universe) [0.7d+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-colormin [amd64] (bionic-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-icss-utils [amd64] (bionic-proposed/universe) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [amd64] (bionic-proposed/universe) [1.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: node-html-comment-regex [amd64] (bionic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-promzard [amd64] (bionic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-validate-npm-package-name [amd64] (bionic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: undertime [i386] (bionic-proposed/universe) [1.1.0] (no packageset)
<LocutusOfBorg> thanks Laney |!
 * LocutusOfBorg goes looking at it
<LocutusOfBorg> oh... we just need to make network-manager migrate, I was picking --proposed this is why I didn't get the break
<jbicha> LocutusOfBorg: find an AA to take care of at least fso-gsmd LP: #1718529 for the ppp transition
<ubot5`> Launchpad bug 1718529 in fso-gsmd (Ubuntu) "Please remove fso* packages from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1718529
<jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/ppp.html
<LocutusOfBorg> oh thanks :) I was driving crazy, network manager is candidate
<LocutusOfBorg> indeed
<LocutusOfBorg> tracker wins over britney :)
<jbicha> I'm still confused by britney's output but that would get us closer
-queuebot:#ubuntu-release- New: accepted console-bridge [amd64] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted console-bridge [armhf] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted console-bridge [ppc64el] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fonts-hack [amd64] (bionic-proposed) [3.002-2]
-queuebot:#ubuntu-release- New: accepted console-bridge [arm64] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted console-bridge [s390x] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted console-bridge [i386] (bionic-proposed) [0.4.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted golang-github-containerd-cgroups [amd64] (bionic-proposed) [0.0~git20180223.d578e4e-1]
-queuebot:#ubuntu-release- New: accepted node-colormin [amd64] (bionic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted node-err-code [amd64] (bionic-proposed) [1.1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted node-icss-utils [amd64] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-promzard [amd64] (bionic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted quintuple [amd64] (bionic-proposed) [0~20171222-1]
-queuebot:#ubuntu-release- New: accepted undertime [amd64] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted undertime [armhf] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted undertime [ppc64el] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [amd64] (bionic-proposed) [1.0~git20180119-2]
-queuebot:#ubuntu-release- New: accepted node-color [amd64] (bionic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-html-comment-regex [amd64] (bionic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted node-validate-npm-package-name [amd64] (bionic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted undertime [arm64] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted undertime [s390x] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [armhf] (bionic-proposed) [1.0~git20180119-2]
-queuebot:#ubuntu-release- New: accepted node-css-color-names [amd64] (bionic-proposed) [0.0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sat-templates [amd64] (bionic-proposed) [0.7d+dfsg-1]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [arm64] (bionic-proposed) [1.0~git20180119-2]
-queuebot:#ubuntu-release- New: accepted node-mutate-fs [amd64] (bionic-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [i386] (bionic-proposed) [1.0~git20180119-2]
-queuebot:#ubuntu-release- New: accepted undertime [i386] (bionic-proposed) [1.1.0]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [ppc64el] (bionic-proposed) [1.0~git20180119-2]
-queuebot:#ubuntu-release- New: accepted usbauth-notifier [s390x] (bionic-proposed) [1.0~git20180119-2]
 * LocutusOfBorg still tries to understand what britney says after all this years, but at least he has the same issue with my wife, and girls in general :)
<LocutusOfBorg> s/my/his
<acheronuk> could someone please accept okular binaries please?
<tsimonq2> LocutusOfBorg: I *think* Britney's a "she" ;)
<tsimonq2> slangasek, Laney: Can someone please do a Binary NEW review of src:okular in Bionic?
<acheronuk> tsimonq2: maybe hold on that
<acheronuk> tsimonq2: getting ready to merge that as much as I can with debian, which means a new qml module package
<xnox> things migrated \o/ yeah
<tsimonq2> \o/
-queuebot:#ubuntu-release- New: accepted fis-gtm [i386] (bionic-proposed) [6.3-003A-1]
-queuebot:#ubuntu-release- New: accepted fis-gtm [amd64] (bionic-proposed) [6.3-003A-1]
-queuebot:#ubuntu-release- New binary: node-npm-bundled [amd64] (bionic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: okular [s390x] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [ppc64el] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [amd64] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [arm64] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [armhf] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New binary: okular [i386] (bionic-proposed/universe) [4:17.12.2-0ubuntu2] (kubuntu)
<tsimonq2> https://wiki.ubuntu.com/ProposedMigration/LocalSetup -- seems that the links from people.canonical.com/~pitti are dead...
<tsimonq2> Does anyone have copies of these scripts that we can put someplace to fix the links there, or will they have to be written from scratch?
-queuebot:#ubuntu-release- New binary: vmdb2 [amd64] (bionic-proposed/universe) [0.12-1] (no packageset)
-queuebot:#ubuntu-release- New source: kio-gdrive (bionic-proposed/primary) [1.2.1-0ubuntu1]
#ubuntu-release 2018-02-25
-queuebot:#ubuntu-release- New binary: node-date-time [amd64] (bionic-proposed/none) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-rollup-plugin-buble [amd64] (bionic-proposed/none) [0.15.0-1] (no packageset)
<rbasak> ddstreet: IIRC I rejected dpkg once due to lack of bug reference in the changelog. I'm not sure if that was your one.
-queuebot:#ubuntu-release- New binary: jquery-caret.js [amd64] (bionic-proposed/none) [0.3.1+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New sync: nx-libs (bionic-proposed/primary) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [sync] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted jquery-caret.js [amd64] (bionic-proposed) [0.3.1+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted node-date-time [amd64] (bionic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-buble [amd64] (bionic-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted node-npm-bundled [amd64] (bionic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted vmdb2 [amd64] (bionic-proposed) [0.12-1]
-queuebot:#ubuntu-release- New binary: nx-libs [s390x] (bionic-proposed/none) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [amd64] (bionic-proposed/none) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [i386] (bionic-proposed/none) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [ppc64el] (bionic-proposed/none) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [arm64] (bionic-proposed/none) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [armhf] (bionic-proposed/universe) [2:3.5.99.13-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted nx-libs [amd64] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [armhf] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [ppc64el] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [arm64] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [s390x] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New: accepted nx-libs [i386] (bionic-proposed) [2:3.5.99.13-4]
-queuebot:#ubuntu-release- New binary: ruby-hamlit [ppc64el] (bionic-proposed/none) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [s390x] (bionic-proposed/none) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [amd64] (bionic-proposed/universe) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [arm64] (bionic-proposed/universe) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [i386] (bionic-proposed/universe) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [armhf] (bionic-proposed/universe) [2.8.7-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [amd64] (bionic-proposed) [2.8.7-2]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [armhf] (bionic-proposed) [2.8.7-2]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [ppc64el] (bionic-proposed) [2.8.7-2]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [arm64] (bionic-proposed) [2.8.7-2]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [s390x] (bionic-proposed) [2.8.7-2]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [i386] (bionic-proposed) [2.8.7-2]
<xnox> infinity, slangasek: i think src:systemd should ship "dummy" transitional packages initscripts & upstart, which are full of rm_conffile
<xnox> or maybe not src:upstart, but like something call "upgrade purger"
<xnox> or maybe not src:upstart, but like something called "upgrade purger"
<slangasek> xnox: I would not object to such dummy packages to handle the upgrade cleanup
<xnox> to clean up, after packages that are removed from the archive, but had coffiles, xenial->bionic.
<slangasek> xnox: it's "cleaner" than doing it in the release upgrader; but I'm fine with that also
<xnox> and we may assemble them in a single source package, and generate the right binary names, with the right versions, etc.
<slangasek> Laney: s390x autopkgtest queue is underperforming; I haven't looked into it yet https://cloud.kpi.canonical.com/dashboard/db/ubuntu-foundations?panelId=19&fullscreen&orgId=1&from=1519291919551&to=1519594805472
<slangasek> infinity: ^^ need more glibc uploads, that's a great dataset for assessing the autopkgtest throughput
<jbicha> slangasek: could you look into LP: #1718529 when you have a chance to try to unblock NM & ppp ?
<ubot5`> Launchpad bug 1718529 in fso-gsmd (Ubuntu) "Please remove fso* packages from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1718529
<slangasek> jbicha: sure; do you want to trade me for analysis / fixing of the glibc-triggered autopkgtest regressions, which is what I was going to be working on? :)
<infinity> There aren't many, thankfully.
<jbicha> cough, cough, cough
<slangasek> astroscrappy is almost certainly badtest, I just hadn't figured out what that means yet
<infinity> Waking up to the sea of green was a pleasant surprise.
<infinity> slangasek: That string doesn't appear in astrocrappy's source, so I assume it's a dep that hates life.
<infinity> But that's as far as I dug before reminding myself it's a weekend.
<jbicha> I thought you guys were making up the name of that packageâ¦
<slangasek> I remembered the s
<slangasek> infinity ... refactored it
<slangasek> I assume astroscrappy is an add-on package for astroscooby
<jbicha> "Optimized Cosmic Ray Annihilation in Python 3"
<jbicha> oh, the github acronym is better "Speedy Cosmic Ray Annihilation Package in Python"
<xnox> slangasek, what about nvidia-304? it's blocking my xorg upgrade fix.... https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1748000 or should i be working with the kernel team to fix it, because hwe & xenial still probably needs to ship nvidia 304?!
<ubot5`> Ubuntu bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Critical,Triaged]
<jbicha> xnox: I'm hoping the mesa/nvidia transition finishes on Monday, not sure how much it's related to your bug
<slangasek> xnox: ok, that one I'll trade you for the libunistring-triggered regression in tracker, which looks like it might be a difficult-to-bisect gnulib problem ;)
<xnox> slangasek, this is not how the scrub poker is supposed to work!
<xnox> *scrum
 * jbicha folds
 * xnox ponders if we can make an Agile method based on the Risk strategy board game of diplomacy, conflict and conquest
<slangasek> xnox: I think you care about tracker, libunistring is tied to libcurl4
<xnox> sigh
<slangasek> xnox: speaking of which, we've got Debian maintainer ack, I think we should proceed with that upload at least
<xnox> slangasek, yes, my plan was to kick it off on Monday.
<slangasek> ok
<xnox> slangasek, it will need new queue processing, so will not upload no change rebuilds. Unless I do the doko hack of the .dsc
<xnox> to include extra build-depends on libcurl-dev (>= bla)
<slangasek> ick no :)
<acheronuk> slangasek: can the ppc64el and s390x tests on parley be ignored please? http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#parley
<acheronuk> as it no longer builds on those architectures
<acheronuk> ^^^ not urgent :)
#ubuntu-release 2019-02-18
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-143.169~14.04.2]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1039.43] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1039.43]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1039.41~14.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1039.41~14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (bionic-proposed) [7.2.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-books [amd64] (disco-proposed) [3.31.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-books [armhf] (disco-proposed) [3.31.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-books [ppc64el] (disco-proposed) [3.31.90-1]
-queuebot:#ubuntu-release- New: accepted gnome-books [arm64] (disco-proposed) [3.31.90-1]
-queuebot:#ubuntu-release- New: accepted golang-github-thcyron-uiprogress [amd64] (disco-proposed) [0.0~git20171218.25e98ff-1]
-queuebot:#ubuntu-release- New: accepted gnome-books [i386] (disco-proposed) [3.31.90-1]
<acheronuk> sil2100: hi. would you have time to run an update of the Kubuntu package set?
<sil2100> acheronuk: hey! We're sprinting right now, but I can do that somewhen today in-between meetings :)
<acheronuk> sil2100: thank you. that would be great.
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (cosmic-proposed) [3.90ubuntu3.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (bionic-proposed) [3.90ubuntu3.18.04.2]
<juliank> doko: to reduce python2 in main, should we just do Extra-Exclude: python-*-dbg python-*-dev in supported seed? e.g. python-apt is probably only pulled into main by python-apt-{dbg,dev} via Extra-Include: *-dbg *-debug *-dev *-doc *-docs gir1.2-* *-examples
<juliank> vorlon, infinity ^
<doko> why not have extra-excludes for python-apt?
<vorlon> I think the point is that if we did python-*-dbg python-*-dev as a pattern we would potentially catch more things that are autopromoted
<vorlon> and it sounds reasonable to me
<juliank> doko, vorlon Yeah I think we reached the point where we should pull any remaining python-*-{dbg,dev} packages in manually if we really need them
<juliank> Though, um, I guess that would not work
<juliank> But we also don't need -dev packages in main anymore, and it seems ot make sense to not have them for python2 ibraries to discourage python2 development
<vorlon> why would it not work? Extra-Exclude only overrides Extra-Include
<vorlon> and Extra-Exclude: python-*-dbg python-*-dev sounds good to me
<juliank> oh right
<juliank> let's do it
<juliank> and it's done
-queuebot:#ubuntu-release- New binary: vmdk-stream-converter [amd64] (disco-proposed/main) [0.2-4ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New: accepted vmdk-stream-converter [amd64] (disco-proposed) [0.2-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.6]
<bshah> infinity: sil2100: Hi there, can someone look into SRU : https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/1777994 (comment #5)
<ubot5> Launchpad bug 1777994 in libxcb (Ubuntu Bionic) "the header xcb/xinput.h is missing" [Low,Fix committed]
<sil2100> bshah: looking
<bshah> Thanks :)
<doko> rbalint: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/l/livecd-rootfs/20190218_124002_f076c@/log.gz
-queuebot:#ubuntu-release- Unapproved: rejected libxcb [source] (bionic-proposed) [1.13-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1.4]
<slashd> sil2100, can you please release pciutils for xenial and bionic in -updates for me ?
<slashd> query sil2100
-queuebot:#ubuntu-release- Unapproved: libguestfs (xenial-proposed/universe) [1:1.32.2-4ubuntu2.1 => 1:1.32.2-4ubuntu2.2] (no packageset)
<rbalint> doko, yes, it is expected, xnox uploads livecd-rootfs with the other side of the fix
<xnox> rbalint, doko - livecd-rootfs is in proposed
<xnox> it's in autopkgtests right now
-queuebot:#ubuntu-release- Unapproved: syslinux (cosmic-proposed/main) [3:6.04~git20171011.af7e95c3+dfsg1-4ubuntu1.18.10.1 => 3:6.04~git20171011.af7e95c3+dfsg1-4ubuntu1.18.10.2] (core)
-queuebot:#ubuntu-release- Unapproved: syslinux (bionic-proposed/main) [3:6.03+dfsg1-2ubuntu0.18.04.1 => 3:6.03+dfsg1-2ubuntu0.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected libguestfs [source] (xenial-proposed) [1:1.32.2-4ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted syslinux [source] (cosmic-proposed) [3:6.04~git20171011.af7e95c3+dfsg1-4ubuntu1.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted syslinux [source] (bionic-proposed) [3:6.03+dfsg1-2ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: libguestfs (xenial-proposed/universe) [1:1.32.2-4ubuntu2.1 => 1:1.32.2-4ubuntu2.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (xenial-proposed) [1:1.32.2-4ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.18 => 2.525.19] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.43 => 2.408.44] (desktop-core)
<cjwatson> infinity: ^- same again x2
<cjwatson> Err hmm I suppose that should've had a bug# :-(
<cjwatson> I'll self-reject and reupload
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.44]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.19]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.18 => 2.525.19] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.43 => 2.408.44] (desktop-core)
-queuebot:#ubuntu-release- New binary: redmine [amd64] (disco-proposed/universe) [4.0.1-1] (no packageset)
#ubuntu-release 2019-02-19
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.37.1 => 2.37.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.37.1.1+18.04 => 2.37.3+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.37.1+18.10 => 2.37.3+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.37.1~14.04 => 2.37.3~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1007.8] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1034.39] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1007.8]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1034.39]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1009.11] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1009.11]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1007.8~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1009.11~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: golang-1.8 (bionic-proposed/universe) [1.8.3-2ubuntu1 => 1.8.3-2ubuntu1.1] (no packageset)
<acheronuk> sil2100: hi, might you be able to do that Kubuntu packageset update? No worries if you just can't :)
<acheronuk> or cyphermox? ^
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1009.11~16.04.1]
<cyphermox> acheronuk: do you need one package in particular? I'm still half-way done reviewing the changes
<cyphermox> I'll try to finish it now anywya
<acheronuk> cyphermox: not urgently today. thanks. kitinerary and kpkpass are the most crucial, as they are part of New KDE apps release I want to try to beat the freeze to update (may end up FFE anyway)
<acheronuk> the rest are new KDE/Qt things, or old ones that somehow dropped out at some point
<cyphermox> ok; update in progress
<cyphermox> (I've finished the review)
<cyphermox> but let's make sure the things are in
<cyphermox> kitinerary and kpkpass confirmed
<sil2100> acheronuk: ...crap, forgot about that, but cyphermox was on it indeed
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-16.17~18.04.1] (kernel)
<cyphermox> acheronuk: I think you should be good to go now
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-16.17~18.04.1] (kernel)
<fidencio> does someone know fro the top of their head in which release ubuntu had python3 as default?
<doko> none, there almost always was python2 and python3 in parallel
-queuebot:#ubuntu-release- Packageset: 601 entries have been added or removed
<acheronuk> cyphermox: looks like it. thank you :)
 * apw is looking at snapd
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.5.0~beta4-7359-g1f94845ac-0ubuntu1~18.04.1]
<rbasak> https://code.launchpad.net/~ubuntu-sru/+activereviews
-queuebot:#ubuntu-release- New binary: libreoffice-l10n [amd64] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.19]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.44]
<sil2100> Laney: in case you didn't find it: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/355544
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
<cyphermox> acheronuk: glad to hear
<sil2100> Laney: actually, checked the docs of the e-mail interface and you can send comments through e-mails that are signed with a known GPG key
<sil2100> Laney: so that might be some path to go forward if you'll be -1 on the lplib
<sil2100> Maybe we could re-use the same credentials from the e-mail policy
<sil2100> Laney: would you prefer me to re-work it in that way?
<Laney> sil2100: I see "Messages that just add comments to a bug or merge proposal are not required to be signed"
<sil2100> Laney: actually I missed that one!
<Laney> :>
<sil2100> (even though it's the next sentence after the one I read)
<sil2100> Laney: so I guess... ignore the review, let me rewrite it
<sil2100> :|
 * Laney learns how to trick sil2100 
<sil2100> Laney: how did you know about the e-mail interface? That seems so... old
<Laney> sil2100: you never reply to bug mail?!?!?!
<LocutusOfBorg> vorlon, I'm seriously thinking about uploading pandas (new release) with testsuite disabled, to see what happens
<LocutusOfBorg> should it make things worse?
<LocutusOfBorg> it is btw tracked upstream https://github.com/pandas-dev/pandas/issues/25322
<gitbot> pandas-dev issue 25322 in pandas "pandas 0.24.1 testsuite failure with new numpy (" [Build, Compat, Open]
<vorlon> LocutusOfBorg: how is ignoring the incompatibility between pandas and the new python-numpy in -proposed *not* making things worse?
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1007.8~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-16.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-16.17~18.04.1]
<LocutusOfBorg> vorlon, you sure it isn't a testsuite fault?
<vorlon> LocutusOfBorg: no. are you sure it is?
<LocutusOfBorg> no :) this is why I didn't upload before asking
<LocutusOfBorg> I did some investigation and the result is that I can't understand that code
<fidencio> jibel: https://www.redhat.com/archives/libosinfo/2019-February/msg00107.html
<fidencio> jibel: and, again, thanks a lot!
<jibel> Hi fidencio, that's great! I'm happy it helped you.
<jbicha> jibel: awesome, that's been a wishlist item for years ð
<fidencio> jbicha: unattended installations for Ubuntu?
<fidencio> jbicha: I mean, on Boxes
<fidencio> jbicha: if so, it'll be part of 3.32 release as it depends on some new APIs on libosinfo + some code changes on Boxes itself
<jbicha> yes
<fidencio> jbicha: yeah, it's been a long time I wanted that as well. Just never had enough time to work on that
-queuebot:#ubuntu-release- New binary: golang-github-hetznercloud-hcloud-go [amd64] (disco-proposed/none) [1.12.0+git20190218.63d492d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [i386] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [arm64] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libreoffice [armhf] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: roundcube-plugins-extra [amd64] (disco-proposed/universe) [1.3.8-20190219] (no packageset)
#ubuntu-release 2019-02-20
-queuebot:#ubuntu-release- New: accepted golang-github-hetznercloud-hcloud-go [amd64] (disco-proposed) [1.12.0+git20190218.63d492d-1]
-queuebot:#ubuntu-release- New: accepted roundcube-plugins-extra [amd64] (disco-proposed) [1.3.8-20190219]
-queuebot:#ubuntu-release- New: accepted redmine [amd64] (disco-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted libreoffice-l10n [amd64] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (disco-proposed/main) [1:6.2.1~rc1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.18-dfsg-3~ubuntu18.04.1 => 5.2.18-dfsg-3~ubuntu18.04.2] (no packageset)
<fidencio> jbicha: jibel: https://twitter.com/ffidencio/status/1098194562659614720
-queuebot:#ubuntu-release- Unapproved: base-files (trusty-proposed/main) [7.2ubuntu5.5 => 7.2ubuntu5.6] (core)
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.7 => 9.4ubuntu4.8] (core)
-queuebot:#ubuntu-release- New binary: sagemath [i386] (disco-proposed/universe) [8.6-5] (no packageset)
-queuebot:#ubuntu-release- New binary: sagemath [ppc64el] (disco-proposed/universe) [8.6-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.8]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.27 => 20101020ubuntu451.28] (core)
-queuebot:#ubuntu-release- New binary: sagemath [amd64] (disco-proposed/universe) [8.6-5] (no packageset)
<cjwatson> Stopping transition tracker updates while I see if I can lift and shift it over to the bionic chroot
<infinity> Ooo, fancy.
<cjwatson> (doko got that created via RT)
<infinity> Does it actually need to be in a chroot at all anymore?   I thought it was in one because it needed newer packages than the base system provided at the time.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.28]
<Laney> It needs a ton of ocaml stuff
<cjwatson> infinity: Yes, because snakefruit is xenial while versioned provides (the motivation for this change) requires bionic
<cjwatson> Wasn't implemented in dose3 until then
<infinity> Ahh, fair enough.
<cjwatson> The ocaml stuff is less of a problem now that we're using the ben and dose-distcheck binary packages rather than building it from source
<Laney> ah, I missed the former
<cjwatson> (still pulls in a few ocaml packages, but much less than it used to when we had a ton of -dev)
-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: rejected libio-socket-ssl-perl [sync] (bionic-proposed) [2.060-3~ubuntu18.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected nova [sync] (bionic-proposed) [2:17.0.7-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-cryptography [sync] (bionic-proposed) [2.1.4-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: rejected python3.6 [sync] (bionic-proposed) [3.6.8-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected r-cran-openssl [sync] (bionic-proposed) [1.0.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [sync] (bionic-proposed) [2.5.1-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected libnet-ssleay-perl [sync] (bionic-proposed) [1.84-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected python2.7 [sync] (bionic-proposed) [2.7.15-4ubuntu4~18.04]
-queuebot:#ubuntu-release- Unapproved: rejected ruby-openssl [sync] (bionic-proposed) [2.0.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected python3.7 [sync] (bionic-proposed) [3.7.2-1~18.04.1]
<cjwatson> Hmm, can't seem to get the bionic tracker to work
<cjwatson> E: General error: ben-specific error: template debian not found
<cjwatson> Trying to reproduce locally
<cjwatson> Reproduced locally with minimal config; rebuilding doesn't help
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.6] (20101020ubuntu451.28) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.6] (20101020ubuntu451.28) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.6] (20101020ubuntu451.28) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.6] (20101020ubuntu451.28) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.6] (20101020ubuntu451.28) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.6] (20101020ubuntu451.28) has been added
<sil2100> ^ ignore those, .6 is still not a thing
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (cosmic-proposed) [2.37.3+18.10]
<coreycb> hello, can an archive admin please look at accepting masakari from the disco NEW queue? we are adding support for the masakari project which provides VM HA for openstack.
-queuebot:#ubuntu-release- New binary: sagemath [arm64] (disco-proposed/universe) [8.6-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (disco-proposed) [1.2.4-2]
<infinity> coreycb: Is that headed to Debian at some point?
<coreycb> infinity: probably not, they generally do openstack packages seperately
-queuebot:#ubuntu-release- New: rejected initramfs-tools-devices [source] (cosmic-proposed) [0.1]
<coreycb> infinity: core openstack packages at least. we share a lot of dependencies but generally not core openstack packages that we have in main.
<infinity> Mmkay.
-queuebot:#ubuntu-release- New binary: lazarus [i386] (disco-proposed/universe) [2.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lazarus [amd64] (disco-proposed/universe) [2.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lazarus [armhf] (disco-proposed/universe) [2.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lazarus [arm64] (disco-proposed/universe) [2.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sagemath [armhf] (disco-proposed/universe) [8.6-5] (no packageset)
<vorlon> Laney, juliank, sil2100: armhf runners were failed - Feb 17 14:42:05 juju-prod-ues-proposed-migration-machine-12 sh[29907]: autopkgtest [14:42:04]: ERROR: testbed failure: unexpected eof from the testbed
<juliank> ugh
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.1-0ubuntu1 => 3:14.0.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New source: waylandpp (disco-proposed/primary) [0.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New source: libmarc-charset-perl (disco-proposed/primary) [1.35-2build1]
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (cosmic-proposed/main) [2.5.1-5ubuntu4.1 => 2.5.1-5ubuntu4.2] (kubuntu, ubuntu-desktop, ubuntu-server)
<ricotz> hello, was this forgotten to be (fully) approved https://launchpad.net/ubuntu/+source/fwupd/1.2.4-3 ?
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lldpd (bionic-proposed/universe) [0.9.9-1 => 0.9.9-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lldpd (cosmic-proposed/universe) [1.0.1-1 => 1.0.1-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-go-xorm-core [amd64] (disco-proposed/none) [0.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [amd64] (disco-proposed/none) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sat-pubsub [amd64] (disco-proposed/none) [0.3.0a1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [i386] (disco-proposed/none) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vue-router.js [amd64] (disco-proposed/none) [3.0.2+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-teris-io-shortid [amd64] (disco-proposed/none) [1.0+git20171029.771a37c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [amd64] (disco-proposed/none) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [ppc64el] (disco-proposed/none) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [ppc64el] (disco-proposed/none) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [i386] (disco-proposed/none) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [s390x] (disco-proposed/none) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [s390x] (disco-proposed/none) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speech-dispatcher-contrib [i386] (disco-proposed/multiverse) [0.9.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [armhf] (disco-proposed/universe) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcloud-cli [arm64] (disco-proposed/universe) [1.11.0+git20190206.5780af6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [armhf] (disco-proposed/universe) [0.26.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uefitool [arm64] (disco-proposed/universe) [0.26.0-1] (no packageset)
#ubuntu-release 2019-02-21
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.6 => 4.0.0-1ubuntu8.7] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (cosmic-proposed/main) [4.6.0-2ubuntu3.2 => 4.6.0-2ubuntu3.3] (ubuntu-server, virt)
<juliank> sil2100: we can release apt/trusty
<juliank> the regressions are not regressions
<ginggs> these are not the regressions you are looking for
-queuebot:#ubuntu-release- New: accepted golang-github-go-xorm-core [amd64] (disco-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [amd64] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [armhf] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [ppc64el] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-teris-io-shortid [amd64] (disco-proposed) [1.0+git20171029.771a37c-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [i386] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [arm64] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted hcloud-cli [s390x] (disco-proposed) [1.11.0+git20190206.5780af6-1]
-queuebot:#ubuntu-release- New: accepted sat-pubsub [amd64] (disco-proposed) [0.3.0a1-1]
-queuebot:#ubuntu-release- New: accepted uefitool [arm64] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted uefitool [i386] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted uefitool [s390x] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted uefitool [amd64] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted uefitool [ppc64el] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted uefitool [armhf] (disco-proposed) [0.26.0-1]
-queuebot:#ubuntu-release- New: accepted vue-router.js [amd64] (disco-proposed) [3.0.2+ds-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [armhf] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [arm64] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice [i386] (disco-proposed) [1:6.2.1~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected masakari [source] (disco-proposed) [7.0.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New source: flatbuffers (disco-proposed/primary) [1.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lazarus [amd64] (disco-proposed) [2.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lazarus [armhf] (disco-proposed) [2.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sagemath [amd64] (disco-proposed) [8.6-5]
-queuebot:#ubuntu-release- New: accepted sagemath [armhf] (disco-proposed) [8.6-5]
-queuebot:#ubuntu-release- New: accepted sagemath [ppc64el] (disco-proposed) [8.6-5]
-queuebot:#ubuntu-release- New: accepted lazarus [arm64] (disco-proposed) [2.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sagemath [arm64] (disco-proposed) [8.6-5]
-queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [i386] (disco-proposed) [0.9.0-5]
-queuebot:#ubuntu-release- New: accepted lazarus [i386] (disco-proposed) [2.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sagemath [i386] (disco-proposed) [8.6-5]
-queuebot:#ubuntu-release- New: rejected waylandpp [source] (disco-proposed) [0.2.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected flatbuffers [source] (disco-proposed) [1.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New sync: libmarc-charset-perl (disco-proposed/primary) [1.35-2]
-queuebot:#ubuntu-release- New: accepted libmarc-charset-perl [sync] (disco-proposed) [1.35-2]
-queuebot:#ubuntu-release- New: rejected libmarc-charset-perl [source] (disco-proposed) [1.35-2build1]
-queuebot:#ubuntu-release- New source: initramfs-tools-devices (disco-proposed/primary) [0.3]
-queuebot:#ubuntu-release- New binary: libmarc-xml-perl [amd64] (disco-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (cosmic-proposed/universe) [2.0.0-0ubuntu2 => 2.0.0-0ubuntu2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openssl-ibmca (bionic-proposed/universe) [1.4.1-0ubuntu1 => 1.4.1-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libmarc-xml-perl [amd64] (disco-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- Unapproved: opencryptoki (cosmic-proposed/universe) [3.10.0+dfsg-0ubuntu1 => 3.10.0+dfsg-0ubuntu1.1] (no packageset)
<ogra> abeato, infinity, vorlon initramfs-tools-devices uploaded to the dingo ... (please move out of NEW)
<abeato> ogra, thank you!
-queuebot:#ubuntu-release- New: accepted python-os-ken [source] (disco-proposed) [0.3.1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected fwupd-snap [source] (disco-proposed) [1.0]
-queuebot:#ubuntu-release- New binary: sagetex [amd64] (disco-proposed/universe) [3.2+ds-2] (no packageset)
<vorlon> ogra, abeato: ta
-queuebot:#ubuntu-release- New binary: python-os-ken [amd64] (disco-proposed/none) [0.3.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maven-debian-helper (bionic-proposed/universe) [2.3~exp1 => 2.3.2~18.04.1] (no packageset) (sync)
<cjwatson> doko: I've turned the transition tracker back on using the trusty chroot, because I haven't been able to get ben working in bionic and don't have time to fix it.  If you want to pursue this then I suggest getting ben working in bionic, or finding people who can fix it
-queuebot:#ubuntu-release- Unapproved: accepted maven-debian-helper [sync] (bionic-proposed) [2.3.2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: skiboot (cosmic-proposed/main) [6.1-2 => 6.1-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: skiboot (bionic-proposed/main) [5.10~rc4-1ubuntu1.1 => 5.10~rc4-1ubuntu1.2] (core)
<doko> cjwatson: ta
-queuebot:#ubuntu-release- New binary: libcatmandu-marc-perl [amd64] (disco-proposed/universe) [1.24-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcatmandu-marc-perl [amd64] (disco-proposed) [1.24-1]
-queuebot:#ubuntu-release- New: accepted sagetex [amd64] (disco-proposed) [3.2+ds-2]
-queuebot:#ubuntu-release- New: accepted python-os-ken [amd64] (disco-proposed) [0.3.1-0ubuntu1]
-queuebot:#ubuntu-release- New sync: dd-plist (bionic-proposed/primary) [1.20-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: plexus-languages (bionic-proposed/universe) [0.9.5-2 => 0.9.10-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: testng (bionic-proposed/universe) [6.9.12-2 => 6.9.12-2ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-lang3-java (bionic-proposed/universe) [3.5-2ubuntu1 => 3.8-1~18.04.2] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: dd-plist (bionic-proposed/primary) [1.20-1~18.04.1]
-queuebot:#ubuntu-release- New: rejected dd-plist [sync] (bionic-proposed) [1.20-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted testng [sync] (bionic-proposed) [6.9.12-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plexus-languages [sync] (bionic-proposed) [0.9.10-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-lang3-java [sync] (bionic-proposed) [3.8-1~18.04.2]
-queuebot:#ubuntu-release- New: accepted dd-plist [sync] (bionic-proposed) [1.20-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: clojure1.8 (bionic-proposed/universe) [1.8.0-5 => 1.8.0-7ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [3.4.1-7ubuntu1 => 4.4.1-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jtreg (bionic-proposed/universe) [4.2-b10-1 => 4.2-b13-1ubuntu0.1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-compiler-plugin (bionic-proposed/universe) [3.6.2-2ubuntu2 => 3.8.0-1ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: surefire (bionic-proposed/universe) [2.20.1-3build1 => 2.22.0-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clojure1.8 [sync] (bionic-proposed) [1.8.0-7ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [4.4.1-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted jtreg [sync] (bionic-proposed) [4.2-b13-1ubuntu0.1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maven-compiler-plugin [sync] (bionic-proposed) [3.8.0-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted surefire [sync] (bionic-proposed) [2.22.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: gradle-debian-helper (bionic-proposed/universe) [1.6ubuntu1 => 2.0.2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: groovy (bionic-proposed/universe) [2.4.15-1ubuntu1 => 2.4.16-1ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle-debian-helper [sync] (bionic-proposed) [2.0.2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted groovy [sync] (bionic-proposed) [2.4.16-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (cosmic-proposed) [2.6.0-0ubuntu7.2]
<bdmurray> xnox: bug 1790831 is also missing SRU information
<ubot5> bug 1790831 in Ubuntu on IBM z Systems "lstape, lsluns: handle non-zfcp; lin_tape multiple paths" [Medium,In progress] https://launchpad.net/bugs/1790831
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (cosmic-proposed) [3.30.5-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [source] (cosmic-proposed) [3.30.5-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New source: masakari (disco-proposed/primary) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (cosmic-proposed) [3.30.5-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- New binary: mutter [amd64] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [s390x] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [i386] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
<LocutusOfBorg> infinity, https://launchpad.net/ubuntu/+source/libmarc-charset-perl/+publishinghistory what did happen?
<infinity> LocutusOfBorg: britney lost its mind?
<LocutusOfBorg> do you think you can fix it? or is it better to no-change rebuild and reupload? I think the former
<infinity> LocutusOfBorg: I've already copied it back.
<infinity> Oh, britney had promoted it.  I guess I'll copy to release.
-queuebot:#ubuntu-release- New binary: mutter [armhf] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
<LocutusOfBorg> meh, I don't think to coincidences...
<cjwatson> I'll grep logs
<cjwatson> Though not right now
<cjwatson> <PlainPackageCopyJob to copy package libmarc-charset-perl from ubuntu, PROPOSED pocket, in ubuntu disco to ubuntu, RELEASE pocket, in ubuntu disco, including binaries>
<cjwatson> raised CannotCopy:
<cjwatson> libmarc-charset-perl 1.35-2 in disco (binaries conflicting with the existing ones)
<cjwatson> I reckon that this is a problem specific to having copied the binaries forward from xenial, somehow
<cjwatson> Not the usual thing
-queuebot:#ubuntu-release- New binary: mutter [arm64] (disco-proposed/main) [3.31.90-2~fakesync] (desktop-core, desktop-extra)
<cjwatson> Not sure exactly why but it may need a no-change rebuild to get things fixed up
<cjwatson> Or maybe not; if it publishes then all is good
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (disco-proposed) [3.31.90-2~fakesync]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (disco-proposed) [3.31.90-2~fakesync]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (disco-proposed) [3.31.90-2~fakesync]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (disco-proposed) [3.31.90-2~fakesync]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (disco-proposed) [3.31.90-2~fakesync]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (disco-proposed) [3.31.90-2~fakesync]
<LocutusOfBorg> cjwatson, so, you think we are good? I see it is published
<infinity> Might have been goofy because there was a powerpc build.
<infinity> Going to wait until I see the result in rmadison, but I think it's okayish now.
<LocutusOfBorg> yes, I checked rmadison and it wasn't happy... interesting the powerpc thing..
 * apw wonders how it was not ok before and became ok this time
<LocutusOfBorg> apw, I was wondering the same, maybe the second copy was done from proposed to proposed again, or from disco/* to disco-proposed
<LocutusOfBorg> so powerpc wasn't there anymore
<cjwatson> A powerpc build is a fair guess, yes
<cjwatson> Not sure precisely, not going to trace now since it isn't a systemic problem with copies
<LocutusOfBorg>  libmarc-charset-perl | 1.35-2 | xenial/universe  | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<LocutusOfBorg>  libmarc-charset-perl | 1.35-2 | disco/universe   | source, amd64, arm64, armhf, i386, ppc64el, s390x
<infinity> Yeah, this is a known bug.  I don't remember the number.
-queuebot:#ubuntu-release- New binary: poppler [s390x] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
<infinity> Copying forward from xenial works.  Copying back from disco-proposed to disco fails.
<infinity> My second copy was from xenial to disco, bypassing that.
-queuebot:#ubuntu-release- New binary: poppler [amd64] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu3.18.10.1 => 1.5ubuntu3.18.10.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (disco-proposed/multiverse) [10.0.130-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (cosmic-proposed) [18.01-0ubuntu4.2]
-queuebot:#ubuntu-release- New binary: poppler [armhf] (disco-proposed/main) [0.74.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (bionic-proposed) [18.01-0ubuntu3.3]
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (disco-proposed) [0.74.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.6]
-queuebot:#ubuntu-release- New source: masakari (disco-proposed/primary) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (disco-proposed/multiverse) [10.0.130-2] (no packageset)
-queuebot:#ubuntu-release- New: rejected masakari [source] (disco-proposed) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted masakari [source] (disco-proposed) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (disco-proposed) [10.0.130-2]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (disco-proposed) [10.0.130-2]
-queuebot:#ubuntu-release- New binary: masakari [amd64] (disco-proposed/none) [7.0.0~b1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3.18.10.2]
-queuebot:#ubuntu-release- New: accepted masakari [amd64] (disco-proposed) [7.0.0~b1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [1.1ubuntu1.18.04.7~16.04.1 => 1.1ubuntu1.18.04.7~16.04.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libxcb (bionic-proposed/main) [1.13-1 => 1.13-2~ubuntu18.04] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.8 => 1.1ubuntu1.18.04.9] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lmdb (bionic-proposed/universe) [0.9.21-1 => 0.9.21-1ubuntu2~bionic18.04] (kubuntu)
-queuebot:#ubuntu-release- New binary: golang-github-codahale-hdrhistogram [amd64] (disco-proposed/none) [0.0~git20161010.3a0bb77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-yudai-golcs [amd64] (disco-proposed/none) [0.0~git20170316.ecda9a5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-crossdock-crossdock-go [amd64] (disco-proposed/none) [0.0~git20160816.049aabb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-uber-go-atomic [amd64] (disco-proposed/universe) [1.3.2+git20181018.8dc6146-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.9]
-queuebot:#ubuntu-release- New binary: vala [s390x] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (disco-proposed/universe) [0.43.90-1] (ubuntu-desktop)
<tsimonq2> infinity: So people upload to Cosmic to get things into Disco? :P
<tsimonq2> (email)
<infinity> tsimonq2: I'm the king of bad copy and paste (and an inability to proof read)
<tsimonq2> :)
<infinity> tsimonq2: Like, even after you pointed it out, and I was pretty sure you must be right, I had to re-read it three times to notice the word "cosmic" in there.
<rbasak> It's OK. I'm not sure uploading to cosmic-roposed will work anyway :)
<rbasak> My proof reading usually improves significantly only when doing it after sending/submitting.
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> This is why I reread emails an obnoxious number of times before sending them. :P
#ubuntu-release 2019-02-22
 * Laney turns off auto-sync
* Laney changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Cosmic 18.10 | Archive: FF, DIF | Disco Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
-queuebot:#ubuntu-release- New sync: servlet-api (disco-proposed/primary) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted golang-github-codahale-hdrhistogram [amd64] (disco-proposed) [0.0~git20161010.3a0bb77-1]
-queuebot:#ubuntu-release- New: accepted golang-github-uber-go-atomic [amd64] (disco-proposed) [1.3.2+git20181018.8dc6146-1]
-queuebot:#ubuntu-release- New: accepted servlet-api [sync] (disco-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New: accepted golang-github-crossdock-crossdock-go [amd64] (disco-proposed) [0.0~git20160816.049aabb-1]
-queuebot:#ubuntu-release- New: accepted vala [amd64] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New: accepted golang-github-yudai-golcs [amd64] (disco-proposed) [0.0~git20170316.ecda9a5-1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (disco-proposed) [0.43.90-1]
-queuebot:#ubuntu-release- New binary: servlet-api [amd64] (disco-proposed/universe) [4.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted servlet-api [amd64] (disco-proposed) [4.0.1-2]
<rbasak> Now that autosync is off, could an AA look at bug 1813317 pretty please.
<ubot5> bug 1813317 in php7.3 (Ubuntu) "Please remove src:php7.3 from disco" [Undecided,New] https://launchpad.net/bugs/1813317
<rbasak> We're doing some work on src:php7.2 so it'd be nice to be able to catch any issues from 7.3 removal in case it causes problems.
<rbasak> (hopefully not because they're separated dependency-wise)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
<Odd_Bloke> Does someone have a minute to look at https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 so we can get vagrant out of -proposed, please?
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
<bdmurray> xnox: Were you going to update bug 1790831?
<ubot5> bug 1790831 in Ubuntu on IBM z Systems "lstape, lsluns: handle non-zfcp; lin_tape multiple paths" [Medium,In progress] https://launchpad.net/bugs/1790831
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.6] (20190222.1) has been added
<ogra> infinity, initramfs-tools-devices looks so lonely in https://launchpad.net/ubuntu/disco/+queue ... it wants to cuddle with the other packages in the archive ...
<infinity> ogra: Maybe it should learn to love itself, then others might love it more.
<ogra> ha
 * sil2100 is fixing the ubuntu-gnome .6 builds
<sil2100> I'll also try re-running mythbuntu, since that one seemed to be more of a transient failure (in case anyone wants to test that one)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (bionic-proposed/universe) [0.11-1 => 1.0.3-0ubuntu0.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-gtk (bionic-proposed/universe) [0.11-1 => 1.0.2-0ubuntu1.1] (ubuntugnome)
-queuebot:#ubuntu-release- New source: xdg-desktop-portal-gtk (xenial-proposed/primary) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New source: xdg-desktop-portal (xenial-proposed/primary) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.6] (20190222.1) has been added
<sil2100> \o/
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.6] (20190222.1) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] has been updated (20190222.1)
<jbicha> sil2100: .6?
<jbicha> is it apt?
<juliank> autopkgtest cloud workers were broken for 10,20 mins. Sorry for the inconvenience
<infinity> jbicha: Yes, apt. :/
<juliank> infinity: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_administration, "Journal log analysis"
<juliank> journalctl ADT_PACKAGE=autopkgtest :)
<juliank> vorlon, sil2100, Laney ^ documentation for what fields we have now in the journal on the cloud worker
<juliank> Merge request: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/363546
<juliank> We might want to parse the params we get and add more useful field than stuff that json into that journal field
-queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1 => 0.22.2-1ubuntu0.1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1 => 0.23.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot-apache (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1 => 0.23.0-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: python-josepy (xenial-proposed/primary) [1.1.0-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: python-letsencrypt-apache (xenial-proposed/universe) [0.4.1-1ubuntu0.16.04.1 => 0.7.0-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-letsencrypt (xenial-proposed/universe) [0.4.1-1ubuntu0.16.04.1 => 0.7.0-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsp-api [amd64] (disco-proposed/universe) [2.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted jsp-api [amd64] (disco-proposed) [2.3.4-2]
-queuebot:#ubuntu-release- Unapproved: openssl1.0 (cosmic-proposed/main) [1.0.2n-1ubuntu6.1 => 1.0.2n-1ubuntu6.2] (core)
-queuebot:#ubuntu-release- Unapproved: openssl1.0 (bionic-proposed/main) [1.0.2n-1ubuntu5.2 => 1.0.2n-1ubuntu5.3] (core)
-queuebot:#ubuntu-release- New: rejected python-josepy [source] (xenial-proposed) [1.1.0-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: python-josepy (xenial-proposed/primary) [1.1.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-acme [source] (xenial-proposed) [0.22.2-1ubuntu0.1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1 => 0.22.2-1ubuntu0.1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-josepy [source] (xenial-proposed) [1.1.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: python-josepy [amd64] (xenial-proposed/none) [1.1.0-1~ubuntu16.04.1] (no packageset)
<LocutusOfBorg> autopkgtest [11:22:09]: ERROR: "sh -ec mkdir -p /etc/apt/preferences.d; PKGS=""; PKGS="$PKGS $(apt-cache showsrc libmarc-xml-perl | awk '/^Package-List:/ { show=1; next } (/^ / && show==1) { print $1; next } { show=0 }' |sort -u | tr '\n' ' ')"; printf "Package: $PKGS\nPin: release a=disco-proposed\nPin-Priority: 995\n" > /etc/apt/preferences.d/autopkgtest-disco-proposed; printf "
<LocutusOfBorg> Package: *\nPin: release a=disco-updates\nPin-Priority: 990\n" >> /etc/apt/preferences.d/autopkgtest-disco-proposed; " failed with stderr "E: You must put some 'source' URIs in your sources.list
<LocutusOfBorg> this looks awesome
<LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/libmarc-xml-perl/disco/arm64 <-- here
<LocutusOfBorg> also here https://autopkgtest.ubuntu.com/packages/libmarc-charset-perl/disco/ppc64el and many other places..
<infinity> LocutusOfBorg: Known, and vorlon is/was/did fixing/fix it.  Ish.
-queuebot:#ubuntu-release- Unapproved: glewmx (bionic-proposed/universe) [1.13.0-4 => 1.13.0-4ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: glewmx (cosmic-proposed/universe) [1.13.0-4 => 1.13.0-4ubuntu0.18.10.1] (no packageset)
<vorlon> yes, that's been fixed
<vorlon> but not the bug in the script that allowed the broken image to be created
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (xenial-proposed) [0.22.2-1ubuntu0.1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot [source] (xenial-proposed) [0.23.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted python-josepy [amd64] (xenial-proposed) [1.1.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot-apache [source] (xenial-proposed) [0.23.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt [source] (xenial-proposed) [0.7.0-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt-apache [source] (xenial-proposed) [0.7.0-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.6] has been disabled
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.6] has been disabled
<jbicha> (I disabled the Ubuntu GNOME 16.04.6 builds)
<LocutusOfBorg> vorlon, will you kick tests again once is fixed?
<vorlon> it's already fixed. tests already kicked.
<jbicha> please remove birdfont/s390x from disco-proposed it's correctly in depwait now
<jbicha> sorry, birdtray
<jbicha> the thunderbird thingy not the font thingy
<acheronuk> vorlon release team et al. Just a FYI so you knoe it is coming... Kubuntu would like a freeze exception for the KDE PIM (email/rss/contacts etc) stack. I will do a FFE bug in the next few days. this will be 59 source packages, which sound a lot but we have followed debian on dropping autopkgtests from most of those, so it should not be a big strain on the infra
<acheronuk> Laney: you will no doubt be pleased to hear that about the tests ^^. ~38 were nuked. I am also sorry that I have not responded to your email. recent family bereavement has meant that I have been doing a bar minimum here. I will try my best in the next few months to review what tests are useful, and which are not
<acheronuk> *bare minimum
<acheronuk> I would note that removing the PIM tests cut the amount of rdep tests generated by the last frameworks update by about 40%. If the non x86 infra had not had a network meltdown just after I uploaded, most queues would have cleared in a day or 2
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.6] has been disabled
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.6] has been disabled
<tomreyn> there are some people in #ubuntu reporting their xenial instrallations using some kind of automation are failing due to broken installers. were broken 16.04.6 builds released at some point during the past 3 days?
<Eickmeyer> tomreyn: I think I read something about that in the mailing list that there had to be a respin due to some breakages, but don't quote me on that.
<tomreyn> Eickmeyer: thanks for responding. that's ubuntu-release@lists ?
<Eickmeyer> Yes.
<jbicha> vorlon: it doesn't look like ppc64el is fixed
<tomreyn> more reports on the broken xenial mini.iso - https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1816846 - 41 people confirming so far (and i assume this bug is filed against the wrong package, should it not be "debian-installer")
<ubot5> Launchpad bug 1816846 in glibc (Ubuntu) "segfault in libc-2.23.so netinstall installation pxe" [Undecided,Confirmed]
<vorlon> jbicha: what are you seeing on ppc64el?
<jbicha> vorlon: there's lots of red on excuses, here's a result that's a little older now but still after the time you said things were fixed: https://autopkgtest.ubuntu.com/packages/g/gnome-photos/disco/ppc64el
<vorlon> ok.  I didn't realize those images had also gotten broken; I'll fix them now
<jbicha> I think s390x too but some of the s390x tests passed ð¤·
<vorlon> because s390x has two cloud regions and I only managed to break images in one of them
<jbicha> thank you
<tsimonq2> infinity, vorlon: Do I still have permission to approve/deny FFes for Kubuntu packages like last cycle?
#ubuntu-release 2019-02-23
<jbicha> ppc64el autopkgtests are still broken
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [source] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [source] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [s390x] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [ppc64el] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [amd64] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [powerpc] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [i386] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [arm64] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [armhf] (xenial-proposed/none) [1.0.3-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [amd64] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [armhf] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [powerpc] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [s390x] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [arm64] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [ppc64el] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [i386] (xenial-proposed) [1.0.3-0ubuntu0.0]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [i386] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [s390x] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [amd64] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [ppc64el] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [powerpc] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [arm64] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal-gtk [armhf] (xenial-proposed/universe) [1.0.2-0ubuntu0.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [amd64] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [armhf] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [powerpc] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [s390x] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [arm64] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [ppc64el] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal-gtk [i386] (xenial-proposed) [1.0.2-0ubuntu0.0]
-queuebot:#ubuntu-release- Unapproved: ghostscript (bionic-updates/main) [9.22~dfsg+1-0ubuntu1 => 9.26~dfsg+0-0ubuntu0.18.04.4] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ghostscript [sync] (bionic-updates) [9.26~dfsg+0-0ubuntu0.18.04.4]
<vorlon> tsimonq2: yes, I don't see a reason to change this
<vorlon> tumbleweed: are you still maintaining the reverse-depends service?  seems to be not updating for the past day or so
<vorlon> xnox: openssl1.0 removed
<ginggs> vorlon: hi, is it possible to remove pandas 0.24.0-0ubuntu1  so i can upload 0.23.3-1fakesync1ubuntu3
<ginggs> i'm not sure under what circumstances we can backtrack version numbers
<vorlon> ginggs: not today, plane doors just closed
<ginggs> ack
 * Laney is going to retry all unknown results
<Laney> done, hopefully those go better
<Odd_Bloke> Hey folks, still looking for someone to merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 to unblock Vagrant migration.
<infinity> tsimonq2: I concur with vorlon.
<bluesabre> Release team, can I get another review and merge of https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/bionic_image_size/+merge/363298 ? We're trying to reduce the daily image oversized notifications :)
#ubuntu-release 2019-02-24
<tsimonq2> infinity, vorlon: ack, thanks. Should I ask for approval every cycle or should I just assume it's policy for devel until further notice?
<tsimonq2> vorlon: Bump on that MP fixing the cdimage CSS. 18.04.2 was released with bad looking CSS on the page; I'd like to get that fixed for 16.04.6 and retroactively apply that back to 18.04.2.
<tsimonq2> https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/restore-kubuntu-lubuntu-css/+merge/358940
<tsimonq2> It looks like the CSS for 18.10's page was also moved around as well due to the flavor-agnostic includes being updated for the new CSS.
<tsimonq2> I would really like that MP merged to have something *working*, I can work on something more conformant with the look of the Ubuntu one as time comes.
<valorie> thank you, tsimonq2
<vorlon> tsimonq2: wrt CSS, what I tried to communicate when we talked last was that I am not happy to add complexity to the python code by adding more conditionals, when the right solution is for the HTML structure to be consistent between flavors and the display to be managed via css
<vorlon> tsimonq2: I'm not willing to merge this tech det
<vorlon> debt
<vorlon> lol @ failing hello autopkgtest
<vorlon> doko: seems the hello autopkgtest is an addition by you; it fails because one of the tests returns 77 instead of 0 meaning it should be skipped, but autopkgtest now runs these commands with set -e, so the testsuite fails
 * jbicha waits for the next full moon
<vorlon> gvfs autopkgtests will need updating for glibc 2.29
<vorlon> test fails now with a different error from a glibc name resolution call instead of the expected assertion
<infinity> vorlon: glibc's own failure is something I'm looking into either XFAILing or fixing (I mean, preference to the latter, but yeah) for the next upload, but not going to reupload and reset the whole mess before we migrate anything that's picked up 2.29 deps.
<vorlon> infinity: ack
<vorlon> AssertionError: 188.51403793245183 != 188.51404344898586 within 5 places
<vorlon> thanks, biopython
<ginggs> vorlon: ping re: pandas
<vorlon> ginggs: removed
<vorlon> ginggs: what's the fix you're uploading for pandas 0.23?
<ginggs> https://launchpadlibrarian.net/412461993/pandas_0.23.3-1fakesync1ubuntu3~ppa2_0.23.3-1fakesync1ubuntu3~ppa3.diff.gz
<ginggs> rebecca's patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918206#33
<ubot5> Debian bug 918206 in src:pandas "pandas: autopkgtest fails with python-numpy (1:1.16.0~rc1-3)" [Serious,Open]
<vorlon> ok then
<jbicha> vorlon: do you want to remove openssl1.0 from disco-proposed too?
<vorlon> jbicha: definitely
<vorlon> done
<ginggs> vorlon: pandas with patch passed autopkgtests https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco-ginggs-testing/disco/amd64/p/pandas/20190223_111325_a8838@/log.gz
#ubuntu-release 2020-02-17
-queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [1.2.6-0ubuntu1~18.04.2 => 1.3.3-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: containerd (eoan-proposed/universe) [1.2.10-0ubuntu1 => 1.3.3-0ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.19-0ubuntu0.16.04.1 => 9.5.21-0ubuntu0.16.04.1] (core)
<ginggs> would someone please 'force-badtest psi4/1:1.3.2-3build1/i386' ?
-queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (eoan-proposed) [1.1.12+dfsg1-0ubuntu3~19.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (bionic-proposed) [1.1.12+dfsg1-0ubuntu3~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (xenial-proposed) [1.1.12+dfsg1-0ubuntu3~16.04.0]
<ahasenack> hi release team, haproxy isn't being built for i386, could its dep8/i386 tests be hinted please?
<ahasenack> https://launchpad.net/ubuntu/+source/haproxy/2.0.13-1ubuntu2
<ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.13 => 1.1ubuntu1.18.04.14] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (trusty-proposed/main) [0.82.1ubuntu2.5 => 0.82.1ubuntu2.6] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (eoan-proposed/main) [1.14ubuntu1.1 => 1.14ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [1.1ubuntu1.18.04.7~16.04.5 => 1.1ubuntu1.18.04.7~16.04.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New source: wireguard-linux-compat (eoan-proposed/primary) [0.0.20200205-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [0.0.20190913-1ubuntu1 => 1.0.20200206-1ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rtl8821ce (eoan-proposed/universe) [5.5.2.1-0ubuntu1~19.10.1 => 5.5.2.1-0ubuntu3~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rtl8821ce (bionic-proposed/universe) [5.5.2.1-0ubuntu1~18.04.1 => 5.5.2.1-0ubuntu3~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: php-guzzlehttp-promises (focal-proposed/primary) [1.3.1-2]
<seb128> http://autopkgtest.ubuntu.com/packages/o/openscad/focal/s390x should probably marked to skip/badtest since it regressed with the new mesa and isn't an issue in proposed
<seb128> tjaalton, ^ did you discuss that?
<seb128> vorlon, ^ pinging since you rebuilt it for a transition so you probably want to see it unblocked
<vorlon> seb128: thanks, hint bumped
<vorlon> also the hint says to hassle tjaalton when bumping the hint, about the upstream fix
<LocutusOfBorg> vorlon, is it possible to hint haproxy/i386 and libapache2-mod-perl2/i386 please?
<LocutusOfBorg> xnox, are you looking at hilive/arm64 to make boost candidate? it regressed in release, not sure if worth an hint or a fix...
<LocutusOfBorg> or maybe it should be moved to a machine with more ram
<xnox> LocutusOfBorg:  i'm looking into both boost and icu yes, but it is a bit tedious. But slowly making progress on both.
<LocutusOfBorg> xnox, I'm helping here and there since I want to do ocaml after them :)
<LocutusOfBorg> let me know if I can do anything, right now I'm picking random failures and fixing them
<LocutusOfBorg> e.g. I will do taglib now
<LocutusOfBorg> oh, already done
<xnox> LocutusOfBorg:  random is good =)
<xnox> LocutusOfBorg:  you are working off the transition trackers right?
<LocutusOfBorg> yes!
<xnox> cool cool
<LocutusOfBorg> for some reasons looks like hilive in my localhost arm64 chroot is hanging too
<LocutusOfBorg> or maybe it needs some more time, because of qemu foo
<rbalint> sil2100, could you please check the unatended-upgrades sru uploads in unapproved?
<sil2100> rbalint: o/
<LocutusOfBorg> also pacemaker/i386 needs an help...
<LocutusOfBorg> needs a bump of the hint ^^
<sil2100> rbalint: hm, what is the actual test-case for the u-u ESM changes?
<sil2100> rbalint: I assume it requires some special permissions?
<sil2100> rbalint: I guess we'll anyway have to have the 'right' someone testing that, so let me proceed and accept
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (eoan-proposed) [1.14ubuntu1.2]
<rbalint> sil2100, thanks!
<rbalint> sil2100, a simpler test case would be just observing the list of allowed origins, but it the bug reporter verifies if the pockets actually work, it is just better imo
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.14]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu1.18.04.7~16.04.6]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-89.89] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-175.205] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: quassel (xenial-proposed/universe) [0.12.2-0ubuntu1 => 0.12.2-0ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: quassel (bionic-proposed/universe) [1:0.12.4-3ubuntu1 => 1:0.12.4-3ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: quassel (eoan-proposed/universe) [1:0.13.1-1ubuntu1 => 1:0.13.1-1ubuntu1.19.10.1] (kubuntu)
<RikMills> vorlon: could you please bump or otherise amend the pyside2 hint? that baseline reset is not working well now there has been a new upload which got some 'neutral' test results :/
<vorlon> RikMills: 'neutral'->'fail' should be considered a regression, and there should be a justification for overriding.  Do you know why the tests are failing looking for python3.7, when 4 days prior they were failing looking for python3.8?
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-89.89] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-175.205]
<RikMills> vorlon: presumably the python3 defaults migration caused that switch
<RikMills> i.e. failing to find X-Python3-Version, it is falling back to the default python which is now 3.8
<RikMills> I guess py3versions must be returning both, and the one not found has now switched
<RikMills> yeah, it a chroot with test deps, that seems to be the case
<RikMills> *in a
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-89.89]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-89.89]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
<tjaalton> seb128, vorlon: upstream 20.0rc has a revert in it that might fix it. i'll push that to focal later this week when i'm back
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-41.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-41.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-41.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-41.33]
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (eoan-proposed) [1.3.3-0ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (bionic-proposed) [1.3.3-0ubuntu1~18.04.1]
<mwhudson> bdmurray: thanks
<bdmurray> mwhudson: no problem
<mwhudson> sigh i wish launchpad tracked rebuild attempts
-queuebot:#ubuntu-release- New binary: wcslib [amd64] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wcslib [s390x] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1033.35] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1014.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1073.83] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1013.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: wcslib [arm64] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wcslib [armhf] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wcslib [ppc64el] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
#ubuntu-release 2020-02-18
-queuebot:#ubuntu-release- New: accepted wcslib [armhf] (focal-proposed) [7.1+ds-2]
-queuebot:#ubuntu-release- New: accepted wcslib [ppc64el] (focal-proposed) [7.1+ds-2]
-queuebot:#ubuntu-release- New: accepted rhinote [amd64] (focal-proposed) [0.7.4-4]
-queuebot:#ubuntu-release- New: accepted wcslib [arm64] (focal-proposed) [7.1+ds-2]
-queuebot:#ubuntu-release- New: accepted wcslib [amd64] (focal-proposed) [7.1+ds-2]
-queuebot:#ubuntu-release- New: accepted wcslib [s390x] (focal-proposed) [7.1+ds-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1014.15]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1013.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1033.35]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1073.83]
<ginggs> would someone please 'force-badtest ruby-declarative/0.0.10-1' ?  it seems to have regressed in release
<locutus_> doko, can you please try to accept php-guzzlehttp-promises from queue? it is needed for symfony, but I don't know if the mismatched tarball will be ok or not...
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-41.33~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-41.33~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-41.33~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-41.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-41.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-41.33~18.04.1]
<ahasenack> hi release team, the mysql8 tests seem to take too long in arm* and hit a timeout: http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64 and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/m/mysql-8.0/20200218_060750_f411f@/log.gz
<ahasenack> what's the solution here?
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1010.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: lighttpd [s390x] (focal-proposed/universe) [1.4.54-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lighttpd [amd64] (focal-proposed/universe) [1.4.54-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1010.11]
-queuebot:#ubuntu-release- New binary: lighttpd [arm64] (focal-proposed/universe) [1.4.54-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lighttpd [armhf] (focal-proposed/universe) [1.4.54-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mod-wsgi (bionic-proposed/main) [4.5.17-1 => 4.5.17-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mod-wsgi (xenial-proposed/main) [4.3.0-1.1build1 => 4.3.0-1.1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted lighttpd [amd64] (focal-proposed) [1.4.54-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted lighttpd [armhf] (focal-proposed) [1.4.54-2ubuntu1]
-queuebot:#ubuntu-release- New: rejected php-guzzlehttp-promises [sync] (focal-proposed) [1.3.1-2]
-queuebot:#ubuntu-release- New: accepted lighttpd [arm64] (focal-proposed) [1.4.54-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pygobject-2 [amd64] (focal-proposed) [2.28.6-14ubuntu1]
-queuebot:#ubuntu-release- New: accepted lighttpd [s390x] (focal-proposed) [1.4.54-2ubuntu1]
-queuebot:#ubuntu-release- New binary: pyprof2calltree [amd64] (focal-proposed/universe) [1.4.4-2] (no packageset)
<ginggs> would someone please 'force-badtest ruby-declarative/0.0.10-1' ?  it seems to have regressed in release
<ginggs> would someone please 'force-badtest psi4/1:1.3.2-3build1/i386' ?
<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
<doko> once that migrates, everything is tested with 3.8 only
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-89.89~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-89.89~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-89.89~16.04.1] (kernel)
<vorlon> ginggs: psi4/all/i386 badtested, sorry for missing it before
<ginggs> vorlon: thanks!
<vorlon> and hinting ruby-declarative now also
<vorlon> doko: I'm not sure what you're asking for wrt python3-defaults ignoring.  The tests seem to be mostly passing, are you asking to not wait for test results?
<doko> vorlon: ys
<vorlon> doko: should we also dump the tests from the queue, so that they're not clogging up the runners running tests whose results we don't care about?
<doko> we'll have a python3-defaults version bump anyway later, so we'll re-run these tests
<doko> yes, dump these would be fine
<vorlon> doko: and what's the impact to other reverse-dependencies that are not python3-defaults by letting this in?  I think you mentioned some packages with tests now failing when dropping python3.7 from supported?
<vorlon> so if we don't track those down now there will be knock-on effects for other things migrating
<vorlon> (not necessarily a blocker, I just want to be completely clear about the impact)
<doko> these would be triggered by the packages itself, not passing their own autopkg tests
<vorlon> or by other dependencies of those packages
<doko> but again, I'm fine to re-upload python3-defaults, once the package migrated
<doko> or wait for the version bump
<vorlon> ok
<doko> 3.8.3 will be next week, or the next week
<doko> 2.8.2 even
<doko> 3.8.2 even
<vorlon> ok, sounds like a plan then
<doko> vorlon: ok what? upload immediatly or after the version bump?
<vorlon> doko: are you suggesting a second upload *just* to re-trigger the tests?  Please not that
<doko> vorlon: as long as you're ok to do that with the version bumo, no.
<doko> bump
<vorlon> doko: yeah, if there's another upload coming anyway next week, please don't do a reupload just for this
<doko> sure
<vorlon> Laney: so I see you reset-test'ed colord/i386, which is fine, but I've been unable to reproduce the failure locally
<ddstreet> infinity lp shows Disco as still 'supported', is that intentional for some reason, or just not updated yet? https://launchpad.net/ubuntu/disco/
<vorlon> ddstreet: there is some cleanup yet to be done before we can close the archive in launchpad; infinity and apw know the details
<apw> vorlon: cleaning NBS as far as I recall
<apw> particularly of kernels which are huge
<vorlon> apw: and did you or infinity do any particular work on scripting this?  Should I jfdi :)
<apw> vorlon: I never actually did it, not could I say for sure that is the extent of it
<vorlon> well NBS removals are slow
<vorlon> but the scripting shouldn't be difficult
<seb128> vorlon, @colord, the test depends on gnome-session which isn't build anymore on i386, how can it work for you?
<vorlon> seb128: gnome-session is arch: all so would be /expected/ to be cross-installed, except it doesn't have the Multi-Arch: foreign flag set, so it /wouldn't/ install, so I really have no idea how it's working locally
<seb128> vorlon, hum, I wonder if gnome-session arch:all is buggy, it deoends on gnome-session-bin which is an arch: any binary from the same source
<seb128> or at least not compatible with a partial archive right?
<vorlon> seb128: I suspect that gnome-session being declared Multi-Arch: foreign is probably fine because all the "interfaces" that gnome-session provides to its reverse-dependencies involve an exec() barrier; but it's also not hugely important
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-89.89~16.04.1]
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (focal-proposed/universe) [4.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [amd64] (focal-proposed/universe) [2.0.0-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (focal-proposed/universe) [4.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (focal-proposed/universe) [4.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (focal-proposed/universe) [4.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (focal-proposed/universe) [4.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [arm64] (focal-proposed/universe) [2.0.0-1] (ubuntukylin)
#ubuntu-release 2020-02-19
<infinity> vorlon: It's not just about scripting, there's also some manual surgery I've been carefully doing do to custom uploads going severely wonky when a batch of kernels was rolled back right before EOL.  I'll get it all sorted Very Soon, promise.
<infinity> vorlon: (In fact, due to said wonkiness, any attempt to script it leads to scripts trying to remove the *current* kernel, which is a bit lolz)
<infinity> Though I'm sure some error checking there relating to checking if a pub is active before declaring it old would fix that. :P
-queuebot:#ubuntu-release- Unapproved: runc (eoan-proposed/universe) [1.0.0~rc8+git20190923.3e425f80-0ubuntu1 => 1.0.0~rc10-0ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (bionic-proposed/universe) [1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2 => 1.0.0~rc10-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (eoan-proposed/universe) [19.03.2-0ubuntu1 => 19.03.6-0ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.09.7-0ubuntu1~18.04.4 => 19.03.6-0ubuntu1~18.04.1] (no packageset)
<mwhudson> that runc in UNAPPROVED fixes a CVE if anyone is interested :)
-queuebot:#ubuntu-release- New: accepted peony [amd64] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pyprof2calltree [amd64] (focal-proposed) [1.4.4-2]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (focal-proposed) [4.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (focal-proposed) [4.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peony [arm64] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (focal-proposed) [4.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (focal-proposed) [4.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (focal-proposed) [4.2.1+dfsg-1]
<amurray> mwhudson: is that CVE-2019-19921 by any chance?
<mwhudson> amurray: er probably
<mwhudson> amurray: https://launchpadlibrarian.net/465601088/runc_1.0.0~rc10-0ubuntu1~18.04.1_source.changes <- yes :)
-queuebot:#ubuntu-release- New binary: gr-limesdr [amd64] (focal-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [s390x] (focal-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [ppc64el] (focal-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [arm64] (focal-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gr-limesdr [armhf] (focal-proposed/universe) [3.0.1-2] (no packageset)
<amurray> mwhudson: cheers
<mwhudson> amurray: apparently someone in security will copy it into -security when it's been through the sru process
<amurray> mwhudson: could you please add us to the SRU bug so we don't forget?
<mwhudson> amurray: ~ubuntu-security?
<amurray> mwhudson: yes thanks
<mwhudson> amurray: done
-queuebot:#ubuntu-release- New binary: python-cogent [amd64] (focal-proposed/universe) [2020.2.7a+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [s390x] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [ppc64el] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2-cutter [amd64] (focal-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [armhf] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [arm64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [amd64] (focal-proposed/universe) [2.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2-cutter [armhf] (focal-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected rtl8821ce [source] (bionic-proposed) [5.5.2.1-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rtl8821ce (bionic-proposed/universe) [5.5.2.1-0ubuntu1~18.04.1 => 5.5.2.1-0ubuntu3~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2-cutter [arm64] (focal-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rtl8821ce (eoan-proposed/universe) [5.5.2.1-0ubuntu1~19.10.1 => 5.5.2.1-0ubuntu3~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected rtl8821ce [source] (eoan-proposed) [5.5.2.1-0ubuntu3~19.10.1]
-queuebot:#ubuntu-release- Unapproved: mesa (eoan-proposed/main) [19.2.8-0ubuntu0~19.10.2 => 19.2.8-0ubuntu0~19.10.3] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.2.8-0ubuntu0~18.04.2 => 19.2.8-0ubuntu0~18.04.3] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (eoan-proposed) [19.2.8-0ubuntu0~19.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.2.8-0ubuntu0~18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted rtl8821ce [source] (eoan-proposed) [5.5.2.1-0ubuntu3~19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted rtl8821ce [source] (bionic-proposed) [5.5.2.1-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [amd64] (focal-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [armhf] (focal-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [s390x] (focal-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [arm64] (focal-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gr-limesdr [ppc64el] (focal-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted python-cogent [amd64] (focal-proposed) [2020.2.7a+dfsg-1]
-queuebot:#ubuntu-release- New: accepted volk [amd64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted volk [armhf] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted volk [s390x] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted volk [arm64] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted volk [ppc64el] (focal-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted radare2-cutter [amd64] (focal-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted radare2-cutter [armhf] (focal-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted radare2-cutter [arm64] (focal-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New source: php-guzzlehttp-promises (focal-proposed/primary) [1.3.1-2ubuntu1]
<locutus_> doko, ^^ that one should be ok to accept
<locutus_> sigh, mismatching tarballs
-queuebot:#ubuntu-release- New binary: libfprint [amd64] (focal-proposed/main) [1:1.90.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [ppc64el] (focal-proposed/main) [1:1.90.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [arm64] (focal-proposed/main) [1:1.90.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [armhf] (focal-proposed/main) [1:1.90.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: ldc [amd64] (focal-proposed/universe) [1:1.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [arm64] (focal-proposed/universe) [1:1.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [armhf] (focal-proposed/universe) [1:1.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpegfs [s390x] (focal-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpegfs [amd64] (focal-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpegfs [ppc64el] (focal-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpegfs [arm64] (focal-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffmpegfs [armhf] (focal-proposed/universe) [1.10-1] (no packageset)
<mitya57> Hi! Repeating myself from 2020-02-11:
<mitya57> qtlocation-opensource-src fails to migrate because âmissing build on i386â. However it now has new build-dependencies which are not in i386 whitelist:
<mitya57> https://salsa.debian.org/qt-kde-team/qt/qtlocation/commit/a7ef4609bb54ee82
<mitya57> Please either add them to whitelist, or remove qtlocation.
-queuebot:#ubuntu-release- New binary: gnuradio [amd64] (focal-proposed/universe) [3.8.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuradio [s390x] (focal-proposed/universe) [3.8.1.0~rc1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ffmpegfs [amd64] (focal-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted ffmpegfs [armhf] (focal-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted ffmpegfs [s390x] (focal-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted ffmpegfs [arm64] (focal-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted ffmpegfs [ppc64el] (focal-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted gnuradio [amd64] (focal-proposed) [3.8.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (focal-proposed) [1:1.20.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (focal-proposed) [1:1.20.0-1]
-queuebot:#ubuntu-release- New: accepted libfprint [arm64] (focal-proposed) [1:1.90.1-1]
-queuebot:#ubuntu-release- New: accepted libfprint [ppc64el] (focal-proposed) [1:1.90.1-1]
-queuebot:#ubuntu-release- New: accepted gnuradio [s390x] (focal-proposed) [3.8.1.0~rc1-2]
-queuebot:#ubuntu-release- New: accepted libfprint [amd64] (focal-proposed) [1:1.90.1-1]
-queuebot:#ubuntu-release- New: accepted ldc [arm64] (focal-proposed) [1:1.20.0-1]
-queuebot:#ubuntu-release- New: accepted libfprint [armhf] (focal-proposed) [1:1.90.1-1]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.42.1 => 2.43.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.42.1+18.04 => 2.43.3+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.42.1+19.04 => 2.43.3+19.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (eoan-proposed/main) [2.42.1+19.10 => 2.43.3+19.10] (core)
-queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.6-1ubuntu3.1 => 3.9-1ubuntu0.19.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1032.33] (kernel)
<LocutusOfBorg> any AA: please blacklist ghc autosync, thanks (debian is talking to put 8.8.2 in sid)
<cjwatson> LocutusOfBorg: done (https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/revision/723)
<slashd> Hi SRU folks, can you please reject my upload for sosreport in Eoan. I'll re-upload later this week, need to add last minute changes.
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (eoan-proposed) [3.9-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- New: accepted php-guzzlehttp-promises [source] (focal-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New binary: php-guzzlehttp-promises [amd64] (focal-proposed/universe) [1.3.1-2ubuntu1] (no packageset)
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- New source: python-edgegrid (focal-proposed/primary) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1032.33]
<LocutusOfBorg> any AA Around please? https://bugs.debian.org/938608 https://bugs.launchpad.net/ubuntu/+source/svn-workbench/+bug/1863931
<ubot5> Debian bug 938608 in ftp.debian.org "RM: svn-workbench -- RoQA; dead upstream; low popcon; blocking py2 removal" [Serious,Open]
<ubot5> Ubuntu bug 1863931 in svn-workbench (Ubuntu) "please remove svn-workbench from focal" [Undecided,New]
<LocutusOfBorg> kick that package out
<xnox> please RM source-highlight 3.1.9-1build1 from focal-proposed, it ftbfs in both debian & ubuntu, and the 3.1.8 that we have in focal-release is better.
-queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (eoan-proposed) [1.0.20200206-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [0.0.20190913-1ubuntu1 => 1.0.20200206-1ubuntu1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- New: rejected wireguard-linux-compat [source] (eoan-proposed) [0.0.20200205-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New source: wireguard-linux-compat (eoan-proposed/primary) [0.0.20200205-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New: accepted wireguard-linux-compat [source] (eoan-proposed) [0.0.20200205-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (eoan-proposed) [1.0.20200206-1ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1014.15~18.04.1] (no packageset)
#ubuntu-release 2020-02-20
-queuebot:#ubuntu-release- New binary: python-jenkinsapi [amd64] (focal-proposed/universe) [0.3.11-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: drmaa [amd64] (focal-proposed/universe) [0.7.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swig [i386] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: swig [ppc64el] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: swig [amd64] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: swig [arm64] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: swig [s390x] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: swig [armhf] (focal-proposed/universe) [4.0.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: nipy [amd64] (focal-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: nipy [s390x] (focal-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: nipy [ppc64el] (focal-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: alsa-lib (bionic-proposed/main) [1.1.3-5ubuntu0.3 => 1.1.3-5ubuntu0.4] (core)
-queuebot:#ubuntu-release- Unapproved: alsa-lib (eoan-proposed/main) [1.1.9-0ubuntu1.1 => 1.1.9-0ubuntu1.2] (core)
-queuebot:#ubuntu-release- New binary: nipy [armhf] (focal-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: nipy [arm64] (focal-proposed/universe) [0.4.2-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted drmaa [amd64] (focal-proposed) [0.7.9-1]
-queuebot:#ubuntu-release- New: accepted nipy [arm64] (focal-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted nipy [ppc64el] (focal-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted php-guzzlehttp-promises [amd64] (focal-proposed) [1.3.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted swig [amd64] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted swig [armhf] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted swig [ppc64el] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted nipy [amd64] (focal-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted nipy [s390x] (focal-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted swig [arm64] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted swig [s390x] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted nipy [armhf] (focal-proposed) [0.4.2-3]
-queuebot:#ubuntu-release- New: accepted swig [i386] (focal-proposed) [4.0.1-2]
-queuebot:#ubuntu-release- New: accepted python-jenkinsapi [amd64] (focal-proposed) [0.3.11-1ubuntu1]
<xnox> sil2100:  please RM source-highlight 3.1.9-1build1 from focal-proposed, it ftbfs in both debian & ubuntu, and the 3.1.8 that we have in focal-release is better. Then i will do no change rebuild of 3.1.8 and it will help with icu transition.
<xnox> reason "ftbfs"
<sil2100> One moment o/
<sil2100> xnox: ok, on it now
<sil2100> xnox: done
<handsome_feng> Hi, Could someone help to deal with the removal: #1863109? Thanks!
<handsome_feng> LP: #1863109
<ubot5> Launchpad bug 1863109 in ukui-indicators (Ubuntu) "Please remove ukui-indicators from focal" [Undecided,New] https://launchpad.net/bugs/1863109
<Kamilion> teward: on contemplating the nginx ipv6 issue in #1743592 I think I came up with useful defaults for all. Please have a look before committing to reverting "tomorrow". Thanks!
-queuebot:#ubuntu-release- New binary: octavia [amd64] (focal-proposed/universe) [6.0.0~b2~git2020020614.005cd1e6-0ubuntu2] (no packageset)
<mfo> sil2100, hi Lukasz!  If you have a chance, could you please review mod-wsgi in the upload queue for bionic/xenial?  Thanks in advance!
-queuebot:#ubuntu-release- New: accepted octavia [amd64] (focal-proposed) [6.0.0~b2~git2020020614.005cd1e6-0ubuntu2]
<sil2100> mfo: on it o/
<sil2100> handsome_feng: I'll try to look into it shortly
 * sil2100 just needs to finish up some stuff
<mfo> sil2100, thanks!
<handsome_feng> sil2100, thanks! +1 :)
-queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (bionic-proposed) [4.5.17-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1040.45] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1014.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1040.45]
<sil2100> mfo, handsome_feng: both done o/
-queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (xenial-proposed) [4.3.0-1.1ubuntu1]
<mfo> sil2100, ack, thanks for the prompt review, Lukasz!
<handsome_feng> sil2100, thank you! \o/
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1013.14~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1013.14~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1053.56] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1013.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1013.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1053.56]
<teward> Kamilion: better place to have that discussion than 'here'.
<teward> needs also Server Team input
-queuebot:#ubuntu-release- Unapproved: procps (xenial-proposed/main) [2:3.3.10-4ubuntu2.4 => 2:3.3.10-4ubuntu2.5] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/main) [2.38~14.04 => 2.43.3~14.04] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1072.77] (kernel)
<vorlon> python3.7 (3.7.6-1ubuntu3) focal; urgency=medium
<vorlon>   * No-change rebuild to drop python3.7.
<vorlon> huh why didn't that work
<vorlon> doko: and I guess you wouldn't like me to zero out my TIL merges by merging ruby-defaults right now ;)
<xnox> vorlon:  server team is doing the ruby transition, so you should consider your TIL stolen on it.
<xnox> vorlon:  or like check with powersj
<doko> yeah, I missed that upload. sorry
<doko> vorlon: just go ahead
-queuebot:#ubuntu-release- Unapproved: landscape-client (eoan-proposed/main) [18.01-0ubuntu9.1 => 18.01-0ubuntu9.2] (ubuntu-server)
<doko> stage1 rebuilds are finished in Debian, and stage2 rebuilds are running
<doko> kanashiro: ^^^
-queuebot:#ubuntu-release- Unapproved: landscape-client (bionic-proposed/main) [18.01-0ubuntu3.4 => 18.01-0ubuntu3.5] (ubuntu-server)
<ahasenack> hi, I need some help/guidance with these mysql8 tests on arm64:  http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64
<ahasenack> looks like they just take too long, and get killed
<ahasenack> the closest I got to the finish line was 97%
<ahasenack> I do see some green ones that took longer and passed, though, so I'm not 100% sure it's just a timeout
<ahasenack> maybe there is an inactivity check?
-queuebot:#ubuntu-release- Unapproved: util-linux (eoan-proposed/main) [2.34-0.1ubuntu2.2 => 2.34-0.1ubuntu2.3] (core)
<ahasenack> I filed https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
<kanashiro> re ruby 2.7 transition: I have a ruby-defaults package in my ppa with only ruby2.7 enabled, I am working to fix stuff on the Debian side and we are planning to upload the new ruby-defaults on Monday. Is that ok?
<kanashiro> btw I am applying and uploading the delta vorlon added to ruby-defaults to Debian, so it can become a sync again
<blackboxsw> rbalint: are we expecting a apt Allowed Origins fix for trusty uploaded too?  Regarding: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051
<ubot5> Ubuntu bug 1857051 in unattended-upgrades (Ubuntu Trusty) "Please add ${distro_id}ESM:${distro_codename}-infra-security and ${distro_id}ESMApps:${distro_codename}-apps-security to allowed origins (on Ubuntu)" [Undecided,New]
<blackboxsw> I've completed SRU verification for xenial, bionic, eoan on this, but it's missing the trusty series upload
<blackboxsw> and that's not a good time to try to get ahold of him :/ sending email
<vorlon> kanashiro: sounds good to me, thanks
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1056.60] (kernel)
<wxl> lubuntu's daily failed and it seems to be an issue with qtermwidget-l10n but it's unclear exactly what. any ideas on how i can get more info? https://launchpadlibrarian.net/465846401/buildlog_ubuntu_focal_amd64_lubuntu_BUILDING.txt.gz
<sarnold> wow you're not kidding :) that's pretty cryptic
<wxl> i'm glad i'm not alone in that interpretation
<wxl> perhaps i should just try a rebuild and see what happens
<TJ-> wxl: it seems pretty obvious: " trying to overwrite '/usr/share/qtermwidget5/translations/qtermwidget_ca.qm', which is also in package qtermwidget5-data 0.14.1-2"
<wxl> ah didn't see that up there
<wxl> thanks for pointing out the literally obvious TJ- :)
<sarnold> hah
-queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.6-1ubuntu0.18.04.4 => 3.9-1ubuntu0.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (eoan-proposed/main) [3.6-1ubuntu3.1 => 3.9-1ubuntu0.19.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1072.77]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1056.60]
<xnox> ocaml transition in progress
<vorlon> doko: I tried to fix gringo's hard-coding of python3.7, and then it ftbfs in basically the same way as gcc-python-plugin, with an error about PyTypeObject.  Do you have a reference to what's changed in PyTypeObject between 3.7 and 3.8?  Because the compiler error messages are rather opaque about which of the 800 elements of the struct are triggering this
-queuebot:#ubuntu-release- New binary: rust-sval-derive [amd64] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sval-derive [s390x] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sval-derive [arm64] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sval-derive [armhf] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sval-derive [ppc64el] (focal-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1031.32] (kernel)
<tumbleweed> vorlon: the relevant change looks like https://www.python.org/dev/peps/pep-0590/
#ubuntu-release 2020-02-21
<wxl> unfortunately it seems like the auto sync robot is misbehaving or something because the last sync of qtermwidget seems to have just obliterated the entire ubuntu history from the changelog https://launchpadlibrarian.net/465792741/qtermwidget_0.14.1-0ubuntu3_0.14.1-2.diff.gz
<wxl> no wonder it's broken :/
<wxl> and if that's the way it's supposed to be it doesn't explain why when building the livefs, it was trying to install qtermwidget-l10n which was effectively blasted away by that change
<wxl> oh i see it was trying to install qtermwidget-l10n 0.14.1-0ubuntu3 but qtermwidget5-data 0.14.1-2 even though they're the same source package â¦ what. the. smurf.
<vorlon> wxl: that wasn't an autosync, I synced it manually because I didn't see anything in the diff that seemed like it warranted keeping.  What exactly is broken?
<vorlon> wxl: ah - qtermidget-l10n was NBS after the sync, and I've removed it now, so I think the next build should be fine
<vorlon> tumbleweed: thanks for the ref
<kc2bez> vorlon: I triggered an iso rebuild. I don't know if that happened before or after your removal but it seemed to build fine.
-queuebot:#ubuntu-release- New binary: ocaml-num [ppc64el] (focal-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-num [amd64] (focal-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-num [s390x] (focal-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-num [arm64] (focal-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-num [armhf] (focal-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-num [arm64] (focal-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ocaml-num [s390x] (focal-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ocaml-num [armhf] (focal-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ocaml-num [amd64] (focal-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-sval-derive [amd64] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sval-derive [armhf] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sval-derive [s390x] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-num [ppc64el] (focal-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-sval-derive [ppc64el] (focal-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sval-derive [arm64] (focal-proposed) [0.5.0-1]
<handsome_feng> Hi, peony-extensions' migration is blocked due to missing build on i386, could someone help to deal with this? Thanks!
-queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.1-1ubuntu1.4 => 1.16.1-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ecasound [amd64] (focal-proposed/universe) [2.9.3-2] (no packageset)
<vorlon> handsome_feng: peony-extensions-common removed on i386 from the release pocket
-queuebot:#ubuntu-release- New: accepted ecasound [amd64] (focal-proposed) [2.9.3-2]
<handsome_feng> vorlon, Thank you!
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1031.32]
-queuebot:#ubuntu-release- New binary: ocaml-fmt [amd64] (focal-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-fmt [ppc64el] (focal-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-fields-conv [armhf] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-variants-conv [armhf] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-compare [armhf] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-fields-conv [amd64] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-fmt [s390x] (focal-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-variants-conv [amd64] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-compare [amd64] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-fmt [armhf] (focal-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-fields-conv [ppc64el] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-compare [ppc64el] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-variants-conv [ppc64el] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-fmt [arm64] (focal-proposed/universe) [0.8.8-1] (no packageset)
<rbalint> blackboxsw, i've uploaded the trusty fix, too: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=
<rbalint> blackboxsw, and pinged security, too
<rbalint> blackboxsw, i was advised to ping security with ESM upload matters, but IMO ESM upload process should also documented on https://wiki.ubuntu.com/StableReleaseUpdates
-queuebot:#ubuntu-release- New binary: ppx-compare [s390x] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-variants-conv [s390x] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-fields-conv [s390x] (focal-proposed/universe) [0.13.0-2] (no packageset)
<rbalint> sil2100, i saw a few packages getting uploaded via the trusty unapproved queue (how) are they processed?
-queuebot:#ubuntu-release- New binary: ppx-compare [arm64] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-fields-conv [arm64] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-variants-conv [arm64] (focal-proposed/universe) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: botch [s390x] (focal-proposed/universe) [0.22-2] (no packageset)
<rbalint> tjaalton, do you know how trusty unapproved queues are processed?
<rbalint> tjaalton, well, the only one
<tjaalton> how?
<rbalint> tjaalton, this is what i'd like to know :-)
<rbalint> tjaalton, i saw a few packages going through https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text= and i'd like to get unattended-upgrades accepted
<tjaalton> it's extended lts
<tjaalton> I've never touched it iirc..
<sil2100> tjaalton: I think the only exception for trusty is ubuntu-advantage-tools
<rbalint> tjaalton, ok, but who can/should?
<sil2100> rbalint: ^
<rbalint> sil2100, u-u has a fix in that area
<rbalint> sil2100, or should the change go to ubuntu-advantage-tools instead?
<sil2100> rbalint: I'd assume you could try poking the security team about that
<rbalint> sil2100, i did, then i poke them again
<rbalint> sil2100, having and extended https://wiki.ubuntu.com/StableReleaseUpdates page for extended lts would be nice
<rbalint> sil2100, i'll update it when i figured out the process
-queuebot:#ubuntu-release- New: accepted botch [s390x] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted ocaml-fmt [arm64] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted ocaml-fmt [ppc64el] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted ppx-compare [amd64] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-compare [armhf] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-compare [s390x] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-fields-conv [arm64] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-fields-conv [ppc64el] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-variants-conv [amd64] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-variants-conv [armhf] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ocaml-fmt [amd64] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted ocaml-fmt [s390x] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted ppx-compare [ppc64el] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-fields-conv [armhf] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-variants-conv [arm64] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-variants-conv [s390x] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ocaml-fmt [armhf] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted ppx-fields-conv [amd64] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-variants-conv [ppc64el] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New: accepted ppx-compare [arm64] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-fields-conv [s390x] (focal-proposed) [0.13.0-2]
-queuebot:#ubuntu-release- New binary: botch [amd64] (focal-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted botch [amd64] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New binary: lwt-log [amd64] (focal-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lwt-log [ppc64el] (focal-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lwt-log [arm64] (focal-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lwt-log [s390x] (focal-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lwt-log [armhf] (focal-proposed/universe) [1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: botch [ppc64el] (focal-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted botch [ppc64el] (focal-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted lwt-log [arm64] (focal-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New: accepted lwt-log [ppc64el] (focal-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New: accepted lwt-log [amd64] (focal-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New: accepted lwt-log [s390x] (focal-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New: accepted lwt-log [armhf] (focal-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- New binary: ppx-custom-printf [amd64] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-custom-printf [s390x] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-custom-printf [ppc64el] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-domain-name [amd64] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-domain-name [s390x] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: obus [amd64] (focal-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-domain-name [ppc64el] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: obus [s390x] (focal-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-custom-printf [armhf] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppx-custom-printf [arm64] (focal-proposed/universe) [0.13.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: obus [ppc64el] (focal-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-domain-name [arm64] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-domain-name [armhf] (focal-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted obus [amd64] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted obus [s390x] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-domain-name [arm64] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-domain-name [ppc64el] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-custom-printf [amd64] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-custom-printf [armhf] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-custom-printf [s390x] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted obus [ppc64el] (focal-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-domain-name [armhf] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-custom-printf [arm64] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-domain-name [amd64] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ppx-custom-printf [ppc64el] (focal-proposed) [0.13.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-domain-name [s390x] (focal-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New binary: ocaml-ipaddr [s390x] (focal-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ipaddr [amd64] (focal-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ipaddr [ppc64el] (focal-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New source: oem-qemu-meta (focal-proposed/primary) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: ocaml-ipaddr [arm64] (focal-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: js-of-ocaml [s390x] (focal-proposed/universe) [3.5.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: js-of-ocaml [ppc64el] (focal-proposed/universe) [3.5.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ipaddr [armhf] (focal-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: js-of-ocaml [amd64] (focal-proposed/universe) [3.5.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: js-of-ocaml [armhf] (focal-proposed/universe) [3.5.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: js-of-ocaml [arm64] (focal-proposed/universe) [3.5.2-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted js-of-ocaml [amd64] (focal-proposed) [3.5.2-3]
-queuebot:#ubuntu-release- New: accepted js-of-ocaml [armhf] (focal-proposed) [3.5.2-3]
-queuebot:#ubuntu-release- New: accepted js-of-ocaml [s390x] (focal-proposed) [3.5.2-3]
-queuebot:#ubuntu-release- New: accepted ocaml-ipaddr [arm64] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ipaddr [ppc64el] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted js-of-ocaml [arm64] (focal-proposed) [3.5.2-3]
-queuebot:#ubuntu-release- New: accepted ocaml-ipaddr [amd64] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ipaddr [s390x] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted js-of-ocaml [ppc64el] (focal-proposed) [3.5.2-3]
-queuebot:#ubuntu-release- New: accepted ocaml-ipaddr [armhf] (focal-proposed) [4.0.0-1]
<wxl> vorlon: that's weird that you say you manually sync'd qtermwidget (well, it doesn't given the changes you made, which erase history, butâ¦) since looking at the full publishing history on launchpad 0.14.1-2 says it was "Copied from debian sid in Primary Archive for Debian GNU/Linux by Ubuntu Archive Auto-Sync (sponsored by Ubuntu Archive Robot)"
<wxl> vorlon: in any case, as kc2bez says, the issue on our daily was because we had the old version of -l10n and the new version of -data which is super weird given they come from the same source package and that seems resolved now. i can only think that was some timing error that we would have avoided had the build happened just a few seconds later. bizarre.
<wxl> vorlon: however, someone else said they had a similar error trying to upgrade an existing focal install, which also seems weird. i would expect apt to calculate all of the appropriate changes and act accordingly, i.e. to remove -l10n before bothering trying to upgrade -data. but maybe the only way to ensure this is breaks/replaces. see bug 1864170
<ubot5> bug 1864170 in qtermwidget (Ubuntu) "dpkg ugrade error - files in qtermwidget5-data also in old qtermwidget-l10n" [Undecided,New] https://launchpad.net/bugs/1864170
<cjwatson> wxl: You're looking at the copy into the release pocket.  Look at the copy into -proposed, which was done by vorlon
<wxl> cjwatson: ah yes, i see that now. well, at least the machinery is working correctly XD
<RikMills> wxl: how would apt/dpkg know that there will be a file conflict. you need to tell it in the packaging. i.e. breaks/replaces in the packaging
<wxl> yeah i guess you're right :/
<RikMills> wxl: LP: #1864170
<ubot5> Launchpad bug 1864170 in qtermwidget (Ubuntu) "dpkg ugrade error - files in qtermwidget5-data also in old qtermwidget-l10n" [Undecided,New] https://launchpad.net/bugs/1864170
<wxl> RikMills: see a few lines up
<RikMills> wxl: see what?
<wxl> that i mentioned the same bug XD
<RikMills> :)
-queuebot:#ubuntu-release- Unapproved: system-config-printer (eoan-proposed/main) [1.5.11-4ubuntu1 => 1.5.11-4ubuntu2] (desktop-core)
<RikMills> anyway, it is easy one to fix
<wxl> yeah ok well alf upstream in debian broke it. there's a rec to qtermwidget-l10n which is not available at least as far back as buster https://packages.debian.org/buster/libqtermwidget5-0
<wxl> there is a separate lxqt-l10n that maybe they intended to stick qtermwidget-l10n into but it's not there
<wxl> looks like that change came in (egads) 0.7.1-3 https://salsa.debian.org/lxqt-team/qtermwidget/commit/4a6c55c5479c04f09c461cc5629d859fed2ddbcd
<wxl> i don't know how we went this long without it breaking
-queuebot:#ubuntu-release- Unapproved: libreoffice (eoan-proposed/main) [1:6.3.4-0ubuntu0.19.10.1 => 1:6.3.5-0ubuntu0.19.10.1] (ubuntu-desktop)
<wxl> oh! WE added it in 0.14.0-0ubuntu1 https://launchpad.net/ubuntu/+source/qtermwidget/0.14.0-0ubuntu1
<RikMills> wxl: yes, you were packaging 0.14 slightly ahead of debian, and made a different choice on what to do with the new translation files. you made an -l10n package. debian 2 days later put them in the -data package. you have not merged/synced since
<wxl> yikes
<LocutusOfBorg> vorlon, please? https://bugs.launchpad.net/ubuntu/+source/svn-workbench/+bug/1863931
<ubot5> Ubuntu bug 1863931 in svn-workbench (Ubuntu) "please remove svn-workbench from focal" [Undecided,New]
<LocutusOfBorg> (removed in sid already)
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (trusty-proposed) [0.82.1ubuntu2.6]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (disco-proposed) [2.43.3+19.04]
<vorlon> xnox: how are things going w/ icu and boost?
<RikMills> vorlon: the nifti2dicom in release does not depend on qt4, but still shows on https://people.canonical.com/~ubuntu-archive/transitions/html/html/qt4-rm.html
<RikMills> some cleanup required as that is now only amd64?
<RikMills> meshlab and doomsday will hopefully be off the rm list shortly, so that would leave only 4 qt4 things left :)
<RikMills> debuild should sign the changes file
<RikMills> if not, you can use the debsign command
<RikMills> ^^ wrong chat for last 2 lines
<RikMills> whoops!
<vorlon> RikMills: nifti2dicom shows on there as 'unknown', not 'bad', I don't know what it matches that causes it to be shown in the transition but nothing else to be done there
<RikMills> vorlon: ok. just wondered if it meant there was something more to do. thanks
-queuebot:#ubuntu-release- New source: bind9-libs (focal-proposed/primary) [1:9.11.16+dfsg-3~build1]
<blackboxsw> sil2100: rbalint powersj morlino sbeattie vorlon just finished SRU verification for unattended-upgrades per https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1857051   thanks for your work there folks! No need to upload to trusty.
<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> ^ just closing out for those that put eyes on the above
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-15.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-15.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-15.18] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-15.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-15.18]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-15.18]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-15.18] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-15.18]
-queuebot:#ubuntu-release- New binary: flashrom [amd64] (focal-proposed/universe) [1.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cstore-fdw [amd64] (focal-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-joint-state-publisher [amd64] (focal-proposed/universe) [1.12.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cstore-fdw [s390x] (focal-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [s390x] (focal-proposed/universe) [2.9.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cstore-fdw [arm64] (focal-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [amd64] (focal-proposed/universe) [2.9.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cstore-fdw [armhf] (focal-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: knot [ppc64el] (focal-proposed/universe) [2.9.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cstore-fdw [ppc64el] (focal-proposed/universe) [1.7.0-1] (no packageset)
 * RikMills glares at meshlab
-queuebot:#ubuntu-release- New binary: knot [arm64] (focal-proposed/universe) [2.9.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: visp [amd64] (focal-proposed/universe) [3.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cstore-fdw [ppc64el] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted knot [ppc64el] (focal-proposed) [2.9.2-4]
-queuebot:#ubuntu-release- New binary: knot [armhf] (focal-proposed/universe) [2.9.2-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted knot [arm64] (focal-proposed) [2.9.2-4]
-queuebot:#ubuntu-release- New: accepted visp [amd64] (focal-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [amd64] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [armhf] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted flashrom [amd64] (focal-proposed) [1.2-3]
-queuebot:#ubuntu-release- New: accepted knot [s390x] (focal-proposed) [2.9.2-4]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [arm64] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted knot [amd64] (focal-proposed) [2.9.2-4]
-queuebot:#ubuntu-release- New: accepted cstore-fdw [s390x] (focal-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New: accepted ros-joint-state-publisher [amd64] (focal-proposed) [1.12.14-1]
<vorlon> augh why does germinate list htmldoc in i386+build-depends.sources but not in i386+build-depends
-queuebot:#ubuntu-release- Packageset: Removed avalon-framework from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed python-functools32 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added htmldoc to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libpdfbox-java to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added protozero to i386-whitelist in focal
#ubuntu-release 2020-02-22
<vorlon> this r-cran-xml autopkgtest failure looks an awfully lot like a wrong test to me
-queuebot:#ubuntu-release- New binary: acorn [amd64] (focal-proposed/universe) [6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-13] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pixmap [amd64] (focal-proposed/universe) [0.4-11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rdbnomics [amd64] (focal-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-matlab [amd64] (focal-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pixmap [s390x] (focal-proposed/universe) [0.4-11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pixmap [arm64] (focal-proposed/universe) [0.4-11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pixmap [armhf] (focal-proposed/universe) [0.4-11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pixmap [ppc64el] (focal-proposed/universe) [0.4-11-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-matlab [amd64] (focal-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pixmap [armhf] (focal-proposed) [0.4-11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pixmap [s390x] (focal-proposed) [0.4-11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pixmap [arm64] (focal-proposed) [0.4-11-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rdbnomics [amd64] (focal-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pixmap [ppc64el] (focal-proposed) [0.4-11-1]
-queuebot:#ubuntu-release- New: accepted acorn [amd64] (focal-proposed) [6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-13]
-queuebot:#ubuntu-release- New: accepted r-cran-pixmap [amd64] (focal-proposed) [0.4-11-1]
-queuebot:#ubuntu-release- New: accepted knot [armhf] (focal-proposed) [2.9.2-4]
-queuebot:#ubuntu-release- New binary: openvdb [s390x] (focal-proposed/universe) [6.2.1-8ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: openvdb [amd64] (focal-proposed/universe) [6.2.1-8ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: openvdb [ppc64el] (focal-proposed/universe) [6.2.1-8ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New: accepted bind9-libs [source] (focal-proposed) [1:9.11.16+dfsg-3~build1]
-queuebot:#ubuntu-release- New: accepted openvdb [amd64] (focal-proposed) [6.2.1-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted openvdb [s390x] (focal-proposed) [6.2.1-8ubuntu1]
-queuebot:#ubuntu-release- New: accepted oem-qemu-meta [source] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New: accepted openvdb [ppc64el] (focal-proposed) [6.2.1-8ubuntu1]
-queuebot:#ubuntu-release- New binary: oem-qemu-meta [amd64] (focal-proposed/universe) [20.04~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted oem-qemu-meta [amd64] (focal-proposed) [20.04~ubuntu1]
-queuebot:#ubuntu-release- New binary: bind9-libs [s390x] (focal-proposed/universe) [1:9.11.16+dfsg-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: bind9-libs [ppc64el] (focal-proposed/universe) [1:9.11.16+dfsg-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: bind9-libs [amd64] (focal-proposed/universe) [1:9.11.16+dfsg-3~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bind9-libs [amd64] (focal-proposed) [1:9.11.16+dfsg-3~build1]
-queuebot:#ubuntu-release- New: accepted bind9-libs [s390x] (focal-proposed) [1:9.11.16+dfsg-3~build1]
-queuebot:#ubuntu-release- New: accepted bind9-libs [ppc64el] (focal-proposed) [1:9.11.16+dfsg-3~build1]
<doko> ahasenack: please subscribe server team to bind9-libs. already promoted to get things installable again
<ahasenack> doko: wilco
<ahasenack> it won't migrate until I upload the real bind9
<ahasenack> hm, not sure what's going on with the libreoffice/arm64 tests, there's just a console dump at the end of the failed run
<ahasenack> http://autopkgtest.ubuntu.com/packages/libr/libreoffice/focal/arm64
<ahasenack> there are two boot logs, and one has a panic as it can't mount root
-queuebot:#ubuntu-release- New binary: node-prosemirror-model [amd64] (focal-proposed/universe) [1.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-autoparse [amd64] (focal-proposed/universe) [0.3.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-terraform-svchost [amd64] (focal-proposed/universe) [0.0~git20191119.d2e4933-1] (no packageset)
#ubuntu-release 2020-02-23
-queuebot:#ubuntu-release- New binary: duktape [amd64] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-clipboard [amd64] (focal-proposed/universe) [2.0.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [s390x] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-gcp-common [amd64] (focal-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [ppc64el] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [arm64] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [armhf] (focal-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted duktape [armhf] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [amd64] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [ppc64el] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-go-gcp-common [amd64] (focal-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted node-clipboard [amd64] (focal-proposed) [2.0.4+ds-1]
-queuebot:#ubuntu-release- New: accepted ruby-autoparse [amd64] (focal-proposed) [0.3.3-3]
-queuebot:#ubuntu-release- New: accepted duktape [arm64] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-terraform-svchost [amd64] (focal-proposed) [0.0~git20191119.d2e4933-1]
-queuebot:#ubuntu-release- New: accepted duktape [s390x] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted node-prosemirror-model [amd64] (focal-proposed) [1.9.0-1]
<vorlon> incredible, all of ruby-libxml, r-cran-xml2, and libxml-libxml-perl have autopkgtest regressions with new libxml2 because they're are making buggy assertions in their test suites
<vorlon> -        xmlC14NErrInternal("cannicanize document to buffer");
<vorlon> +        xmlC14NErrInternal("canonize document to buffer");
<vorlon> >_<
<ginggs> canonize?  make the document a saint
<vorlon> evidently
<vorlon> wow, apparently registering a new account on gitlabe.gnome.org w/ github as the auth source is a bad idea
<vorlon> anyway, libxml2 uploaded with a fix for the real bug causing the libxml-libxslt-perl/armhf failure; so that part of icu should clear now
<vorlon> and stale i386 binaries removed from -proposed to let e-d-s through
<vorlon> 6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-14
<doko> LocutusOfBorg: llvm-8 needs some python3.8 & swig love ...
<doko> The following packages have unmet dependencies:
<doko>  idle-python3.7 : Depends: python3.7-tk
<doko> E: Unable to correct problems, you have held broken packages.
<doko> vorlon: ^^^please ignore the python3.7 test failure, we're going to remove it anyway
<LocutusOfBorg> doko, will have a look thanks
<LocutusOfBorg> I don't know what is swig, but me
<LocutusOfBorg> meh
-queuebot:#ubuntu-release- New binary: zshdb [amd64] (focal-proposed/universe) [1.1.2-1] (no packageset)
<vorlon> doko: surely icu didn't need reuploaded while in the middle of the transition to remove patches (and reset the update_output)
<vorlon> and getting snagged on flaky autopkgtests that need button mashing
<vorlon> doko: python3.7 autopkgtests ignored
-queuebot:#ubuntu-release- New binary: golang-github-jcmturner-gofork [amd64] (focal-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-errgo.v2 [amd64] (focal-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jcmturner-dnsutils.v1 [amd64] (focal-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jcmturner-rpc.v0 [amd64] (focal-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-karrick-godirwalk [amd64] (focal-proposed/universe) [1.15.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jcmturner-goidentity.v2 [amd64] (focal-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-hlandau-acmeapi.v2 [amd64] (focal-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-jcmturner-aescts.v1 [amd64] (focal-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-questplus [amd64] (focal-proposed/universe) [2019.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lavasearch2 [amd64] (focal-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openssh [amd64] (focal-proposed/main) [1:8.2p1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: python-questplus [armhf] (focal-proposed/universe) [2019.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openssh [s390x] (focal-proposed/main) [1:8.2p1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: python-questplus [arm64] (focal-proposed/universe) [2019.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openssh [ppc64el] (focal-proposed/main) [1:8.2p1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: r-cran-lavasearch2 [arm64] (focal-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lavasearch2 [armhf] (focal-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-questplus [ppc64el] (focal-proposed/universe) [2019.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lavasearch2 [ppc64el] (focal-proposed/universe) [1.5.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openssh [arm64] (focal-proposed/main) [1:8.2p1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: openssh [armhf] (focal-proposed/main) [1:8.2p1-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: python-questplus [s390x] (focal-proposed/universe) [2019.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lavasearch2 [s390x] (focal-proposed/universe) [1.5.4+dfsg-1] (no packageset)
